El 90% de los Developers Elige Su Estrategia de Renderizado Mal
Tienes una página de producto en tu e-commerce. 10.000 visitas diarias. Precio que cambia cada hora.
La configuras como Static Generation.
Vercel cachea el HTML. El tiempo de respuesta es instantánea. Todo parece perfecto.
Hasta que un usuario ve un precio de ayer.
El problema real no es qué herramienta usas. Es que no entiendes cuándo invalidate el cache.
La mayoría de developers elige entre Static, ISR y Dynamic basándose en intuición. Pocos han leído la documentación de revalidate. Menos todavía han medido el impacto real de cada decisión.
Este artículo te da el framework para decidir correctamente.
Por Qué Static No Siempre Es la Respuesta
La sabiduría convencional dice: "Static es más rápido, úsalo siempre que puedas."
Esa frase es mentira incompleta.
Static Generation genera HTML en build time. El contenido nunca cambia hasta el siguiente deploy. Para páginas de marketing, documentación, o landing pages, es perfecto.
Para tu catálogo de productos con precios que fluctúan, es un desastre.
El espectro completo de renderizado en Next.js
La decisión correcta depende de tres variables:
→ Frecuencia de cambio del contenido
→ Volumen de tráfico esperado
→ Necesidad de datos personalizados por usuario
ISR: El Medio Que Todos Ignoran
La Incremental Static Regeneration existe desde Next.js 12.1.
Funciona así: generas la página estática en build, pero defines un intervalo de revalidación. Pasado ese tiempo, la siguiente petición triggers una regeneración en background.
Este código genera estáticamente todas las páginas de productos en build. Después, cada hora, la primera visita que llega dispara una regeneración en background.
Los números que importan
- TTFB (Time to First Byte): similar a Static una vez cacheado
- Freshness: contenido actualizado dentro del intervalo de revalidate
- Server load: una regeneración por hora, no por request
- Scalability: maneja millones de visitas sin computational overhead
ISR te da 90% de los beneficios de Static con 10% de la frescura de Dynamic.
El secreto es elegir el intervalo de revalidate correcto.
El Framework de Decisión: Tres Preguntas
Antes de elegir tu estrategia, responde estas tres preguntas en orden:
1. ¿Con qué frecuencia cambia el contenido?
2. ¿El contenido es personalizado por usuario?
3. ¿Cuánto tráfico esperas?
❌ Lo que hace la mayoría:
"Elijo ISR porque es el término del medio y parece equilibrado."
✅ Lo correcto:
"Aplico el framework: contenido cambia cada 6 horas, es igual para todos, espero 500k visitas → ISR con revalidate 21600."
Patrones de ISR Que el Tutorial Básico No Entiende
ISR por-ruta vs global
Next.js 14+ permite configurar revalidate a nivel de segmento completo o por-route específica:
On-Demand Revalidation
El revalidate basado en tiempo tiene un problema: si publicas un artículo a las 23:59 y el revalidate está en 24 horas, el contenido viejo permanece hasta el día siguiente.
La solución es on-demand revalidation via webhooks:
Tu CMS (Sanity, Contentful, Strapi) envía un webhook a /api/revalidate cuando publicas contenido. Vercel recibe el webhook, triggerea revalidación, y el contenido se actualiza instantáneamente.
Stale-While-Revalidate Pattern
Para contenido crítico donde la frescura importa más que la velocidad, usa el patrón stale-while-revalidate:
El usuario ve contenido inmediatamente (puede ser 1 minuto viejo). En background, Next.js revalida. La siguiente petición ya tiene contenido fresco.
Cuándo Dynamic Rendering Es La Elección Correcta
No todo debe ser ISR.
Dynamic Rendering genera HTML en cada request. Es slower, pero necesario en tres escenarios:
1. Contenido personalizado por sesión
2. Datos que cambian en tiempo real
3. Headers/Cookies requeridos
❌ Error común:
"Uso Dynamic para todo porque es más simple y no tengo que pensar en cache."
✅ Decisión correcta:
"Mi dashboard de analytics tiene datos real-time → Dynamic. Mi página de pricing con cambios semanales → ISR."
Configuración en Vercel: El Detalle Que Importa
Vercel automatiza mucho del cacheo, pero hay configuraciones específicas que debes conocer:
Headers de Cache en Vercel
Para páginas ISR con revalidate 3600:
El CDN cachea 1 hora. Pasada esa hora, sirve stale hasta 24 horas mientras revalida.
Caso Real: Migración de Dynamic a ISR
Proyecto real: e-commerce de moda con 800k visitas mensuales.
Situación inicial:
- Todo en Dynamic Rendering
- TTFB promedio: 850ms
- Server load: alto, costs elevados
- Contenido de producto actualizable 2-3 veces por semana
Cambio aplicado:
- Categorías y listados → ISR con revalidate 3600
- Páginas de producto → ISR con revalidate 300 + on-demand revalidation
- Carrito y checkout → Dynamic (sesión personalizada)
- Landing pages → Static Generation
Resultados medidos:
- TTFB promedio: 45ms (95% improvement)
- Server load: reducido 73%
- Contenido de producto actualizado: instantáneo post-publicación
- Coste de infraestructura: significativamente menor
La diferencia no fue cambiar de hosting. Fue elegir la estrategia de renderizado correcta.
Key Takeaways
→ Static Generation es para contenido que nunca cambia: documentación, landing pages, contenido de marketing.
→ ISR es para contenido que cambia periódicamente con volumen alto: catálogos, blogs, listados de productos.
→ Dynamic Rendering es para contenido personalizado o real-time: dashboards, perfiles de usuario, precios que fluctúan constantemente.
→ On-demand revalidation elimina la necesidad de intervalos cortos de revalidate. Tu CMS triggerea la actualización cuando publicas.
→ Mide antes de optimizar. Dashboard de Vercel te muestra TTFB, cache hit rate, y server execution time. Esas métricas te dicen si tu estrategia actual funciona.
Tu Siguiente Paso
Abre tu proyecto Next.js en Vercel. Identifica tus 10 páginas con más tráfico. Clasifícalas:
- ¿Con qué frecuencia cambia el contenido?
- ¿Es igual para todos los usuarios?
- ¿Cuál es tu TTFB actual?
Si alguna página con contenido estático tiene TTFB > 100ms, probablemente está en Dynamic cuando debería estar en ISR.
La decisión de renderizado no es arquitectura fija. Es una decisión por página que evoluciona con tu producto.
Cambia una página hoy. Mide el impacto. Repite.
Artículos relacionados
- Error Recovery en AI Agents: El Framework que Transforma el 40% de Fallos en Aprendizaje
- Refactoring con AI: El Sistema que Reduce Deuda Técnica un 40% Sin Romper Producción
- Schema Design Patterns en Sanity.io: Cómo Construir Schemas que Sobreviven a Tus Migraciones
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
