Cuando un framework como Next.js, Nuxt o SvelteKit te pregunta cómo querés renderizar una página, la respuesta que des no es solo técnica. Define qué tan rápido responde tu sistema, qué tan fresca está la información, y — más importante de lo que parece — cómo percibe el usuario lo que ve.
Hay tres estrategias principales. Entenderlas bien te ahorra elegir la equivocada.
SSR — Server-Side Rendering
Con SSR, cada request genera el HTML en el servidor en ese momento. El usuario pide la página, el servidor busca los datos, construye el HTML, y lo devuelve.
Qué le da al usuario: información fresca y personalizada. Si tu app muestra datos de cuenta, precios en tiempo real, o contenido basado en sesión, SSR es la única estrategia que puede hacerlo correctamente.
Qué le cuesta al sistema: cada request consume recursos del servidor. Bajo tráfico alto, la latencia crece. La disponibilidad depende de que el servidor responda bien — si está lento, la página está lenta.
Para qué sirve: paneles de usuario, ecommerce con precios dinámicos, feeds de contenido personalizado, cualquier cosa donde los datos cambian entre un usuario y otro o entre un request y el siguiente.
SSG — Static Site Generation
Con SSG, el HTML se genera una vez, en el momento del build, y se sirve como archivo estático desde un CDN. No hay servidor que procesar por request — el archivo ya existe.
Qué le da al usuario: velocidad extrema. Un archivo servido desde un CDN cerca del usuario es lo más rápido que puede ser una página web. Sin latencia de servidor, sin base de datos consultada en tiempo real.
Qué le cuesta al sistema: los datos están congelados en el momento del build. Si algo cambia, tenés que volver a buildear y deployar para que el cambio se vea. En sitios con contenido muy dinámico, eso es inmanejable.
Para qué sirve: landing pages, documentación, blogs, sitios de marketing, cualquier cosa donde el contenido cambia poco y la velocidad de carga importa mucho.
ISR — Incremental Static Regeneration
ISR es el punto medio: las páginas se generan estáticamente, pero con una ventana de revalidación. Después de cierto tiempo, la próxima request dispara una regeneración en background. El usuario actual sigue viendo la versión cacheada; el siguiente ya ve la nueva.
Qué le da al usuario: casi la misma velocidad que SSG, con datos que se actualizan periódicamente sin necesidad de rebuilds completos.
Qué le cuesta al sistema: complejidad de razonamiento. En algún momento el usuario va a ver datos que tienen algunos minutos de retraso. Para la mayoría de los casos eso está bien; para datos críticos (stocks, precios en tiempo real), no lo está.
Para qué sirve: páginas de producto en ecommerce, listados de contenido, cualquier cosa que cambia pero no cada segundo — y donde tolerás una ventana de eventual consistencia.
Cómo compararlos
| SSR | SSG | ISR | |
|---|---|---|---|
| Velocidad de respuesta | Depende del servidor | Muy alta (CDN) | Alta (CDN + revalidación) |
| Frescura de datos | Siempre actual | Congelada al build | Periódicamente actual |
| Personalización | Sí | No | Limitada |
| Complejidad operativa | Alta | Baja | Media |
| Ideal para | Datos dinámicos y personalizados | Contenido estático | Contenido semi-dinámico |
La pregunta que determina todo
Antes de elegir, una sola pregunta: ¿los datos de esta página cambian entre un usuario y el siguiente, o entre un request y el siguiente?
Si la respuesta es sí — SSR. Si la respuesta es no, pero cambian cada tanto — ISR con una ventana de revalidación razonable. Si la respuesta es no, o casi nunca — SSG y servilo desde el CDN más cercano a tus usuarios.
La mayoría de las aplicaciones reales necesitan las tres estrategias en distintas rutas. La página de inicio puede ser SSG. Las páginas de producto, ISR. El dashboard del usuario, SSR. Los frameworks modernos te dejan mezclarlas por ruta exactamente por eso — no te obligan a elegir una para todo el sitio.
El error más común es elegir SSR por defecto porque "así siempre tengo datos frescos", sin considerar que cada request que podría ser estático está usando recursos de servidor innecesariamente. El segundo error más común es elegir SSG por defecto porque "es más rápido", y enterarse en producción de que los precios o el stock que muestra el sitio son de hace tres horas.
La elección correcta no es la más sofisticada — es la que le da al usuario lo que necesita con la menor complejidad operativa posible.