Aplica la política al recurso, no al servidor
Haz un inventario de URLs representativas antes de cambiar cabeceras: página de inicio, página de contenido, shell de aplicación, CSS, JavaScript, imágenes, fuentes, APIs, login, cuenta, checkout y descargas. Para cada una, anota si la respuesta es pública o personalizada, si su URL cambia cuando cambian sus bytes y qué tan rápido debe llegar una corrección a los visitantes.
Crea una matriz de políticas a partir de ese inventario. Un activo público direccionado por contenido necesita una regla distinta al HTML en una dirección estable. Las respuestas sin Cache-Control todavía pueden almacenarse de forma heurística, así que las reglas explícitas son más fáciles de probar.
El periodo durante el cual una respuesta almacenada puede reutilizarse; max-age lo da en segundos.
Usa los términos de Cache-Control con precisión
Cache-Control indica a navegadores y caches compartidas cómo almacenar y reutilizar una respuesta. max-age=N permite la reutilización mientras esté fresca. s-maxage=N establece la frescura para caches compartidas y sobrescribe max-age allí, pero los navegadores ignoran s-maxage. public permite cualquier caché; private permite caché en el navegador pero evita el almacenamiento en caches compartidas.
no-cache permite el almacenamiento pero requiere validación con el origen antes de reutilizar. no-store significa que las caches no deben almacenar la respuesta, pero no es un control de privacidad completo. Usa must-revalidate cuando servir contenido obsoleto tras la expiración sea inaceptable; un origen no disponible puede entonces devolver 504 en lugar de un recurso obsoleto.
Elimina el almacenamiento en lugar de solamente requerir una comprobación; resérvalo para respuestas que realmente no deben almacenarse.
Versiona activos inmutables antes de asignarles una larga duración
Una URL de activo versionada incluye una huella de contenido o versión de release, por ejemplo app.4f2c.js. Cuando los bytes del activo cambian, publica una URL distinta y actualiza la referencia en el HTML. La caché ve un recurso nuevo, así que los visitantes obtienen el nuevo activo sin que una invalidación alcance cada navegador.
Para una representación que no cambiará durante su vida de frescura, Cache-Control: max-age=31536000, immutable es un patrón práctico. immutable indica a clientes que lo soporten que no revaliden condicionalmente mientras esté fresca. No lo apliques ni uses un max-age de un año para un archivo mutable con la misma URL. Conserva los activos fingerprinted anteriores mientras el HTML en caché aún pueda referenciarlos.
El HTML elige las URLs de los activos, así que la secuencia de releases debe conservar la generación referenciada.
Mantén el HTML actual mediante validación, no mediante caché largo
El HTML suele tener una URL estable y visible para humanos y cambia con el contenido, referencias a activos, flags de funciones o avisos de seguridad. Un patrón conservador para HTML público es Cache-Control: no-cache con ETag y Last-Modified cuando tu plataforma puede producirlos correctamente. El navegador almacena el cuerpo pero usa una petición condicional antes de reutilizar; una respuesta sin cambios puede retornar 304 Not Modified sin cuerpo.
ETag identifica una versión de recurso. Sobre una respuesta obsoleta, el navegador puede enviarla en If-None-Match; si coincide, el servidor responde 304, de lo contrario envía la nueva representación. La guía de RFC prefiere tanto ETag como Last-Modified en una respuesta 200 cuando sea posible. no-cache no garantiza validación en navegación Atrás o Adelante porque un navegador puede restaurar una instantánea del historial de sesión.
Un ETag debe cambiar cuando la representación cambia; pruébalo entre orígenes y despliegues.
Separa la entrega pública de respuestas personalizadas y sensibles
Un cache compartido, como un CDN, puede reutilizar una respuesta para múltiples usuarios. No permitas que almacene HTML o datos de API específicos de cuenta para distintos usuarios. Para contenido personalizado que puede residir en el navegador, private, no-cache es un punto de partida sensato: evita el almacenamiento compartido y requiere validación. Un header Set-Cookie por sí solo no detiene el caching.
Para respuestas que no deben almacenarse, usa no-store y revisa el código de la aplicación, reglas del CDN, service workers, almacenamiento del navegador, registros y páginas de error. Solo las cabeceras no constituyen un programa de privacidad, cumplimiento o seguridad de pagos. Haz que revisores cualificados de seguridad, privacidad y pagos evalúen los flujos sensibles y los requisitos aplicables.
Prueba sign-in, sign-out, cambio de cuenta y cambios de permisos con caches de navegador y CDN calientes.
Despliega cambios de caché como un release reversible
Captura cabeceras base y comportamiento del cuerpo para peticiones sin caché y repetidas. En staging, despliega activos versionados primero, luego el HTML que los referencia, y prueba HTML en caché más antiguo contra el nuevo origen. Revisa rutas directas al origen y rutas CDN si ambas existen. Las cabeceras en DevTools Network deben mostrar la política prevista y el comportamiento en repeticiones.
Mantén un manifiesto de release con las URLs de activos, reglas de cabeceras y la versión de configuración. Si un release combina archivos de cliente incompatibles, restaura HTML y comportamiento de aplicación compatibles, pero no sobrescribas un archivo fingerprinted publicado. Reapunta el HTML a la generación conocida como buena y conserva ambas generaciones mientras el HTML en caché pueda solicitarlas. Una purga de cache compartida no puede forzar a los navegadores a descartar una respuesta fresca.
Convierte fallos en pruebas de cabeceras, 404s de activos y desajustes de versiones en cambios para la siguiente checklist de release.