La directiva HTTP Cache-Control stale-while-revalidate permite a los navegadores servir contenido en caché de inmediato mientras lo revalidan de forma asíncrona en segundo plano. Esta característica es un método principal para mejorar el rendimiento del sitio al reducir el tiempo que los usuarios pasan esperando a que se descargue contenido nuevo del servidor. Al configurar esta cabecera, instruyes al navegador para que muestre una versión existente y en caché de una página o recurso si todavía está dentro de la ventana obsoleta, mientras el navegador comprueba simultáneamente en el servidor si hay una versión más nueva.
¿Por qué deberías usar stale-while-revalidate?
El rendimiento web depende en gran medida de minimizar la latencia para los visitantes recurrentes. En una cuenta típica, un usuario puede visitar una página de aterrizaje varias veces al día. Si tus cabeceras de caché son demasiado estrictas, el navegador le pide constantemente confirmación al servidor, lo que ralentiza la experiencia. El uso de stale-while-revalidate equilibra eficazmente la necesidad de datos frescos con la velocidad del almacenamiento en caché local. Mantiene la interfaz de usuario ágil al evitar la necesidad de esperar una respuesta de red durante la fase de renderizado inicial de un recurso.
Esta directiva es especialmente útil para activos que no requieren una precisión perfecta a nivel de milisegundos. Por ejemplo, considera una página de precios de productos o un feed de blog que se actualiza unas cuantas veces al día. Al utilizar esta directiva, permites que el navegador muestre el contenido en caché de inmediato. Si ese contenido es más antiguo que tu max-age especificado pero está dentro de la ventana stale-while-revalidate, el navegador busca la actualización en segundo plano. El usuario ve la página al instante y, la próxima vez que la visite, verá los nuevos datos.
¿Cuál es la sintaxis de la directiva?
La directiva se implementa a través de la cabecera HTTP Cache-Control. Defines un max-age para indicar al navegador durante cuánto tiempo se considera fresco el contenido y, a continuación, añades el parámetro stale-while-revalidate. Por ejemplo, una configuración común tiene este aspecto: Cache-Control: max-age=60, stale-while-revalidate=3600. Esta configuración indica al navegador que el recurso está fresco durante 60 segundos. Si se produce una solicitud después de 60 segundos pero antes de 3600 segundos, el navegador sirve el contenido obsoleto e inicia una recuperación en segundo plano.
- max-age: Establece la duración durante la cual el contenido se considera fresco.
- stale-while-revalidate: Establece la ventana de tiempo después de que expire el max-age en la que el navegador puede usar contenido obsoleto mientras obtiene una actualización.
- Privado frente a Público: Estas cabeceras se pueden combinar con directivas privadas o públicas para controlar dónde se almacena el contenido, como en la caché del navegador frente a una caché CDN compartida.
Cómo configurar tu servidor para esta cabecera
Para implementar esto en tu servidor, debes modificar las cabeceras de respuesta enviadas al cliente. Si estás utilizando Nginx, ajustarías tu archivo de configuración dentro del bloque location para tus activos estáticos o endpoints de API. Una línea de ejemplo sería: add_header Cache-Control ‘public, max-age=86400, stale-while-revalidate=86400’;. Este enfoque garantiza que tu servidor comunique claramente la estrategia de almacenamiento en caché a cada navegador que solicite tus recursos, lo que lleva a una experiencia más coherente para tus usuarios finales.
Para los desarrolladores que usan Apache, puedes utilizar el módulo mod_headers para lograr el mismo resultado. Agregarías una línea a tu archivo .htaccess como: Header set Cache-Control ‘max-age=604800, stale-while-revalidate=86400’. Una vez implementados estos cambios, es una buena práctica verificar las cabeceras de respuesta en las herramientas de desarrollo del navegador. Abre la pestaña Red, actualiza la página y selecciona el recurso para confirmar que el valor de Cache-Control coincide con la configuración prevista.
Comparación de estrategias de almacenamiento en caché
| Estrategia | Velocidad inmediata | Frescura |
|---|---|---|
| Caché estándar | Alta | Baja |
| No-Cache | Baja | Alta |
| Stale-While-Revalidate | Alta | Alta |
Cómo aplica Alien Road stale-while-revalidate
En Alien Road, a menudo revisamos las métricas de rendimiento de los clientes al construir u optimizar interfaces web. En un compromiso típico, primero examinamos los tiempos de respuesta actuales del servidor y la naturaleza del contenido que se sirve. Si identificamos que un sitio depende de activos estáticos o datos a los que se accede con frecuencia que cambian lentamente, recomendamos implementar esta directiva. Nos aseguramos de que la implementación no entre en conflicto con los requisitos de seguridad, especialmente para páginas que contienen datos de usuario sensibles.
Nuestro proceso implica verificar las configuraciones de cabecera existentes y probar los tiempos de carga en diferentes navegadores. Luego ajustamos los intervalos de max-age y stale-while-revalidate en función de la frecuencia de actualización específica del contenido. Por ejemplo, un sitio de noticias puede requerir intervalos más cortos, mientras que la página de un portafolio corporativo podría beneficiarse de otros más largos. Documentamos esta configuración para que el equipo del cliente entienda por qué ciertos activos aparecen en caché y cómo las actualizaciones en segundo plano afectan la experiencia general del usuario.
¿Qué activos son los más adecuados para este enfoque?
No todos los activos de tu sitio web son candidatos para stale-while-revalidate. Debes priorizar los activos que no son críticos para la seguridad inmediata o aquellos en los que un ligero retraso en la actualización del contenido es aceptable. Las imágenes, los archivos CSS, los paquetes de JavaScript y las respuestas de API semiestáticas son candidatos ideales. Al utilizar esta directiva en estos archivos, reduces la carga en tu servidor de origen y garantizas que los visitantes reciban los tiempos de renderizado más rápidos posibles.
- Archivos CSS y JavaScript: Rara vez cambian lo suficientemente drásticamente como para requerir actualizaciones instantáneas.
- Imágenes de productos: Almacenarlas con una ventana de revalidación larga ahorra un ancho de banda significativo.
- Feeds de datos JSON: Los datos no sensibles que se actualizan periódicamente funcionan bien con la revalidación en segundo plano.
Errores comunes que se deben evitar
Un error frecuente es establecer la ventana de revalidación demasiado larga para contenido que requiere alta precisión. Si un usuario espera ver el precio de una acción en tiempo real o una alerta crítica, servir contenido obsoleto puede ser contraproducente. Evalúa siempre el impacto comercial de servir información que tiene minutos u horas de antigüedad. Además, evita aplicar esto a tokens de autenticación o tokens CSRF, ya que estos deben estar siempre frescos para evitar vulnerabilidades de seguridad durante el envío de formularios o acciones de la cuenta.
Por dónde empezar esta semana
Empieza identificando los cinco recursos estáticos más accedidos en tu sitio web. Utiliza las herramientas de desarrollo de tu navegador para inspeccionar la cabecera Cache-Control actual de cada uno. Si ves un max-age sin un componente stale-while-revalidate, calcula una ventana de revalidación adecuada en función de la frecuencia con la que cambia ese archivo específico. Aplica el cambio a la configuración de tu servidor en un entorno de ensayo (staging) primero para verificar que el comportamiento del navegador coincide con tus expectativas antes de implementarlo en tu sitio de producción en vivo.
Preguntas frecuentes
¿Funciona esto en todos los navegadores?
La mayoría de los navegadores modernos admiten la directiva stale-while-revalidate. Dado que forma parte de la especificación estándar Cache-Control, los navegadores que no reconocen el parámetro simplemente lo ignorarán y seguirán las instrucciones estándar de max-age. Esto la convierte en una mejora progresiva y segura para añadir a tu estrategia de caché existente sin romper la experiencia para los navegadores más antiguos que pueden no admitir el proceso de revalidación en segundo plano.
¿Puedo usar esto con una CDN?
Sí, muchas Redes de Entrega de Contenido (CDN) modernas admiten stale-while-revalidate. Cuando una CDN recibe esta cabecera de tu servidor de origen, puede almacenar el contenido en caché y gestionar el proceso de revalidación en segundo plano por sí misma. Esto es muy eficaz para reducir el tráfico de origen. Consulta la documentación de tu proveedor de CDN para confirmar si admiten esta directiva y si se requiere algún paso de configuración específico para habilitarla en la capa perimetral (edge layer).
¿Qué pasa si la actualización en segundo plano falla?
Si la solicitud de revalidación en segundo plano falla, el navegador normalmente seguirá utilizando la versión obsoleta del contenido que ya tiene en su caché. La experiencia del usuario no se interrumpe, ya que el navegador no muestra ningún error al visitante. La próxima vez que el usuario solicite el recurso, el navegador puede intentar el proceso de revalidación nuevamente, dependiendo de la lógica interna del navegador y el estado de la caché.
¿Es esto mejor que la validación ETag?
Estos dos métodos sirven para propósitos diferentes. La validación ETag requiere un viaje de ida y vuelta al servidor para comprobar si el contenido ha cambiado, lo que todavía introduce cierta latencia. La directiva stale-while-revalidate elimina esa latencia por completo al mostrar el contenido en caché de inmediato. Puedes utilizarlos juntos para garantizar que, incluso cuando se revalida la caché, el navegador solo descargue la carga útil completa si el contenido realmente ha cambiado, ahorrando aún más ancho de banda.
Sigue leyendo: Diseño y desarrollo web · Diseño web