Actualizar CSS y JavaScript almacenados en la caché del navegador

Si un despliegue cambia CSS o JavaScript pero mantiene la misma URL, algunos navegadores pueden reutilizar una copia todavía vigente. Las cabeceras nuevas solo se reciben cuando el navegador vuelve a solicitar esa URL: el servidor no puede vaciar a distancia una respuesta que el cliente aún considera fresca.

Comprueba primero en Red / Network de las herramientas del navegador qué URL carga, su estado, Cache-Control, Age, ETag y si responde el navegador, un service worker o una CDN. Así distingues la caché HTTP de otras capas.

Cambia la URL del activo

La solución fiable es publicar cada versión con una URL nueva. Preferiblemente utiliza nombres con un hash del contenido:

<link rel="stylesheet" href="https://static.example.com/css/app.abc123.css">
<script src="https://static.example.com/js/app.abc123.js"></script>

También puedes añadir una versión a la URL, por ejemplo /css/app.css?v=20260825, si tu aplicación y las cachés intermedias respetan parámetros de consulta.

Sirve el HTML no versionado con Cache-Control: no-cache para que se revalide y apunte a los activos nuevos. no-cache permite almacenar, pero exige validar antes de reutilizar. Conserva ETag o Last-Modified: permiten responder 304 Not Modified sin descargar de nuevo un recurso idéntico.

Los activos con hash pueden usar una caducidad larga porque su URL cambia con el contenido. Si existe una CDN o un service worker, actualiza también su manifiesto o ejecuta la purga específica de esa capa. No mantengas durante semanas reglas globales no-store, no elimines validadores y no uses Pragma como sustituto general de Cache-Control.

Consulta la guía de caché HTTP y URLs versionadas y la referencia de Cache-Control.

Evitar que un despliegue rompa sesiones abiertas

Publica primero los archivos nuevos y después el HTML que los referencia. Conserva durante un periodo de transición los activos de la versión anterior: una pestaña abierta puede seguir solicitándolos. Borrarlos de inmediato puede provocar 404 aunque las visitas nuevas funcionen.

Si la aplicación utiliza un service worker, prueba una actualización con una pestaña antigua abierta y otra nueva. El HTML dinámico o privado puede necesitar una política distinta del HTML público; no apliques una cabecera global sin revisar sesiones y datos sensibles.

Comprueba la URL final, el contenido recibido y la versión tras el despliegue. Una respuesta 304 puede ser correcta cuando el recurso no ha cambiado; no es por sí sola un síntoma de caché defectuosa.