Ultima actualización
La elección de la estrategia de renderizado no es solo una decisión técnica; define la Experiencia de Usuario (UX), el SEO y los costos de infraestructura de tu aplicación.
Esta guía técnica desglosa cuándo y por qué utilizar cada modelo en el ecosistema actual de Next.js.
SSR (Server-Side Rendering)
Dynamic Rendering at Request Time
El HTML se genera en el servidor en cada petición.
Ideal para:
- Datos en tiempo real: Dashboards financieros, feeds de redes sociales.
- Personalización crítica: Páginas que dependen de cookies o headers del request.
- SEO dinámico: Contenido que cambia cada segundo y debe ser indexado.
Trade-offs Técnicos:
- ⚠️ Mayor TTFB (Time to First Byte): El usuario espera a que el servidor procese la página.
- 💸 Costo Computacional: Requiere ejecución de servidor (Serverless/Node) por cada visita.
SSG (Static Site Generation)
Build Once, Cache Forever
El HTML se genera durante el build time y se distribuye globalmente vía CDN.
Ideal para:
- Marketing Pages: Landings, "About Us", Contacto.
- Documentación: Contenido que no cambia frecuentemente.
- Blogs: Artículos históricos.
Ventajas:
- 🚀 Performance Extrema: El TTFB es insignificante (servido desde el Edge).
- ✅ Estabilidad: Si la API de datos falla, la página sigue funcionando (es un archivo estático).
ISR (Incremental Static Regeneration)
Static Content with Dynamic Updates
Combina la velocidad de SSG con la frescura de SSR. Permite regenerar páginas estáticas en el fondo tras un intervalo de tiempo (revalidate).
Ideal para:
- E-commerce: Fichas de producto (precios/stock pueden tener un lag de minutos).
- Sitios de Noticias: Contenido que puede tolerar un retraso de 60 segundos.
Mecanismo:
- Usuario A visita la página → Recibe versión v1 (rápida desde caché).
- Next.js detecta que el caché expiró → Inicia regeneración en background.
- Usuario B visita la página → Recibe v2 actualizada.
PPR (Partial Prerendering)
The Future of Hybrid Rendering
La "bala de plata" de Next.js. Permite que una misma ruta tenga un shell estático (SSG) de carga instantánea, mientras partes dinámicas (como un carrito de compras) se cargan vía Streaming.
Ideal para:
- Aplicaciones Modernas: Donde el layout es estático pero el contenido es dinámico.
- Optimización de Core Web Vitals: Mejora drástica de LCP (Largest Contentful Paint) y reducce el CLS.
Beneficio: Elimina el "waterfall" de datos. El usuario ve la estructura inmediatamente mientras los datos llegan.
Matriz de Decisión
| Estrategia | Escenario Típico | Performance (LCP) | Costo Server |
|---|---|---|---|
| SSG | Blog, Landing | ⭐⭐⭐⭐⭐ (Instantáneo) | 📉 Bajo |
| ISR | Catálogo Productos | ⭐⭐⭐⭐⭐ (Cache Hit) | 📉 Bajo-Medio |
| SSR | Admin Panel, Feed | ⭐⭐ (Depende de DB) | 📈 Alto |
| PPR | App Compleja | ⭐⭐⭐⭐ (Hybrid) | ⚖️ Balanceado |
Conclusión
No existe un "mejor renderizado" universal.
- Si puedes hacerlo estático (SSG), hazlo estático.
- Si necesitas frescura pero puedes tolerar latencia, usa SSR.
- Si quieres lo mejor de ambos mundos para apps complejas, apuesta por PPR.
Como ingenieros, nuestro trabajo es alinear la tecnología con los requerimientos del producto. Elige la estrategia que maximice el valor para el usuario final.