Volver al diccionario
Desarrollo Web
SSR / SSG / ISR
SSR, SSG e ISR son las estrategias de renderizado web. Aprende qué es Server-Side Rendering, Static Generation, ISR y cuándo usar cada una en tu proyecto.
Estrategias de renderizado
Las aplicaciones web modernas pueden renderizarse en diferentes momentos y lugares, cada estrategia con sus ventajas.
SSR (Server-Side Rendering)
El HTML se genera en el servidor para cada petición.
Ventajas:
- SEO perfecto
- Contenido siempre actualizado
- Buena para páginas dinámicas
Desventajas:
- Más carga en el servidor
- TTFB más lento
Uso: Páginas de producto, dashboards, contenido personalizado.
SSG (Static Site Generation)
El HTML se genera en tiempo de build, antes del despliegue.
Ventajas:
- Máxima velocidad (CDN cacheable)
- Sin carga en el servidor
- Ideal para hosting barato
Desventajas:
- Build time aumenta con muchas páginas
- Contenido estático hasta el siguiente build
Uso: Blogs, documentación, páginas de marketing.
ISR (Incremental Static Regeneration)
Combina SSG con actualización periódica. Las páginas se regeneran en segundo plano cada X segundos.
Ventajas:
- Velocidad de SSG
- Contenido actualizado sin rebuild completo
Ejemplo en Next.js:
\\\`javascript
export async function getStaticProps() {
const productos = await fetchProductos()
return {
props: { productos },
revalidate: 3600 // Regenerar cada hora
}
}
\\\`
CSR (Client-Side Rendering)
El HTML se genera en el navegador con JavaScript. Usado en SPAs (Single Page Applications).
Ventajas: Navegación fluida sin recargas, muy interactivo
Desventajas: SEO complicado (los bots pueden no ejecutar JS), carga inicial lenta, el usuario ve contenido en blanco mientras carga
Uso: Dashboards privados, aplicaciones autenticadas donde el SEO no importa.
Comparativa de estrategias
| Estrategia | Cuándo se genera el HTML | Ideal para | SEO | Velocidad |
|---|---|---|---|---|
| SSR | En el servidor, en cada petición | Páginas dinámicas y personalizadas | Perfecto | TTFB más lento |
| SSG | En build time, antes del deploy | Blogs, landings, documentación | Perfecto | Máxima |
| ISR | SSG + regeneración periódica | Catálogos con actualizaciones frecuentes | Perfecto | Muy alta |
| CSR | En el navegador | Dashboards, apps privadas | Problemático | Primera carga lenta |
Renderizado en Next.js App Router
Con el App Router de Next.js (versión 13+), el modelo cambia:
- Server Components (por defecto): Se renderizan en el servidor, el HTML se envía al cliente. Sin JavaScript en el cliente.
- Client Components (\
'use client'\): Hidratados en el cliente para interactividad. - **\
cache: 'no-store'\**: Equivale a SSR — datos frescos en cada petición. - **\
revalidate: 3600\**: Equivale a ISR — regeneración cada hora. - Sin cache**: Equivale a SSG — datos estáticos durante el build.
Preguntas frecuentes
¿Cuál es mejor para SEO: SSR o SSG?
Ambos son igual de buenos para SEO. El HTML llega pre-renderizado al bot de Google, que lo indexa perfectamente. La diferencia es la frescura del contenido: SSR siempre es actual, SSG puede estar desactualizado hasta el próximo build (o la próxima revalidación con ISR).
¿Puede un mismo proyecto usar SSR, SSG e ISR a la vez?
Sí, y es la práctica recomendada. En Next.js, cada página puede tener su propia estrategia: la home puede ser SSG (contenido estático), la página de producto puede ser ISR (actualiza cada hora), y el perfil del usuario puede ser SSR (personalizado en cada petición).
¿Por qué el CSR es malo para el SEO?
Cuando Googlebot visita una página CSR, recibe un HTML casi vacío. El contenido real se carga después con JavaScript. Aunque Google ha mejorado su capacidad para indexar contenido JavaScript, sigue siendo más lento y menos fiable que recibir el HTML ya renderizado. Para contenido que quieras posicionar, SSR o SSG son siempre más seguros.
Términos relacionados
Necesitas ayuda con tu ecommerce?
Somos expertos en desarrollo de tiendas online. Cuéntanos tu proyecto y te asesoramos sin compromiso.
Contactar con Ganton