El almacenamiento en caché HTTP ahorra tiempo y datos, ya que solo vuelve a cargar los recursos cuando realmente han cambiado. A través de ETag y Última modificación Compruebo mediante una solicitud condicional si el servidor responde con un 304 Not Modified, lo que reduce considerablemente la transferencia de datos y la carga del servidor.
Puntos centrales
Las siguientes ideas clave muestran en qué me centro al utilizar el almacenamiento en caché condicional con ETag y Última modificación atención.
- Menos tráfico: Los archivos sin cambios devuelven un código de estado 304, en lugar de todo el cuerpo de la respuesta, lo que reduce notablemente el volumen de datos y la latencia.
- Mejor rendimiento: La reducción de los tiempos de espera mejora la experiencia del usuario (UX) y los Core Web Vitals, lo que SEO ayuda.
- Dos mecanismos: Last-Modified/If-Modified-Since y ETag/If-None-Match validan la caché de forma segura.
- Control de la caché: Las directivas controlan la vigencia, la actualización y el comportamiento en las cachés intermedias.
- Combinación: Ambos métodos, combinados, ofrecen una gran precisión y soluciones alternativas sencillas.
Primero compruebo qué recursos cambian con mucha frecuencia y cuáles lo hacen raramente. Para los archivos que se modifican raramente, establezco un Última modificación-Fecha y hora, y añado un ETag. Para las respuestas dinámicas, prefiero utilizar el ETag, ya que cualquier cambio en el contenido se detecta de inmediato. De este modo, aligero la carga de los servidores, reduzco los tiempos de espera y ofrezco páginas muy rápidas a los visitantes habituales. Esta estrategia refuerza la Core Web Vitals y, por lo tanto, indirectamente, la visibilidad.
Almacenamiento en caché condicional HTTP: cómo comprobar la validez
Al realizar una nueva solicitud, el cliente envía, además de GET, encabezados adicionales que evalúo en el servidor. Si el recurso tiene el mismo ETag Si coincide con el caché (If-None-Match), devuelvo un 304 Not Modified sin cuerpo. Si la marca de tiempo no ha cambiado (If-Modified-Since), el servidor también responde con un 304. Si la fecha o el día ya no coinciden, envío un 200 OK con contenido nuevo y actualizado. Última modificación y ETag. De este modo, ahorro ancho de banda, mantengo la caché actualizada y consigo que los tiempos de carga sean notablemente más rápidos.
«Last-Modified» e «If-Modified-Since» en el día a día
El encabezado Última modificación Utilizo la fecha y hora reales de modificación del archivo, por ejemplo, las del sistema de archivos. Si más tarde llega una solicitud con «If-Modified-Since» y el recurso no ha cambiado desde entonces, respondo con un 304. Este método es sencillo, fácil de entender e ideal para recursos estáticos como CSS, JS o imágenes. Las limitaciones surgen con la resolución de segundos de las marcas de tiempo HTTP y en situaciones en las que el contenido cambia lógicamente sin que exista una fecha de archivo clara. Donde Last-Modified llega a sus límites, un ETag el control.
ETag e If-None-Match en sistemas dinámicos
A ETag Lo genero como un hash, un identificador de versión o a partir de una columna de la base de datos que marca los cambios de estado. Al volver a acceder, el navegador envía un If-None-Match; yo comparo la etiqueta con mi valor actual y respondo en consecuencia con un 304 o un 200. Esta comparación detecta cualquier cambio significativo en el contenido sin depender de las marcas de tiempo de los archivos. Esto ofrece resultados muy precisos, especialmente en el caso de las API, las páginas compuestas o los fragmentos personalizados. Es importante mantener la coherencia de los ETags en entornos de clústeres, para que ningún servidor utilice por error un Día producido.
Combinar correctamente el encabezado Cache-Control
Con Control de la caché Defino durante cuánto tiempo se considera que el contenido está actualizado sin necesidad de volver a consultarlo y cuándo el navegador debe volver a validarlo. Establezco valores adecuados para «max-age» en función de la frecuencia de los cambios y utilizo «must-revalidate» cuando los datos obsoletos podrían ser críticos. Para los archivos versionados, es adecuado un periodo de validez largo, mientras que las respuestas que cambian con frecuencia tienen una vida útil más corta y pueden verificarse correctamente mediante ETag o la fecha. De este modo, combino tiempos de respuesta cortos con una actualidad correcta. Quien desee profundizar en el tema, encontrará muchos ejemplos en Estrategias de control de caché, que utilizo en la consulta.
Proceso paso a paso de una solicitud GET condicional
En la primera solicitud, el servidor envía un 200 OK con Cache-Control, Última modificación y el ETag; el navegador lo guarda todo. En la siguiente visita, la antigüedad en la caché determina si es necesaria una revalidación. Si es necesario, el navegador realiza la solicitud con If-None-Match y/o If-Modified-Since. Si los valores coinciden con el estado actual, envío un 304 Not Modified y el cliente sigue utilizando su caché. Si ya no coinciden, se envía un 200 OK con un nuevo cuerpo y datos actualizados. Datos de validación.
Comparación: ETag frente a Last-Modified
Ambos métodos me garantizan el control, pero difieren en cuanto a esfuerzo, precisión e idoneidad. Última modificación Destaca por su fácil implementación y su semántica clara, siempre y cuando disponga de marcas de tiempo precisas. El ETag refleja el contenido con gran precisión, pero requiere algo de lógica para generarlo. En muchas configuraciones combino ambos y así me beneficio de la simplicidad y del reconocimiento exacto. La siguiente tabla resume las características típicas y ayuda a tomar una decisión.
| Aspecto | Última modificación | ETag | Nota |
|---|---|---|---|
| Identidad | Fecha y hora de la última modificación | Hash del contenido o ID de versión | Tiempo frente a un identificador basado en el contenido |
| Detección de cambios | Resolución de segundos, indirecta | Orientado directamente al contenido | ETag detecta las partículas más pequeñas Diferencias |
| implementación | Muy ligero, el sistema de archivos es suficiente | Requiere generación y coherencia | Los clústeres necesitan lo mismo ETags |
| Utilice | Recursos estáticos | Respuestas dinámicas | Esta combinación cubre muchas Casos de |
| Respuestas | 304 sin cambios en la marca de tiempo | 304 con la misma etiqueta | 200 en caso de modificaciones con un nuevo Valor |
Práctica: Distribución eficiente de recursos estáticos
Los archivos estáticos, como CSS, JS e imágenes, rara vez cambian y son adecuados para periodos largos max-age-Tiempos. Para los archivos versionados, establezco valores altos, de hasta un año, y los marco como inmutables, para que el navegador los cargue sin solicitar confirmación. Para los activos sin versionar, elijo plazos más cortos y confío en la revalidación mediante ETag y Last-Modified. Así evito contenidos obsoletos y mantengo el tráfico bajo. Me aseguro de no Sabotear la cabecera de la caché si lo dejo así, consigo una alta tasa de aciertos en la caché.
Aplicación práctica: API y páginas dinámicas
En cuanto a las API, suelo optar por ETags, que genero a partir del resultado serializado o de una columna de versión. Si el registro cambia, genero una nueva etiqueta, y los clientes lo detectan de inmediato. Para contenidos con marcas de tiempo poco fiables, a menudo prescindo de Last-Modified, para que no se cree una falsa impresión de actualidad. Además, controlo la vida útil mediante Cache-Control y, una vez caducada, obligo a la revalidación. De este modo, mantengo los datos actualizados de forma fiable, sin que las respuestas sean innecesariamente grandes.
Pruebas y supervisión de la tasa de aciertos de la caché
Compruebo encabezados como ETag, Last-Modified, If-None-Match e If-Modified-Since en las herramientas de desarrollo. Al hacerlo, presto atención a los códigos de respuesta, especialmente al 304 frente al 200, para comprobar la eficacia de mi revalidación. Si el 304 es poco frecuente, ajusto el Cache-Control, los tiempos de caducidad y la generación de ETag. Los registros y las métricas me muestran qué rutas devuelven respuestas innecesariamente grandes. Para mejoras agrupadas, me gusta utilizar un Paquete de solicitudes condicionales, que combina la configuración y las pruebas.
Arquitectura de alojamiento y trampas ETag
En configuraciones con varios servidores, es necesario un ETag Debe ser independiente de la instancia; de lo contrario, el reconocimiento fallará. Me aseguro de que todos los nodos utilicen la misma lógica y la misma clave para la generación. Los proxies inversos o las CDN no deben modificar los ETag y deben reenviar correctamente los encabezados de condición. En implementaciones con huellas de activos, evito el recálculo de ETags por parte del servidor si el archivo ya lleva una URL versionada. Unas reglas uniformes evitan respuestas inconsistentes y mantienen alta la tasa de aciertos de la caché.
Actualización frente a validación: uso preciso de las directivas
Hago una clara distinción entre Frescura (¿Durante cuánto tiempo puede un caché utilizar una copia sin consultar el servidor?) y Validación (¿cómo compruebo si sigue siendo válida?). A través de Control de la caché puedo controlar ambos con gran precisión: max-age establece el tiempo de vida en el cliente, s-maxage para cachés compartidas, como los proxies. público permite el almacenamiento en caché en cachés compartidas, privado lo limita al navegador final. debe revalidarse obliga a realizar consultas tras la expiración, mientras que inmutable evita revalidaciones innecesarias en el caso de los activos versionados. no-cache no prohíbe el almacenamiento en caché, sino que exige una revalidación en todo momento; no-store por el contrario, prohíbe totalmente el almacenamiento. Las versiones anteriores Expira enUtilizo el encabezado -Header solo como alternativa; traspaso sistemáticamente la lógica a Cache-Control. Y si quiero mitigar los fallos, me ayudan stale-while-revalidate y stale-if-error, para seguir compartiendo contenidos que han caducado recientemente, mientras actualizo en segundo plano o soluciono los errores.
ETags fuertes y débiles, compresión y variantes
Distingo deliberadamente entre los factores de validación fuertes y los débiles. ETags fuertes identifican exactamente la misma representación, byte a byte; ideal si yo también Solicitudes de gama quiere gestionar de forma eficiente. ETags débiles (Prefijo W/) basta con que haya equivalencia semántica, por ejemplo, en el caso de pequeños cambios de formato sin importancia. Lo importante es cómo se gestiona Compresión: Si sirvo contenidos codificados tanto con gzip como con Brotli, no se puede utilizar un único ETag para todas las variantes. O bien genero el ETag a partir de la versión sin comprimir y, además, establezco un Vary: Accept-Encoding, o bien genero ETags coherentes pero diferentes para cada variante. De este modo evito resultados erróneos y respuestas 200 que en realidad deberían ser 304. En If-Range Combino las consultas de alcance con un validador: si el ETag o la fecha coinciden, respondo con un 206 (contenido parcial); en caso contrario, devuelvo un 200 con el cuerpo completo, para que el cliente disponga de una base coherente.
Dominar a la perfección los encabezados Vary y la negociación de contenido
Siempre que el servidor proporcione diferentes representaciones en función de los requisitos, yo Variar correcto. Algunos ejemplos típicos son Aceptación de codificación (compresión), Aceptar idioma (localización) o indicadores de funciones específicos. Evito recurrir a encabezados volátiles como Agente de usuario o incluso Galleta variar, porque eso reduce drásticamente la tasa de aciertos de la caché. Cuando es necesaria la personalización, marco las respuestas como privado o no-store y las separo claramente de los recursos que se pueden almacenar en caché públicamente. Importante: las variaciones también afectan a los ETags; cada variante necesita su propio validador coherente. De este modo, me aseguro de que los navegadores, los proxies y las CDN apliquen la misma lógica y de que ninguna variante se mezcle accidentalmente con otra.
Consultas condicionales más allá de GET
Las solicitudes condicionales no solo funcionan en la lectura. Para los métodos de escritura, utilizo Si coincide o If-Unmodified-Sincecon el fin de actualizaciones perdidas para evitarlo. Si el cliente envía el ETag visto por última vez en una operación PUT o DELETE mediante Si coincide si el estado del servidor sigue siendo el mismo, solo aplico el cambio; de lo contrario, respondo con 412 Condición previa no cumplida. Para controlar a los clientes, el servidor también puede 428 Se requiere una condición previa establecer. Para pruebas rápidas sin cuerpo, utilizo HEAD, que me devuelve los mismos encabezados que una solicitud GET; ideal si quiero probar los metadatos. Y en 304-En las respuestas vuelvo a incluir todos los encabezados relevantes para la caché (Cache-Control, ETag, Expires, Last-Modified), para que el cliente actualice sus metadatos sin necesidad de transferir el cuerpo del mensaje.
Seguridad, protección de datos y cumplimiento de la normativa
No guardo contenidos personales o sensibles en la caché pública. En este caso, utilizo Control de caché: privado o no-store, para que el navegador, o más bien ninguna instancia, guarde el contenido. Hay que tener cuidado con las cuentas de usuario y los paneles de control: las respuestas con Establecer cookie o Autorización no deben poder almacenarse en caché de forma pública por error. Los propios ETags pueden utilizarse indebidamente como vector de rastreo si se mantienen estables durante mucho tiempo. Para evitarlo, utilizo los validadores solo donde el almacenamiento en caché es deseado, y los desactivo en rutas específicas para el usuario o mantengo su vida útil corta. De esta forma, combino el rendimiento con los requisitos de protección de datos.
Detalles de implementación y costes de rendimiento
La generación de una etiqueta ETag no debe ser más costosa que el beneficio que aporta. En el caso de archivos grandes o renderizados costosos, guardo la etiqueta junto con los metadatos (suma de comprobación del archivo, hash de compilación, base de datos-versión de fila) y no lo recapitulo en cada solicitud. En el caso de las páginas compuestas, resulta útil una Estrategia de creación de versiones: Creo el ETag a partir de sub-ETags estables (por ejemplo, plantilla, fragmento de datos, configuración), de modo que los pequeños cambios den como resultado un nuevo valor específico pero reproducible. En clústeres, sincronizo la lógica de generación en una biblioteca común y la compruebo en CI para que ninguna instancia se desvíe. Para blobs extremadamente grandes, utilizo sumas de comprobación rápidas (CRC64) o guardo hash de compilación, en lugar de generar el hash del cuerpo sobre la marcha. Cuando no es necesaria la igualdad absoluta de bytes, basta con ETags débiles como un compromiso pragmático.
Errores comunes y cómo evitarlos
- ETags aleatorios: Si las etiquetas se generan de nuevo en cada solicitud, cualquier revalidación carece de sentido. Me aseguro de que los valores sean deterministas y solo cambien cuando se produzca un cambio real.
- Combinación incorrecta de directivas: no-store Usar ETag no sirve de nada: el navegador no lo almacena de todos modos. Elijo combinaciones coherentes para conseguir el comportamiento deseado.
- Vary excesivo: Las variaciones en las cookies o en el User-Agent desorganizan la caché. Limito el campo «Vary» a cambios reales en la representación.
- Trampas de compresión: Un ETag común para gzip y br provoca resultados erróneos. Asigno los ETags correctamente a la variante concreta y configuro Vary de forma adecuada.
- Desviación horaria: Los relojes de servidor inexactos distorsionan el valor de «Last-Modified». Mantengo sincronizadas las fuentes de tiempo para que «If-Modified-Since» funcione correctamente.
- Confusión con «no-cache»: Muchos leen „no almacenar en caché“. Lo que se quiere decir es „revalidar siempre“. Para una prohibición real, yo utilizo no-store.
Resolución de problemas, métricas y flujos de trabajo
Para solucionar el problema, empiezo por la pestaña «Red»: ¿Es correcto? Control de la caché? ¿Se aplica en caso de rehabilitación? 304 ¿En lugar de 200? ¿Te vale? ETag y Última modificación ¿Cuánto tiempo pasa entre la consulta y la respuesta? Lo voy a comprobar Variar, para comprobar si las variantes se han detectado correctamente. En los registros, me muestro Acierto/Error-Mostrar las tasas de 304 y el tamaño medio de las respuestas por ruta. Si la tasa de 304 aumenta, el volumen de datos y el TTFB suelen disminuir de forma notable. En las pruebas de carga, simulo llamadas repetidas para medir los costes de revalidación en lugar de los de transferencia. Si detecto anomalías, elimino gradualmente los factores perturbadores: Set-Cookie, reglas Vary demasiado estrictas, encabezados contradictorios como Pragma. Así encuentro rápidamente el cuello de botella que reduce la tasa de visitas.
Los Service Workers como capa de caché complementaria
Si utilizo un Service Worker, lo utilizo como un nivel adicional, no como uno contradictorio. Dejo que se encargue de lo mismo Control de la caché-Respeta las señales y combina estrategias como stale-while-revalidate utilizando deliberadamente la validación HTTP mediante ETag y Last-Modified. En casos de conexión offline, el worker puede proporcionar recursos que hayan quedado obsoletos temporalmente y revalidarlos en segundo plano. Es importante que transmita correctamente los encabezados de condición; de lo contrario, pierdo las ventajas del 304 en la conexión de red. De este modo, los escenarios de PWA también se benefician de un almacenamiento en caché HTTP limpio, en lugar de eludir sus mecanismos.
Efecto SEO y Core Web Vitals
Mejorar las respuestas rápidas UX y las señales de los usuarios, lo que favorece el posicionamiento. Los visitantes habituales son los que más se benefician, ya que su navegador recupera muchos archivos directamente de la caché o mediante un código de estado 304. Esta menor latencia tiene un efecto positivo en el FCP, el LCP y el TTFB, que reduzco mediante una revalidación selectiva. Además, el servidor ahorra tiempo de procesamiento, que puedo utilizar para picos de carga o solicitudes complejas. De este modo, mantengo el rendimiento, mientras que los contenidos llegan correctamente y de forma oportuna.
Resumen: Mi plan de acción
Confío en una clara Combinación a partir de Cache-Control, Last-Modified y ETag. Para los recursos estáticos, elijo duraciones largas y me aseguro mediante la revalidación cuando los archivos no están versionados. Para las respuestas dinámicas, genero ETags fiables y mantengo la coherencia de los clústeres. A continuación, compruebo con herramientas, métricas y registros si los 304 se producen con la frecuencia suficiente y ajusto la configuración. De este modo, garantizo una entrega rápida, una menor carga y una mejor experiencia de usuario mediante un Almacenamiento en caché HTTP.
