SSR, CSR, SSG e ISR: la diferencia real
SSG crea HTML antes de que llegue la request, normalmente durante el build. SSR lo crea en el servidor para cada request. CSR construye gran parte de la interfaz después de ejecutar JavaScript en el navegador. ISR conserva un resultado estático pero permite regenerarlo tras el despliegue por tiempo o invalidación explícita. [6][9][16]
Las preguntas útiles son cuándo se genera el HTML, cuánto tiempo se guarda y cuánto trabajo queda para el navegador.
SEO: Google renderiza JavaScript, pero CSR no equivale a prerendering
Google describe tres fases para sitios JavaScript: crawling, rendering e indexing. Si el HTML inicial no contiene el contenido real, el Web Rendering Service debe ejecutar JavaScript y la página entra en una cola de renderizado. [1]
Google también recomienda SSR o prerendering porque mejora la velocidad para usuarios y crawlers, y no todos los bots ejecutan JavaScript. [1]
CSR puede funcionar, pero para contenido público importante es más robusto entregar HTML significativo desde el principio.
SSG: el mejor punto de partida para contenido poco cambiante
Con SSG, el HTML se genera en el build y puede servirse como archivo estático desde CDN. Next.js recomienda Static Generation cuando la página puede prepararse antes de la request. [9][12]
Landing pages, documentación, artículos, ayuda, portfolios y parte de los listados de producto son casos típicos. [10][16]
La limitación aparece cuando los datos cambian con mucha frecuencia o el build se vuelve demasiado largo.
SSR: cuando el contenido debe estar fresco o depende de la request
SSR genera HTML para una request concreta y puede utilizar datos actuales, headers, cookies, localización o parámetros. [6][10][11]
El contenido llega en HTML, pero cada request implica trabajo de servidor y un render lento puede aumentar TTFB. [6]
Las partes estables pueden cachearse y dejar dinámico solo lo realmente dependiente de la request.
ISR: HTML estático con frescura controlada
ISR mantiene las ventajas del HTML estático y permite regenerar páginas después del despliegue. Next.js documenta la actualización de páginas estáticas tras el build y Nuxt 4 ofrece mecanismos similares con `isr` y `swr`. [9][13][16]
Encaja con catálogos, artículos, documentación y categorías que cambian periódicamente pero no necesitan tiempo real.
Con stale-while-revalidate, el primer visitante tras la expiración puede recibir la versión anterior mientras se genera la nueva. [13][16]
CSR: adecuado para aplicaciones sin necesidad de indexación
En CSR, el navegador descarga, analiza y ejecuta JavaScript antes de construir gran parte del DOM. web.dev advierte que bundles grandes pueden perjudicar INP, especialmente en móviles. [6][7]
Nuxt cita SaaS, back-office, juegos e interfaces muy interactivas sin necesidad SEO como casos adecuados. [13]
Para contenido público, CSR aumenta la dependencia del renderizado JavaScript de los crawlers. [1][2]
Comparación de SEO y rendimiento
| Modo | Cuándo se genera el HTML | Contenido en HTML inicial | Frescura | Coste por request | SEO |
|---|---|---|---|---|---|
| SSG | Build | Sí | Hasta el siguiente build | Muy bajo | Muy bueno |
| ISR | Build o revalidación | Sí | Según revalidación | Bajo | Muy bueno |
| SSR | Cada request | Sí | Muy alta | Más alto | Muy bueno |
| CSR | En el navegador | A menudo limitado | Alta tras fetch | Servidor bajo, cliente mayor | Posible, menos óptimo |
No existe un ranking universal. SSG e ISR suelen tener ventaja de caché y coste, SSR de frescura y CSR de flexibilidad en el cliente. [6][9][13]
Para SEO, SSG, ISR y SSR pueden devolver HTML significativo desde la primera respuesta. CSR puede ser indexado por Google, pero necesita una fase adicional de renderizado. [1][9]
Core Web Vitals: el modo de renderizado es solo un factor
| Métrica | Bueno | Malo | Qué mide |
|---|---|---|---|
| LCP | ≤ 2.5 s | > 4.0 s | Carga del contenido principal |
| INP | ≤ 200 ms | > 500 ms | Respuesta a interacciones |
| CLS | ≤ 0.1 | > 0.25 | Estabilidad visual |
Google usa Core Web Vitals en sus sistemas de ranking, pero deja claro que buenos resultados no garantizan una posición alta. Las métricas actuales son LCP, INP y CLS. [4][5]
Los umbrales recomendados son LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1 en el percentil 75. [4][8]
SSG puede entregar HTML rápido y aun así tener mal INP por exceso de JavaScript. SSR puede mejorar el primer render, pero un backend lento puede perjudicar TTFB. [6][7]
Hidratación: SSR no termina cuando llega el HTML
Muchos frameworks hidratan el resultado de SSR o SSG añadiendo estado y eventos después de recibir el HTML. web.dev advierte que la rehidratación completa puede aumentar TBT y perjudicar INP. [6]
Una página puede parecer lista y todavía bloquear interacciones durante un tiempo.
Reducir JavaScript, usar code splitting, lazy loading e hidratación parcial o diferida ayuda. Nuxt 4 documenta páginas casi estáticas con muy poco JavaScript. [7][14]
Caché y frescura: la diferencia clave
SSG reutiliza el resultado hasta el siguiente build. ISR añade revalidación. SSR puede recalcular cada request, aunque también puede combinarse con caché de servidor o CDN. [6][13][16]
La decisión debe partir de la antigüedad máxima aceptable de los datos. Unos minutos pueden ser válidos para un producto, pero no para un saldo de cuenta.
La invalidación debería relacionarse con cambios reales de contenido cuando sea posible.
SEO no termina en el renderizado
El HTML no sustituye estados HTTP correctos, enlaces rastreables, canonical, sitemap, títulos y metadatos. Google recomienda URLs propias y enlaces rastreables para el contenido importante. [1][2]
SSR mal implementado puede seguir devolviendo 200 incorrectos, duplicados o metadatos erróneos. El renderizado es una parte del SEO técnico.
Google ya no recomienda Dynamic Rendering como solución a largo plazo y prefiere SSR, static rendering o hydration. [3]
Qué estrategia elegir según la página
Landing pages, blogs y documentación suelen encajar con SSG. Catálogos grandes o noticias periódicas, con ISR. Páginas públicas dependientes de la request pueden requerir SSR. Dashboards privados pueden quedarse en CSR. [9][13]
Un e-commerce puede mezclar categoría estática, ISR para productos, SSR para datos de sesión y CSR para filtros interactivos.
La decisión debe tomarse por ruta.
Realidad de 2026: los modelos híbridos son más granulares
Next.js 16.3.4 documenta Cache Components, `use cache`, revalidación de datos y UI, una shell estática y streaming para datos de request. La guía actual se actualizó el 25 de agosto de 2026. [11]
Nuxt 4 permite `prerender`, `ssr`, `swr` e `isr` por ruta mediante Route Rules. [13][14]
Los cuatro términos siguen siendo útiles, pero ya no describen cada componente de una aplicación moderna.
Mejorar un CSR para SEO sin rehacer toda la aplicación
Primero identifica las rutas públicas que realmente deben captar tráfico orgánico. No tiene sentido convertir un dashboard privado a SSR solo por uniformidad.
Después mueve contenido crítico, títulos, metadatos y enlaces a HTML generado antes del JavaScript de cliente. Google recomienda SSR o prerendering frente a Dynamic Rendering. [1][3]
Finalmente valida Search Console, el HTML renderizado y los datos de campo de Core Web Vitals.
Regla práctica de elección
Si la página puede generarse por adelantado y el contenido es común a todos, empieza por SSG. Si cambia periódicamente, considera ISR. Si el resultado depende de la request y debe estar en HTML, usa SSR. Si es una aplicación privada sin objetivo SEO, CSR suele bastar. [9][13]
Después valida TTFB, LCP, INP, CLS, coste de servidor, frecuencia de cambios, número de páginas y personalización.
- ¿Debe indexarse el contenido principal?
- ¿Puede generarse el HTML antes de la request?
- ¿Qué frescura necesitan los datos?
- ¿Depende de cookies, sesión o request?
- ¿Cuántas rutas deben generarse?
- ¿Puede cachearse la página de forma segura?
- ¿Cuánto JavaScript debe ejecutar el navegador?
- ¿Cuáles son los LCP, INP, CLS y TTFB reales en producción?
