Encabezados de caché HTTP.Este artículo destaca información importante sobre los encabezados de almacenamiento en caché HTTP y el comportamiento de CDN asociado. En caso de que esté buscando información detallada sobre el rol de los encabezados de caché HTTP en la web moderna, aquí encontrará todo lo que necesita saber.
Los encabezados de caché HTTP explicados
Los cachés trabajan con contenido principalmente a través de la frescura y la validación. Una nueva representación está disponible al instante desde un caché, mientras que una representación validada rara vez envía la representación completa de nuevo si no ha cambiado. En los casos en los que no hay un validador presente (es decir, un encabezado ETag / Last-modified), y la falta de información explícita sobre la actualización, por lo general (pero no siempre) se considerará que no se puede almacenar en caché. Cambiemos nuestro enfoque al tipo de encabezados por los que debería preocuparse.
Control de caché
Cada recurso puede definir su propia política de almacenamiento en caché a través del encabezado HTTP de Cache-Control. Las directivas Cache-Control controlan quién almacena en caché la respuesta, en qué condiciones y durante cuánto tiempo.
Las solicitudes que no necesitan comunicación con el servidor se consideran las mejores solicitudes: las copias locales de las respuestas permiten la eliminación de la latencia de la red, así como los cargos de datos resultantes de las transferencias de datos. La especificación HTTP permite al servidor enviar varias directivas diferentes de control de caché que controlan cómo y durante cuánto tiempo se almacenan en caché las respuestas individuales entre otros cachés intermedios, como una CDN.
Estas configuraciones se conocen como directivas de respuesta. Son los siguientes:
Público vs. Privado
Una respuesta que está marcada como «pública» se puede almacenar en caché incluso en los casos en que está asociada con una autenticación HTTP o el código de estado de respuesta HTTP no se puede almacenar en caché normalmente. En la mayoría de los casos, una respuesta marcada como «pública» no es necesaria, ya que la información de almacenamiento en caché explícita (es decir, «max-age») muestra que una respuesta es de todos modos cacheable.
Por el contrario, una respuesta marcada como «privada» puede ser almacenada en caché (por el navegador) pero tales respuestas están destinadas generalmente a usuarios individuales, por lo que no se pueden almacenar en caché por cachés intermedios (por ejemplo, las páginas HTML con información privada del usuario pueden ser almacenadas en caché por un usuario). navegador pero no por un CDN).
No-cache y no-store
«Sin caché» muestra que las respuestas devueltas no se pueden usar para solicitudes posteriores a la misma URL antes de verificar si las respuestas del servidor han cambiado. Si hay un ETag adecuado (token de validación) como resultado, no-cache incurre en un viaje de ida y vuelta en un esfuerzo por validar las respuestas en caché. Sin embargo, los cachés pueden eliminar las descargas si los recursos no han cambiado. En otras palabras, los navegadores web pueden almacenar en caché los activos, pero tienen que verificar en cada solicitud si los activos han cambiado (respuesta 304 si nada ha cambiado).
Por el contrario, «no-store» es más simple. Este es el caso porque no permite que los navegadores y todos los cachés intermedios almacenen versiones de respuestas devueltas, es decir, respuestas que contengan información privada / personal o datos bancarios. Cada vez que los usuarios solicitan este activo, las solicitudes se envían al servidor. Los activos se descargan cada vez.
Edad máxima
La directiva max-age indica la cantidad máxima de tiempo en segundos que se permite que se vuelvan a utilizar las respuestas obtenidas (desde el momento en que se realiza una solicitud). Por ejemplo, «max-age = 90» indica que un activo se puede reutilizar (permanece en el caché del navegador) durante los siguientes 90 segundos.
S-maxage
La «s-» significa compartido como en «caché compartida». Esta directiva es explícitamente para CDNs entre otros cachés intermedios. Esta directiva anula la directiva max-age y expira el campo de encabezado cuando está presente. KeyCDN también obedece esta directiva.
Debe revalidar
La directiva must-revalidate se usa para decirle a un caché que primero debe volver a validar un activo con el origen después de que esté obsoleto. El activo no se debe entregar al cliente sin realizar una revalidación de extremo a extremo. En resumen, los activos obsoletos deben primero verificarse y los activos vencidos no deben utilizarse.
Proxy-revalidar
La directiva proxy-revalidate es la misma que la directiva must-revalidate, sin embargo, solo se aplica a cachés compartidos como proxies. Es útil en el caso de que un proxy sirva a muchos usuarios que necesitan ser autenticados uno por uno. Una respuesta a una solicitud autenticada se puede almacenar en la memoria caché del usuario sin necesidad de volver a validarla cada vez que se conocen y ya se han autenticado. Sin embargo, proxy-revalidate permite que los proxies aún se vuelvan a validar para los nuevos usuarios que aún no han sido autenticados.
Sin transformar
La directiva de no transformar le dice a cualquier intermediario, como un servidor proxy o servidor de caché, que no haga ninguna modificación al activo original. Los encabezados Content-Encoding, Content-Range y Content-Type deben permanecer sin cambios. Esto puede ocurrir si un proxy no transparente decide hacer modificaciones a los activos para ahorrar espacio. Sin embargo, esto puede causar serios problemas en el caso de que el activo deba permanecer idéntico al cuerpo de la entidad original, aunque también debe pasar por el proxy.
Según Google , el encabezado Cache-Control es todo lo que se necesita en términos de especificación de políticas de almacenamiento en caché. Hay otros métodos disponibles que revisaremos en este artículo, sin embargo, no son necesarios para un rendimiento óptimo.
El encabezado Cache-Control se define como parte de las especificaciones de HTTP / 1.1 y reemplaza los encabezados anteriores (es decir, Vence) que se usan para especificar políticas de almacenamiento en caché de respuestas. Cache-Control es compatible con todos los navegadores modernos, así que eso es todo lo que necesitamos.
Pragma
El antiguo encabezado «pragma» logra muchas cosas, la mayoría de ellas caracterizadas por implementaciones más nuevas. Sin embargo, estamos más preocupados con la pragma: no-cachedirectiva que es interpretada por implementaciones más recientes como cache-control: no-cache. No tiene que preocuparse por esta directiva porque es un encabezado de solicitud que será ignorado por los servidores perimetrales de KeyCDN. Sin embargo, es importante conocer la directiva para la comprensión general. En el futuro, no habrá nuevas directivas HTTP definidas para pragma .
Vence
Hace un par de años, esta era la principal forma de especificar cuándo caducan los activos. Expires es simplemente un sello de fecha y hora básico. Es bastante útil para los antiguos agentes de usuario que aún vagan por territorios desconocidos. Sin embargo, es importante tener en cuenta que los encabezados de control de caché, max-age y s-maxage todavía tienen prioridad en la mayoría de los sistemas modernos. Sin embargo, es una buena práctica establecer valores coincidentes aquí por motivos de compatibilidad. También es importante asegurarse de formatear la fecha correctamente o podría considerarse caducada.
Para evitar romper la especificación, evite establecer el valor de la fecha en más de un año.
Validadores
ETag
Este tipo de token de validación (el estándar en HTTP / 1.1): Se comunica a través del encabezado HTTP de ETag (por el servidor).
Permite actualizaciones de recursos eficientes, es decir, no se realiza la transferencia de datos si el recurso no cambia.
El siguiente ejemplo ilustrará esto. 90 segundos después de la obtención inicial de un activo, inicia el navegador una nueva solicitud (exactamente el mismo activo). El navegador busca la memoria caché local y encuentra la respuesta almacenada previamente en la memoria caché, pero no puede usarla porque está vencida. Este es el punto donde el navegador solicita el contenido completo del servidor. El problema con esto es que si el recurso no ha cambiado, no hay absolutamente ninguna razón para descargar el mismo recurso que ya está en el caché de CDN.
Los tokens de validación están resolviendo este problema. El servidor Edge crea y devuelve tokens arbitrarios, que se almacenan en el campo del encabezado de ETag, que suelen ser un hash u otras huellas digitales del contenido de los archivos existentes. Los clientes no necesitan saber cómo se generan los tokens, sino que deben enviarlos al servidor en solicitudes posteriores. Si los tokens son los mismos, los recursos no han cambiado, por lo tanto, las descargas se pueden omitir.
El navegador web proporciona el token ETag automáticamente dentro del encabezado de solicitud HTTP «If-None-Match». El servidor luego verifica tokens contra los activos actuales en el caché. Una respuesta 304 No modificada le dirá al navegador si un activo en el caché no se ha cambiado y, por lo tanto, permite una renovación por otros 90 segundos. Es importante tener en cuenta que estos activos no necesitan ser descargados nuevamente, lo que ahorra tiempo y ancho de banda .
¿Cómo se benefician los desarrolladores web de una revalidación eficiente?
Los navegadores hacen la mayoría (si no es así) todo el trabajo para los desarrolladores web. Por ejemplo, detectan automáticamente si los tokens de validación se han especificado anteriormente y los añaden a las solicitudes salientes y actualizan las marcas de tiempo de caché según sea necesario en función de las respuestas de los servidores. Por lo tanto, a los desarrolladores web solo les queda un trabajo, lo que garantiza que los servidores proporcionen los tokens ETag necesarios. Los servidores perimetrales de KeyCDN son totalmente compatibles con ETags.
Última modificación
El encabezado Last-Modified indica la última vez que se modificó un documento, que es el validador más común. Puede verse como un validador heredado desde el momento de HTTP / 1.0. Cuando un caché almacena un activo que incluye un encabezado de última modificación , puede utilizarlo para consultar al servidor si esa representación ha cambiado con el tiempo (desde la última vez que se vio). Esto se puede hacer usando un campo de encabezado de solicitud If-Modified-Since .
Un servidor de origen HTTP / 1.1 debe enviar tanto el valor ETag como el valor de Última modificación. Más detalles se pueden encontrar en la sección 13.3.4 en el RFC2616 .
Directivas de control de caché de extensión
Además de las conocidas directivas de control de caché que se describen en la primera sección de este artículo, también existen otras directivas que se pueden usar como extensiones de control de caché para obtener una mejor experiencia de usuario para sus visitantes.
Inmutable
No se activará ninguna revalidación condicional incluso si el usuario actualiza explícitamente una página. La directiva inmutable le dice al cliente que el cuerpo de la respuesta no cambiará con el tiempo, por lo tanto, no hay necesidad de verificar si hay actualizaciones mientras no se cumpla.
Conservado mientras se revalida
La directiva stale-while-revalidate permite que un activo obsoleto se sirva mientras se revalida en segundo plano.
Se define un valor obsoleto mientras se revalida para indicar a la memoria caché que tiene X cantidad de tiempo para validar el activo en segundo plano mientras continúa entregando el valor obsoleto. Un ejemplo de esto se vería así:
Control de caché: max-age = 2592000, stale-while-revalidate = 86400
Stale-If-Error
La directiva stale-if-error es muy similar a la directiva stale-while-revalidate en cuanto a que sirve contenido obsoleto cuando el período máximo caduca. Sin embargo, el error de obsoleto solo devuelve contenido obsoleto si el servidor de origen devuelve un código de error (por ejemplo, 500, 502, 503 o 504) cuando la memoria caché intenta revalidar el activo.
Por lo tanto, en lugar de mostrar a los visitantes una página de error, se les entrega contenido obsoleto por un período de tiempo predefinido. Durante este tiempo, el objetivo es que el error se haya resuelto y que el activo pueda ser revalidado.
Leer también: Agregar encabezado de control de caché en Nginx; caducidad ; ¿Que es almacenamiento en caché y cómo funciona? Ventajas y desventajas ; Que es cache en informática, para qué sirve
This post is also available in:
Español
