Actualizar JavaScript y CSS sin servir versiones antiguas desde caché

Separa el HTML de los recursos versionados

Piensa en el HTML como un manifiesto. La versión A usa app.4c21.js y site.19ab.css; B usa app.9d80.js y puede conservar el CSS si sus bytes no cambiaron. Estos nombres son ilustrativos, no hashes calculados.

Así se reutiliza contenido idéntico y cambia la identidad del contenido modificado. Si el HTML se almacena durante un año, puede seguir apuntando a archivos antiguos aunque el servidor ya tenga una publicación nueva.

Configura cabeceras coherentes con ese contrato

Para un recurso público que nunca cambiará en esa URL, max-age largo e immutable pueden ser adecuados. En HTML, no-cache permite almacenar, pero exige validar antes de reutilizar; no-store solicita no almacenar. Elige por recurso, no copies una cabecera a todo el sitio.

Las cabeceras mostradas son una estrategia de ejemplo. Comprueba qué envían realmente el alojamiento y su caché perimetral. Un archivo local de configuración no demuestra lo recibido por navegador y CDN.

Versioned public asset: /assets/app.9d80.js
Cache-Control: public, max-age=31536000, immutable

HTML document: /index.html
Cache-Control: no-cache

The URL /assets/app.9d80.js must continue to serve the same bytes.

Verifica que la caché distingue las consultas

/app.js?v=release-b puede distinguirse de /app.js?v=release-a si todas las cachés relevantes incluyen la consulta en su clave. Una regla CDN que ignore parámetros puede convertir ambas en el mismo objeto.

No generes un valor aleatorio en cada visita: elimina la reutilización útil. Usa un hash o versión estable que cambie con el recurso. Un fragmento como /app.js#release-b no viaja en la solicitud HTTP y no sirve para este propósito.

Localiza la capa que devuelve bytes antiguos

Compara HTML, URL referenciada y contenido recibido. Si el HTML conserva el hash viejo, revisa su frescura. Si referencia el nuevo y llegan bytes antiguos, revisa publicación, claves de caché y origen. Si la red es correcta pero el comportamiento no, busca una página ya ejecutándose o un service worker.

Purgar la CDN no elimina respuestas frescas ya guardadas en cada navegador. Una recarga forzada solo diagnostica ese navegador. Anota qué capa has omitido en cada prueba para poder reproducir el resultado.

• Registra URL final del HTML y del script o CSS.
• Revisa estado, Content-Type, Cache-Control, ETag y cabeceras de caché.
• Confirma que llega el archivo previsto y no una página HTML de respaldo.
• Comprueba por separado las reglas del service worker, si existe.
• Prueba una visita limpia y una pestaña abierta durante el cambio.

Conserva compatibilidad al publicar y revertir

Sube los archivos nuevos antes del HTML que los referencia, o publica el conjunto de forma atómica. Conserva los anteriores para documentos almacenados y pestañas abiertas: una página puede solicitar un módulo horas después.

Publica B manteniendo recursos de A y B, verifica B y conserva la posibilidad de volver a A. Borrar app.4c21.js de inmediato rompe documentos antiguos. Reutilizar ese nombre para bytes nuevos rompe el contrato y complica la reversión.

Mide la reutilización cuando todo funcione

Prueba primera visita, repetición y nueva publicación: descarga inicial, reutilización permitida y descarga únicamente de versiones modificadas. Inspecciona transferencias reales, incluidas revalidaciones; no todas las respuestas de caché son equivalentes.

Las calculadoras de ahorro de caché y transferencia ayudan a comparar supuestos explícitos sobre aciertos, solicitudes y tamaño. No sustituyen medir cabeceras públicas y tasa real de aciertos.