Ir al contenido 
Te voy a enseñar cómo configurar el encabezado HTTP Control de la caché lo utiliza de forma específica para reducir los tiempos de carga, ahorrar solicitudes y gestionar eficazmente las cachés del navegador. Obtendrás directrices claras, combinaciones útiles y ajustes prácticos para HTML, CSS, JS, imágenes y API, sin tener que ir a ciegas, sino con concreto En unos sencillos pasos.
Puntos centrales
Los siguientes aspectos fundamentales te guiarán sin duda hacia una rápida y fiable Estrategia de caché.
- max-age como temporizador: controla el tiempo de conservación en segundos
- público/privado: determina quién puede almacenar datos en caché
- no-cache vs. no-store: revalidar en lugar de prohibir
- ETag y Última modificación: Las descargas condicionales ahorran datos
- Versionado + inmutable: cachés largos sin residuos históricos
Conceptos básicos: ¿Para qué sirve el encabezado Cache-Control?
El encabezado contiene instrucciones que determinan si se envía una respuesta en el Cache puede estar. Distingo entre las cachés del cliente en el navegador y las cachés compartidas, como los servidores proxy o las CDN, que suelen dar servicio a varios usuarios y, por lo tanto, suponen una Eficacia . Mientras que el encabezado „Expires“, ya obsoleto, utiliza una fecha, yo utilizo en «Cache-Control» intervalos de tiempo relativos mediante «max-age», lo cual es menos propenso a errores. De este modo, determino cuánto tiempo un recurso permanece «actualizado» y si debe revalidarse antes de su uso. De este modo, me reservo la opción de controlar los contenidos dinámicos y de mantener los archivos estáticos almacenados localmente durante mucho tiempo.
Cache-Control se aplica tanto en las respuestas como en las solicitudes, lo que me resulta útil para la revalidación, por ejemplo, en combinación con ETag o Last-Modified para Condicional Solicitudes. Por ejemplo, establezco valores agresivos para los activos sin modificar y reglas conservadoras para el HTML. Esta separación garantiza que las solicitudes posteriores procedan, en la medida de lo posible, de la caché del navegador y, por lo tanto, la Carga del servidor disminuye. Es importante que haya una coordinación planificada para no bloquear recursos sin querer ni agotarlos antes de tiempo. Quien tenga en cuenta estos principios sentará las bases para unos tiempos de carga cortos y unas reglas claras en el comportamiento de la caché.
Directivas importantes explicadas de forma clara
Con max-age Establezco la vida útil de un recurso en segundos, contados a partir de su entrega. Para imágenes, CSS, JS y fuentes, suelo elegir 31536000 (un año), de modo que en las visitas posteriores se utilice casi todo de forma local. Para las páginas HTML establezco un tiempo más corto, unos 300 segundos, o las combino con la revalidación, para que los cambios se vean rápidamente. Una validez prolongada sin versionado de archivos conduce fácilmente a que queden versiones antiguas en la caché, por lo que varío los nombres de los archivos en cada lanzamiento. De este modo, combino una actualización rigurosa con alta Porcentaje de aciertos en la caché.
Las directivas público y privado controlar quién puede almacenar en caché. Asigno el valor «Público» a los contenidos sin personalización, para que también los servidores proxy y las CDN los almacenen en caché. Asigno el valor «Privado» cuando solo el navegador del usuario debe conservar una copia, por ejemplo, en las páginas de cuentas. De este modo, evito que los datos personales acaben en cachés compartidas y allí salirse mal. Esta distinción evita problemas y protege la información confidencial.
no-cache A menudo se interpreta erróneamente: no prohíbe el almacenamiento, pero exige una revalidación con el servidor antes de volver a utilizar el contenido. Esto resulta adecuado para contenidos que cambian con regularidad, sin necesidad de recargarse por completo cada vez que se acceden. Con ETag o Last-Modified, el cliente guarda los datos localmente y solo comprueba si siguen estando actualizados. De esta forma, evito bytes innecesarios y, aun así, mantengo la Contenido fresco. Sin embargo, para datos altamente sensibles, la opción «no-cache» resulta demasiado laxa.
no-store Es la medida más estricta, ya que prohíbe cualquier tipo de almacenamiento en el navegador y en los servidores proxy. Lo utilizo para páginas de inicio de sesión, procesos de pago o documentos con datos confidenciales. De este modo, no quedan copias en carpetas temporales que puedan caer accidentalmente en manos equivocadas. Cuando utilizo «no-store», suelo combinarlo con «max-age=0» para evitar cualquier reutilización excluir. En este caso, la seguridad prima sobre el rendimiento.
debe revalidarse Obliga a consultar al servidor tan pronto como expire el plazo. Si el servidor deja de estar disponible, la caché no debe seguir sirviendo el recurso sin más. Esta directiva es adecuada para ámbitos en los que la coherencia es más importante que una estrategia de tolerancia a fallos flexible. La utilizo cuando los datos obsoletos podrían dar lugar a decisiones erróneas. La regla establece claramente Carácter vinculante durante el proceso.
Directrices ampliadas para las cachés compartidas y la fiabilidad
Además de la configuración básica, utilizo s-maxage, stale-while-revalidate y stale-if-error, para gestionar de forma específica los servidores proxy y las CDN, y ofrecer a los usuarios un servicio fluido incluso en caso de incidencias. s-maxage Establece un TTL propio solo para las cachés compartidas (los navegadores lo ignoran). Así, por ejemplo, puedo mantener un tiempo de caché corto en el navegador (max-age=600), pero más largo en el perímetro (s-maxage=86400). stale-while-revalidate permite que las cachés sigan sirviendo contenidos caducados durante un tiempo determinado, mientras que la actualización ya se está llevando a cabo en segundo plano. stale-if-error se activa en caso de errores (por ejemplo, 500/tiempo de espera agotado) y protege la experiencia del usuario mostrando una versión ligeramente anterior, en lugar de mostrar un error grave.
Un modelo práctico para respuestas de API públicas que rara vez se modifican o para mapas de sitio en formato JSON tiene el siguiente aspecto: Cache-Control: public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600. De este modo, los navegadores se mantienen relativamente actualizados, las CDN son eficientes y los usuarios no notan ni breves interrupciones ni retrasos en las revalidaciones. Dejo deliberadamente al margen de estas directrices flexibles las áreas críticas o personalizadas.
Interacción con «Expires», «ETag» y «Last-Modified»
Utilizo Expira en Como último recurso, ya que Cache-Control permite un control más preciso y tiene prioridad cuando ambos están configurados. Con ETag proporciono una huella digital única del recurso, de modo que el navegador pueda iniciar una revalidación sencilla mediante If-None-Match. «Last-Modified» proporciona la fecha y la hora de la última modificación y funciona en combinación con «If-Modified-Since». Ambas opciones ahorran ancho de banda, ya que, si el contenido no ha cambiado, el servidor solo devuelve el estado 304. Esta interacción mantiene los datos cerca del usuario y reduce Viajes de ida y vuelta.
¿Lo compro? Solicitudes condicionales, los costes por visita a la página se reducen considerablemente, sin que ello impida la publicación de contenidos nuevos. Esta técnica complementa los valores «max-age» reducidos en HTML y garantiza que las visualizaciones estén actualizadas. En cambio, en el caso de los recursos con control de versiones, me baso sobre todo en una validez prolongada y evito validaciones innecesarias. De este modo, aligero la carga del Servidor y agiliza notablemente las visitas posteriores. En definitiva, se crea una ruta de datos optimizada con reglas claras.
ETag/Last-Modified en la práctica: potente, débil y escalable
En configuraciones distribuidas, me aseguro de que los ETags coherente se calculen en todas las instancias. Los ETags basados en archivos que incluyen inodos provocan fallos innecesarios en los clústeres. Por eso, en Apache configuro deliberadamente el cálculo de ETag:
# Apache: ETags coherentes para archivos estáticos
FileETag MTime Size
# Opcional: eliminar el ETag predeterminado y establecer una lógica propia
#Header unset ETag
En Nginx, a menudo basta con etag activado; para archivos estáticos. Para dinámico Yo mismo genero los ETags de las respuestas, idealmente como un hash del cuerpo de la respuesta. Si necesito tolerancia ante pequeños cambios (por ejemplo, marcas de tiempo formateadas), utilizo ETags débiles (W/"..."), que permiten reconocer contenidos semánticamente idénticos a pesar de las diferencias en los bytes. Como opción alternativa, utilizo «Last-Modified», por ejemplo, con la fecha de actualización del registro. Importante: ETag y Last-Modified al mismo tiempo No pasa nada por ofrecerlo: el cliente elige qué es lo que admite.
Cómo utilizar Vary correctamente: personalización sin problemas de caché
Variar determina qué encabezados de solicitud se incluyen en la clave de caché. Mantengo «Vary» deliberadamente sencillo: Aceptación de codificación es el valor predeterminado (Gzip/Brotli), Aceptar idioma solo si doy respuestas específicas sobre la lengua. De Vary: User-Agent No lo recomiendo, porque hace que el tamaño de la caché se dispare. Si los contenidos dependen de las cookies, prefiero privado o no-store, en lugar de tener que gestionar un gran número de reglas de Vary. En el caso de los recursos, elimino las cookies innecesarias siempre que sea posible, para que público-El almacenamiento en caché en el borde entra en funcionamiento. Si utiliza una autenticación de API mediante encabezados, puede Vary: Autorización evitar que las cachés compartidas mezclen las respuestas de distintos usuarios; sin embargo, a menudo ocurre que privado La opción mejor y más clara.
Compruebo en DevTools si se establece „Vary“ de forma involuntaria (por ejemplo, por culpa de middlewares), ya que un «Vary» demasiado amplio reduce enormemente la tasa de aciertos. Unos pocos encabezados, elegidos a conciencia, mantienen la caché manejable y eficiente.
Estrategias según el tipo de contenido
Distingo claramente entre contenidos estáticos y dinámicos para poder aprovechar las ventajas de ambos. Los recursos estáticos tienen una vida útil prolongada y se identifican claramente mediante nombres de archivo versionados. Trato el HTML y los contenidos personales con mayor cautela, para que los cambios estén disponibles rápidamente y los datos no acaben en cachés erróneos. Clasifico las API según la frecuencia de los cambios y la sensibilidad de la información. Esta clasificación aporta Velocidad sin poner en riesgo la confidencialidad y Corrección.
La siguiente tabla resume los ajustes más prácticos y muestra sus ventajas de un solo vistazo.
| Tipo de recurso | Ejemplo de encabezado | Por qué | Nota |
|---|---|---|---|
| CSS/JS/Imágenes/Fuentes | Cache-Control: public, max-age=31536000, immutable | Uso prolongado de Caché del navegador, menos solicitudes | Nombrar los archivos con versiones para mantener un sistema ordenado Rodando Actualización |
| HTML no personalizado | Cache-Control: no-cache, must-revalidate (o max-age=300) | La actualidad sigue siendo elevada, mientras que el volumen de datos sigue siendo reducido | Con ETag/Last-Modified para una fácil revalidación |
| HTML personalizado | Cache-Control: private, no-cache, must-revalidate | No se almacena en cachés compartidas | Proteger los datos de la sesión y Fugas Evite |
| API estáticas / que cambian raramente | Cache-Control: public, max-age=3600 | Alta tasa de aciertos en muchos casos Clientes | Mantén la flexibilidad para realizar implementaciones frecuentes |
| API muy dinámicas / sensibles | Cache-Control: no-store, max-age=0 | No se deben almacenar datos confidenciales | Directo Actualidad en lugar de riesgo |
En el caso de galerías de imágenes, paquetes grandes de JS o fuentes web, los valores altos de «max-age» se amortizan rápidamente. Para ello, presto atención a las cadenas de versión en los nombres de los archivos, para que los usuarios nunca vean paquetes obsoletos. El HTML se mantiene conciso y recurre a la revalidación, de modo que incluso las pequeñas correcciones en los textos o los precios se publiquen rápidamente. Las API siguen sus propias reglas en función del perfil de uso y de la necesidad de cambios. Esta combinación ofrece resultados duraderos flota Visitas a la página y ahorra Ancho de banda.
SPA frente a MPA: HTML de índice corto, recursos largos
En el caso de las aplicaciones de una sola página, considero que la Índice HTML de vida especialmente corta (p. ej.,. no-cache, must-revalidate o max-age=60), ya que controla qué versión de los paquetes se carga. Por el contrario, todos los chunks, fuentes e imágenes compilados están estrictamente versionados y reciben público, max-age=31536000, inmutable. De esta forma me aseguro de que una nueva versión con el HTML de índice actualizado haga referencia inmediatamente a los nuevos nombres de archivo correctos, mientras que los usuarios actuales siguen utilizando el grandes Recuperar los recursos de su caché local.
Las cadenas de consulta como método para evitar el almacenamiento en caché (?v=123) Solo lo utilizo cuando no es posible cambiar fácilmente los nombres de los archivos. Es mejor utilizar nombres de archivo únicos (hashes), ya que segmentan las cachés de forma más precisa y generan menos casos especiales.
Configuración del servidor: Apache y Nginx
En Apache, suelo configurar los encabezados en el archivo .htacceso, siempre que el módulo mod_headers esté activo. A los recursos estáticos les asigno una validez prolongada, mientras que el HTML se trata de forma más estricta. En Nginx lo hago en bloques «location», a menudo junto con la directiva «expires» como alternativa. Compruebo cada cambio con DevTools en la pestaña «Red» para ver los valores reales de los encabezados. De este modo evito reglas erróneas que, de lo contrario, podrían acarrear costosas Consultas erróneas generar.
# Apache (.htaccess)
Header set Cache-Control "public, max-age=31536000, immutable"
Header set Cache-Control "no-cache, must-revalidate"
# Nginx (bloque de servidor)
location ~* \.(jpg|jpeg|png|gif|css|js|woff2?)$ {
expires 365d;
add_header Cache-Control "public, immutable";
}
location ~* \.(html)$ {
add_header Cache-Control "no-cache, must-revalidate";
}
Me aseguro de que no haya reglas contradictorias en los servicios de nivel superior que interfieran con estos encabezados. Por ejemplo, una CDN de nivel superior puede establecer sus propios TTL, lo cual debo controlar de forma deliberada. Si todos los niveles coinciden, los recursos se mantienen fiables. localizable y coherente. Si se revisa todo con cuidado, se evitan largas sesiones de depuración. Unas pequeñas comprobaciones ahorran mucho trabajo más adelante Tiempo.
Prácticas de CDN y proxy: configuración de «s-maxage» y estrategias «Stale»
Para las cachés de borde, añado lo siguiente a la configuración del servidor: s-maxage así como las directivas Stale. Ejemplo de Apache:
# Apache: Reglas optimizadas para CDN
Header set Cache-Control "public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600"
Y en Nginx:
# Nginx: Optimización de la caché compartida
location ~* \.(json|xml|map)$ {
add_header Cache-Control "public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600";
}
Muchas CDN respetan estas directrices directamente. Si tu capa periférica espera encabezados propios (por ejemplo, encabezados sustitutos), reproduzco allí la lógica y mantengo claramente separadas la estrategia del navegador y la de la caché compartida. Gracias al control de versiones, rara vez necesito purgas; si las necesito, las planifico como una intervención pequeña y específica.
Casos especiales: redireccionamientos, páginas de error y flujos de trabajo de formularios
Redireccionamientos: Las respuestas 301 pueden almacenarse en caché según la especificación. Cuando configuro redireccionamientos temporales (302/307), asigno tiempos de vida (TTL) claros o configuro deliberadamente no-store, para que nada quede fijado de forma definitiva. Las rutas 301 permanentes pueden tener un TTL moderado; en ese caso, los cambios se realizan de forma deliberada y coordinada.
Páginas con errores: Las respuestas 404/410 pueden almacenarse en caché durante un breve periodo de tiempo (por ejemplo,. max-age=60), para reducir la carga de los bots. Con los de 500, dependiendo del entorno, stale-if-error activa, para que los usuarios prefieran ver una página antigua que funcione antes que un mensaje de error.
PUBLICAR/Descargar: Por lo general, las respuestas a las solicitudes POST no se almacenan en la caché del navegador. Para las exportaciones de archivos que contienen datos personales (por ejemplo, facturas), configuro sistemáticamente no-store además de una entrega segura (por ejemplo, Content-Disposition), para que nada se mantenga almacenado por error. Por el contrario, las descargas grandes no personalizadas (por ejemplo, versiones nuevas) pueden aprovechar de forma útil las cachés públicas durante mucho tiempo.
Evite los errores típicos
Muchos confunden no-cache con „sin caché“, lo que genera una carga innecesaria. Como bien has leído, «no-cache» permite el almacenamiento en caché, pero exige la revalidación. Otro error clásico: valores de «max-age» muy largos sin versionado en CSS o JS, lo que mantiene archivos obsoletos. La falta de separación entre el HTML y los recursos estáticos merma la velocidad, ya que el HTML rara vez puede almacenarse en caché de forma agresiva. Quien ignore esto, ralentiza la Experiencia del usuario de.
Los conflictos entre el servidor, la CDN y la aplicación sabotean los efectos del almacenamiento en caché sin que nos demos cuenta. Por eso, comprueba las sobrescrituras y los niveles intermedios cuando los encabezados cambien „como por arte de magia“. En estos casos, resulta útil analizar la lógica y la cadena de respuestas para detectar prioridades erróneas. Una lista de comprobación concisa y los errores más comunes relacionados con Sabotear la cabecera de la caché facilitan el control. Establecer prioridades claras evita Efectos secundarios en las implementaciones.
Hacer cuantificable la mejora del rendimiento
Evalúo los efectos de Cache-Control mediante métricas como el TTFB, el LCP y el número de Solicitudes por visita a la página. Un vistazo a DevTools me permite ver si los archivos proceden de la „caché del disco“ o de la „caché de memoria“. Lighthouse, WebPageTest y otras herramientas similares indican si el almacenamiento en caché del navegador funciona de forma consistente. Realizo mediciones antes y después de cada cambio para poder ver claramente las mejoras reales. Esta disciplina garantiza las optimizaciones comprensible y con un objetivo claro.
Las imágenes de gran tamaño, las fuentes web y los paquetes tienen un impacto especialmente notable, ya que no se vuelven a cargar en visitas posteriores. Para ello, el código HTML permanece cerca del servidor, de modo que los usuarios reciben rápidamente los nuevos contenidos. Las API se benefician notablemente cuando las rutas más utilizadas tienen un TTL moderado. Los resultados se traducen en tiempos de carga más cortos, un menor volumen de datos y una carga del servidor más estable. Quien compruebe esto de forma sistemática, ahorrará a largo plazo. Recursos.
Service Worker y caché HTTP: evitar que funcionen en contra
Si utilizo un Service Worker, su estrategia debe coincidir con mis encabezados HTTP. Para los recursos estáticos y versionados, lo más adecuado es „cache-first“ con un TTL largo y inmutable Excelente. Para HTML o datos de API que cambian con frecuencia, prefiero „network-first“ o „stale-while-revalidate“, para que los usuarios vean las respuestas rápidamente y la información actualizada llegue sin demora. Importante: el Service Worker debe respetar las revalidaciones (transmitir «If-None-Match»/«If-Modified-Since»), en lugar de retener el contenido de forma artificial.
Además, quiero dejar claro lo siguiente: la caché HTTP ya puede encargarse de gran parte del trabajo; el Service Worker complementa ese comportamiento, no lo sustituye. De este modo, la depuración y el funcionamiento siguen siendo manejables.
Comprender las directivas del lado de la solicitud
Las solicitudes también pueden controlar el almacenamiento en caché. Cache-Control: no-cache en Solicitar fuerza una revalidación en el servidor, max-age=0 es parecido. no-store En la solicitud se prohíbe el almacenamiento de la respuesta a lo largo de la cadena. Para los casos sin conexión, se puede solo si está en caché Puede resultar útil: en ese caso, el cliente solo acepta respuestas procedentes de la caché. Este mecanismo resulta útil en aplicaciones que deben ofrecer una experiencia definida incluso con una conexión débil.
Buenas prácticas para tu flujo de trabajo
Empezaré por hacer un balance: qué tipos de archivos hay, cuáles están personalizados y cuáles rara vez cambian. A continuación, aplicaré reglas de forma diferenciada para que los activos permanezcan mucho tiempo en el Cache y el HTML se mantenga actualizado. Las cadenas de versión en el nombre del archivo eliminan el riesgo de paquetes obsoletos y permiten tiempos de ejecución más rápidos. Durante las ventanas de mantenimiento periódicas, compruebo los encabezados y las tasas de visitas para detectar las tendencias con antelación. Esta rutina mantiene el sitio performante y predecible.
Documento las configuraciones de forma breve y clara, para que los cambios futuros no provoquen errores involuntarios. Los scripts de implementación actualizan automáticamente los hash de los archivos, para que no se me olvide ningún paso. Para las versiones, utilizo implementaciones con alcance limitado para comprobar el comportamiento en el entorno real. La información obtenida de la monitorización y los registros se incorpora directamente a las reglas de encabezado. De este modo, la estrategia se mantiene realista y eficaz.
Control de versiones y activos inmutables
Añado hash a los nombres de los archivos, por ejemplo, app.20260817.js, y luego establezco «public», «max-age=31536000», inmutable. De este modo, el navegador sabe que el archivo nunca cambia „silenciosamente“ y se ahorra tener que volver a validarlo. En la siguiente versión, el archivo recibe un nuevo nombre, lo que hace que el navegador cargue exactamente la nueva versión. Así evito que haya versiones obsoletas tras una implementación. Esta táctica encaja bien con muchas Estrategias de control de caché las más diversas pilas.
Para HTML no utilizo «immutable», porque la página cambia a menudo y quiero una revalidación flexible. Lo mismo se aplica a las respuestas de las API con datos variables. Las fuentes y las imágenes grandes son las que más se benefician, ya que los usuarios las utilizan varias veces en distintos dispositivos. Sigue siendo importante una asignación completa de los hash a las versiones. La documentación y una clara Nombres evitar confusiones en el equipo y en las configuraciones.
Pasos prácticos para la comprobación y la depuración
Abro DevTools y, en la pestaña «Red», reviso los encabezados de la respuesta para comprobar Cache-Control, ETag, Expires y Variar para comprobarlo. Al volver a cargar la página sin caché (Ctrl+F5), puedo ver si las reglas se aplican realmente. A continuación, la cargo normalmente y compruebo qué elementos se obtienen de la caché. En el caso de los proxies y las CDN, compruebo los encabezados como «Age» o «X-Cache», si están disponibles. Estas comprobaciones detectan conflictos y errores Prioridades rápidamente.
A nivel de servidor, comparo la configuración y los registros para detectar discrepancias. Un error frecuente: una aplicación añade encabezados a posteriori y anula las reglas del servidor. En los procesos de CI/CD, compruebo automáticamente los encabezados en el entorno de prueba para evitar sorpresas en el sistema en producción. Si surgen problemas, recurro temporalmente a TTL cortos hasta que se localiza la causa. Con pruebas claras, me aseguro de que Controlar sobre el comportamiento del almacenamiento en caché en todas las capas.
La realidad de los navegadores: tipos de almacenamiento y limpieza
Los navegadores distinguen entre caché de memoria y caché de disco. Los archivos pequeños que se utilizan con frecuencia se benefician de la caché de memoria (accesos extremadamente rápidos), mientras que los recursos de gran tamaño suelen almacenarse en el disco. Los dispositivos móviles limpian la caché de forma más agresiva; por eso no preveo ninguna estrategia que se base exclusivamente en una persistencia muy prolongada en el navegador, sino que me aseguro de contar con buenas vías de revalidación. inmutable Aunque evita revalidaciones innecesarias, esto solo es así mientras la entrada no se haya eliminado por falta de espacio.
Para llevar
Establecer Control de la caché Aplica de forma selectiva: tiempos de vida largos y la propiedad «immutable» para los activos versionados; reglas prudentes y revalidación para el HTML y los contenidos personales. Combina «max-age» con «ETag» o «Last-Modified» para ahorrar ancho de banda y garantizar la actualidad. Comprueba todos los niveles, incluida la CDN, para que las reglas no se contrarresten entre sí. Evita utilizar «no-store» por puro instinto y recurre a él solo cuando la protección de datos sea una prioridad absoluta. Con una separación clara por tipo de contenido, un control de versiones coherente y una medición continua, conseguirás páginas notablemente más rápidas y mantendrás la Soberanía sobre tu actividad de geocaching.
