Headless WordPress, ISR o SSR: elegir el modo de renderizado según el ritmo del contenido
La pregunta “ISR o SSR” solo tiene sentido ruta por ruta. No hay una respuesta para todo el sitio. Astro y Next.js permiten elegir el modo a nivel de página o de layout, y lo que hace un equipo con experiencia es decidir de forma deliberada, ruta por ruta, a partir de un modelo de cada cuánto cambia el contenido.
Este artículo forma parte del pilar del servicio headless WordPress y complementa la matriz de decisión Next.js o Astro, que trata la elección a nivel de framework.
En resumen
- ISR (o estático con revalidación) gana cuando el ritmo de cambios es previsible y el tráfico es alto.
- SSR gana cuando la página está personalizada, depende de la sesión o contiene datos en directo.
- La corrección de ISR depende de la invalidación de caché; los webhooks son mejores que la revalidación por tiempo.
- Cloudflare Workers ejecuta ambos; ISR apenas consume CPU, SSR paga el renderizado completo.
- El punto de partida es el modo más barato que da un resultado correcto; pase a SSR solo cuando haga falta.
SSG, ISR y SSR explicados para WordPress
Generación de sitios estáticos (SSG). La página se construye una vez, en el build, y se sirve como HTML plano. La más barata en cada petición, la más lenta de actualizar.
Incremental Static Regeneration (ISR). La página se construye una vez, pero puede regenerarse ante un disparador, normalmente un webhook al publicar o un intervalo de revalidación por tiempo. Barata en cada petición, con consistencia eventual en las actualizaciones.
Server-Side Rendering (SSR). La página se renderiza en cada petición. Siempre actualizada, pero el coste de ejecución crece con el tráfico. La personalización, la autenticación y los datos en directo encajan aquí de forma natural.
En WordPress headless, los tres modos leen del origen WordPress mediante REST o GraphQL. La diferencia está en cuándo leen.
Cuándo usar ISR y cuándo SSR en WordPress headless
Importan dos factores:
Ritmo de cambios del contenido. ¿Con qué frecuencia cambia esta página? ¿Una vez al trimestre, una vez al día, cada minuto, en tiempo real?
Superficie de personalización. ¿La página cambia según el visitante? Estado de sesión iniciada, precios según la ubicación, variante de un test A/B.
La regla: elija el modo más barato que dé un resultado correcto. El estático es el más barato. SSR, el más caro. Avance hacia SSR solo cuando un modo más barato no dé un resultado correcto.
| Tipo de página | Modo por defecto | Por qué |
|---|---|---|
| Páginas de marketing, entradas del blog | Estático (reconstrucción al publicar) | Pocos cambios, sin personalización |
| Archivos de categorías y etiquetas | ISR con webhook de publicación | El ritmo depende de la publicación de contenido |
| Páginas de producto, catálogo estable | ISR con webhook de stock | Invalidación previsible |
| Páginas de producto, stock en tiempo real | SSR con caché en el edge | El stock cambia en segundos |
| Carrito y checkout | SSR | Dependen de la sesión por definición |
| Panel con sesión iniciada | SSR | Estado por usuario |
| Portada editorial | ISR con webhook de publicación | El ritmo depende de los eventos de publicación |
Invalidación de caché ISR con webhooks de WordPress
ISR parece gratis hasta que sirve una URL canónica obsoleta tras un cambio de slug. El patrón que lo evita:
Invalidación por webhooks. WordPress lanza un webhook al publicar, al cambiar un slug o al borrar una entrada. El framework de front-end recibe el webhook y dispara la regeneración de las páginas afectadas. El coste es una integración de webhook en el origen WordPress, que se paga una sola vez.
Revalidación por tiempo solo como red de seguridad. Un intervalo de revalidación de 60 segundos cubre los fallos de entrega de webhooks, pero no debería ser el disparador principal. Una página que se revalida cada 60 segundos también se reconstruye 60 veces por hora; en un sitio de 5000 páginas eso es insostenible.
Etiquetas de caché, no URL. Cada página en caché se etiqueta con el ID de la entrada en WordPress, los ID de los términos a los que hace referencia y etiquetas transversales (portada, sitemap). Cuando llega un webhook, el front-end purga por etiqueta, no por URL. Es la diferencia entre “regenerar la página del producto” (frágil) y “regenerar todo lo que hace referencia al producto 8421” (correcto).
Coste de ISR y SSR en Cloudflare Workers
Tanto Astro como Next.js compilan a un runtime compatible con Workers. El coste por modo:
- Estático en el edge. Cloudflare Pages sirve HTML plano casi sin CPU por petición. El modo más barato.
- ISR. La primera petición tras la invalidación paga el coste completo de renderizado; las peticiones en caché, casi nada. Workers cubre ambos casos.
- SSR. Cada petición paga en Workers el coste completo de renderizado. Previsible por petición, caro a escala.
La diferencia de coste importa con mucho tráfico. Con poco tráfico, decide la corrección, no el coste.
Ejemplos de ISR y SSR en rutas reales de WordPress
Portada de marketing. Estática, reconstruida por webhook en cada publicación editorial. Caché de 24 horas en el edge con opción de purga manual. SSR como alternativa solo si se añade un banner específico por país.
Ficha de producto en WooCommerce. ISR con el ID del producto como clave. Webhook de WooCommerce ante cambios de stock, de precio o de contenido. Ventana de caché: 1 hora como red de seguridad. SSR solo si mostrar el stock en tiempo real es un requisito de UX.
Historial de pedidos del cliente. SSR. Por usuario, dependiente de la sesión, sin caché en el edge.
La misma arquitectura, tres modos de renderizado distintos, una sola regla de decisión.
Guías relacionadas sobre WordPress headless
Este artículo forma parte del pilar del servicio headless WordPress. Para la elección a nivel de framework, consulte la matriz de decisión Next.js o Astro.
La parte de implementación de este tema la llevamos dentro de la auditoría Core Web Vitals.
