El renderizado incremental es una de las innovaciones más importantes en el desarrollo web moderno. Next.js, el metaframework de React más adoptado, implementa dos estrategias clave que resuelven la tensión entre el contenido estático (rápido pero desactualizado) y el dinámico (actualizado pero lento): Incremental Static Regeneration (ISR) y On-Demand Revalidation.
El problema que ISR resuelve
En una arquitectura Jamstack clásica, las páginas se generan en build time. Esto produce sitios extremadamente rápidos (HTML puro servido desde CDN) pero con una limitación: cuando el contenido cambia, hay que hacer un nuevo build y despliegue para que el cambio se vea. Para un blog con artículos que se publican una vez por semana, esto puede funcionar. Para un sitio de noticias que actualiza 50 veces al día, es inviable.
La generación dinámica (SSR) resuelve la actualización pero sacrifica el rendimiento: cada petición ejecuta código en el servidor y puede ser lenta. ISR es el término medio: las páginas se generan estáticamente pero se regeneran automáticamente en background cuando el contenido cambia o cuando expira un tiempo definido.
Cómo funciona ISR en Next.js
Con ISR, el desarrollador define un revalidate interval para cada página: el número de segundos después del cual Next.js regenerará esa página en background cuando llegue una petición. El visitante siempre recibe la versión cacheada (rápida), y Next.js actualiza el cache en background sin bloquear al usuario.
- Primera petición: la página se genera en el servidor y se cachea
- Peticiones siguientes dentro del revalidate interval: se sirve la versión cacheada (velocidad máxima)
- Primera petición después de que expira el revalidate: se sirve la versión cacheada y se dispara una regeneración en background
- Peticiones siguientes: reciben la nueva versión ya regenerada
On-Demand Revalidation: control preciso sobre el cache
ISR con intervalo de tiempo tiene una limitación: si publicás un artículo, puede tardar el tiempo del revalidate interval en aparecer. On-Demand Revalidation resuelve esto: Next.js expone un endpoint de API que invalida el cache de una ruta específica en el momento en que se llama. Un webhook desde WordPress puede llamar a este endpoint cuando se publica un post, actualizando el frontend de Next.js inmediatamente.
Este patrón es el corazón de las arquitecturas WordPress + Next.js headless más sofisticadas en 2026: el contenido se gestiona en WordPress, el frontend vive en Vercel o Cloudflare Pages como sitio estático, y los webhooks mantienen el frontend actualizado en tiempo real con On-Demand Revalidation.
Cuándo usar ISR vs SSR vs SSG
SSG (build time completo): ideal para contenido que no cambia o cambia raramente (landing pages, documentación). ISR: ideal para contenido que cambia con cierta frecuencia pero no en tiempo real (blogs, catálogos de productos, noticias). SSR (cada petición al servidor): ideal para contenido personalizado por usuario o datos que cambian en tiempo real.
En Octopus Agencia Digital construimos frontends Next.js con ISR sobre backends WordPress para clientes que necesitan la combinación de rendimiento y agilidad editorial. Hablemos si te interesa esta arquitectura.
