⚡ Analizador de Cache Headers
Analiza Cache-Control, ETag, Expires, Vary, Age — max-age / s-maxage en formato legible. Auto-detecta CDNs principales.
📚 Referencia Cache-Control
• public: Cacheable por cualquier caché
• private: Solo navegador
• no-store: Nunca cachear
• no-cache: Puede cachear pero debe revalidar
• max-age=N: Válido N segundos
• s-maxage=N: max-age solo para cachés compartidas
• immutable: Sin revalidación incluso al recargar
• stale-while-revalidate=N: Sirve stale N segundos mientras revalida
• stale-if-error=N: Sirve stale N segundos en error de origen
📖 Qué te dice este diagnóstico
Este diagnóstico extrae Cache-Control, ETag, Last-Modified, Expires y las cabeceras propias del CDN, y desglosa las directivas. Sólo puede decirte qué estás instruyendo, no qué se ha cacheado de verdad. Un navegador con poco espacio descarta al margen de tus instrucciones, y un CDN puede sobrescribirlas con sus propias reglas.
| Elemento | Qué significa | Cómo corregirlo |
|---|---|---|
| Sin Cache-Control | No decir nada no significa sin cachear: la caché puede inventarse una vida útil (caché heurística). Cuando hay Last-Modified, lo habitual es tomar como fresco alrededor del 10 % del tiempo transcurrido desde esa fecha. Para una página editada hace un año, eso es cerca de un mes de caché que nunca pediste. |
Sé explícito en cada respuesta. Tres patrones cubren casi todo: no-cache para HTML (guárdalo, pero revalida siempre), max-age=31536000, immutable para recursos con hash de contenido y private, no-store para respuestas con datos personales. Pese a los nombres confusos, no-cache guarda y no-store no. |
| max-age largo en un archivo mutable | Pon un max-age de un año en un nombre fijo como style.css y los visitantes existentes no verán la actualización durante un año. Peor aún, una caché ya entregada al navegador no se puede revocar desde el servidor: una purga de CDN llega al borde y no más allá. |
Usa un TTL largo sólo junto a un diseño donde el nombre del archivo cambie al actualizar: un hash de contenido en el nombre, como app.4f2c1a.css, reescribiendo la referencia en el HTML. Así immutable es seguro y ni siquiera una recarga revalida. Si ya repartiste un TTL largo, renombrar el archivo y dar por perdido el antiguo es la única salida. |
| public en una respuesta personalizada | Cuando una página con el nombre de sesión o el contenido del carrito lleva public —o s-maxage—, una caché compartida la guarda y se la sirve tal cual al siguiente visitante, que es otro. Mostrar a un usuario los datos personales de otro es el peor desenlace posible de un error de caché, y suele aflorar justo después de introducir un CDN. |
Devuelve Cache-Control: private, no-store en las respuestas autenticadas. Vary: Cookie las separa en teoría, pero crea una entrada por valor de cookie, así que la caché deja de funcionar en la práctica y el CDN no te aporta nada. Separar el tráfico anónimo del autenticado por ruta o subdominio, y hacer cacheable sólo el primero, es un diseño más fiable. |
Lo peligroso de la caché es que un error se te escapa de las manos y sigue vivo. Corregir la configuración no revoca instrucciones ya repartidas, y por eso la regla es empezar corto y alargar después si dudas. Añadir stale-while-revalidate permite servir la copia antigua mientras se refresca en segundo plano en vez de hacer esperar justo al caducar, así que un max-age corto no cuesta velocidad percibida. Con CDN, un max-age corto para navegadores y un s-maxage largo para el borde, refrescado por purga, es la combinación más manejable.