Cuando trabajas con Incremental Static Generation (ISG) en Next.js, entender cómo y cuándo se actualizan las páginas es fundamental para ofrecer contenido fresco sin sacrificar rendimiento. El mecanismo que orquesta este comportamiento se llama stale while revalidate, y su lógica es más elegante de lo que parece a primera vista.
¿Cómo responde Next.js con páginas desde el caché?
Imagina que ya ejecutaste el build de tu proyecto y todas las páginas están generadas y listas en el servidor. Cada vez que un usuario accede al sitio, Next.js responde directamente con esas páginas pre-construidas [0:18]. Esto se conoce como respuesta desde el caché: el servidor no necesita procesar nada nuevo, simplemente entrega lo que ya existe.
Esta estrategia es extremadamente rápida porque no hay consultas adicionales ni tiempo de renderizado. El usuario recibe el HTML completo de forma casi instantánea.
¿Qué sucede cuando el contenido cambia en el CMS?
Supongamos que alguien modifica un título en Contentful, agrega una nueva entrada o actualiza el contenido de una página existente [0:38]. Aquí es donde el enfoque stale while revalidate muestra su valor:
- Next.js detecta que hay contenido nuevo y comienza a descargar y construir la página actualizada en segundo plano (background).
- Mientras tanto, cualquier request que llegue se responde con la versión anterior de la página, la que ya estaba en caché [0:52].
- El usuario no experimenta interrupciones ni tiempos de carga adicionales.
- Una vez que Next.js termina de generar la nueva versión, las siguientes peticiones recibirán el contenido actualizado.
El término stale hace referencia a que se sirven páginas "vencidas" del caché, y while revalidate indica que, en paralelo, Next.js está verificando y reconstruyendo lo que haya cambiado [1:08].
¿Cuánto tarda en reflejarse una actualización?
El tiempo que transcurre entre el cambio de contenido y la disponibilidad de la nueva página corresponde exactamente al valor de la propiedad revalidate [1:22]. En el peor de los casos, el usuario deberá esperar esa cantidad de segundos o minutos para ver la versión más reciente.
Por ejemplo, si configuraste revalidate en cinco minutos, un usuario que visite la página justo después de un cambio podría ver la versión antigua durante ese periodo [1:35].
¿Se puede configurar un valor distinto por cada página?
Sí, y esta es una de las ventajas más prácticas. Puedes asignar valores de revalidate diferentes según la importancia de cada página [1:50]:
- Páginas estáticas como "contáctenos" o "acerca de nosotros" pueden tener un revalidate alto: diez minutos, una hora o incluso más.
- Páginas con información crítica, como las de productos, pueden configurarse con un revalidate de apenas un segundo [2:06].
- Con un segundo de revalidación, en el peor escenario el usuario ve contenido con apenas un segundo de desfase.
¿Los usuarios pierden experiencia durante la regeneración?
La respuesta es no. Mientras Next.js descarga y construye la nueva versión de una página, los usuarios siempre reciben contenido [2:18]. Nunca van a encontrar una página en blanco o un error de carga. Lo único que varía es qué tan actualizada está la información que están viendo.
Este balance entre frescura del contenido y velocidad de respuesta es precisamente el tradeoff central de ISG. Configurar correctamente el valor de revalidate te permite decidir, página por página, cuánto estás dispuesto a esperar para que un cambio sea visible, sin comprometer jamás la experiencia del usuario.
¿Has experimentado con distintos valores de revalidate en tus proyectos? Comparte tu experiencia y cómo decidiste los tiempos para cada tipo de página.
