Información general sobre el almacenamiento en caché

Una respuesta que se puede almacenar en caché es una respuesta HTTP que Cloud CDN puede almacenar y recuperar rápidamente, lo que permite que los tiempos de carga sean más rápidos. No todas las respuestas HTTP se pueden almacenar en caché.

Modos de caché

Con los modos de caché, puede controlar los factores que determinan si Cloud CDN almacena en caché su contenido.

Cloud CDN ofrece tres modos de caché que definen cómo se almacenan en caché las respuestas, si Cloud CDN respeta las directivas de caché enviadas por el origen y cómo se aplican los TTL de caché.

En la siguiente tabla se muestran los modos de caché disponibles:

Las respuestas de error se pueden almacenar en caché incluso si no hay directivas de caché válidas.

Antes de definir el modo de caché en FORCE_CACHE_ALL, ten en cuenta los siguientes comportamientos:

• En el caso de las URLs o cookies firmadas, FORCE_CACHE_ALL anula la antigüedad máxima especificada mediante el ajuste Antigüedad máxima de la entrada de caché en la consola Google Cloud o la opción gcloud --signed-url-cache-max-age.

• FORCE_CACHE_ALL cambia el tiempo de vida (TTL) de cualquier contenido almacenado en caché anteriormente. Este cambio puede hacer que algunas entradas que antes se consideraban recientes (porque tenían TTLs más largos en los encabezados de origen) se consideren obsoletas, y que algunas entradas que antes se consideraban obsoletas se consideren recientes.

• FORCE_CACHE_ALL anula las directivas de caché (Cache-Control y Expires), pero no anula otros encabezados de respuesta de origen. En concreto, un encabezado Vary puede suprimir el almacenamiento en caché aunque el modo de caché sea FORCE_CACHE_ALL. Para obtener más información, consulta Encabezados Vary.

Para obtener instrucciones de configuración, consulta el artículo Configurar el modo de caché.

Contenido estático

El contenido estático es el que siempre es el mismo, incluso cuando acceden diferentes usuarios. El CSS que usas para dar estilo a tu sitio, JavaScript para proporcionar interactividad, vídeo y contenido de imagen normalmente no cambian para cada usuario en una URL determinada (clave de caché) y, por lo tanto, se benefician de estar en caché en la red perimetral global de Cloud CDN.

Si configuras el modo de caché como CACHE_ALL_STATIC y una respuesta no tiene directivas de almacenamiento en caché explícitas en los encabezados Cache-Control o Expires, Cloud CDN almacena en caché automáticamente esa respuesta en los siguientes casos:

• Recursos web, incluidos CSS (text/css), JavaScript (application/javascript) y todas las fuentes web, incluido WOFF2 (font/woff2)
• Imágenes, incluidos JPEG (image/jpg) y PNG (image/png)
• Vídeos, incluidos H.264, H.265 y MP4 (video/mp4)
• Archivos de audio, incluidos MP3 (audio/mpeg) y MP4 (audio/mp4)
• Documentos formateados, incluidos PDF (application/pdf)

En la siguiente tabla puedes ver un resumen.

Cloud CDN inspecciona el encabezado de respuesta HTTP Content-Type, que refleja el tipo MIME del contenido que se está sirviendo.

Ten en cuenta lo siguiente:

• El software del servidor web de tu origen debe definir el Content-Type para cada respuesta. Muchos servidores web definen automáticamente el encabezado Content-Type, incluidos NGINX, Varnish y Apache.

• Cloud Storage define el encabezado Content-Type automáticamente cuando usas la Google Cloud consola o la CLI de Google Cloud para subir contenido.

• Cloud Storage siempre proporciona un encabezado Cache-Control a Cloud CDN. Si no se elige ningún valor explícitamente, se envía un valor predeterminado. Por lo tanto, todas las respuestas correctas de Cloud Storage se almacenan en caché según los valores predeterminados de Cloud Storage, a menos que ajuste explícitamente los metadatos de control de caché de los objetos de Cloud Storage o utilice el modo FORCE_CACHE_ALL para anular los valores enviados por Cloud Storage.

• Si quieres almacenar en caché los tipos de contenido text/html y application/json, debes definir encabezados Cache-Control explícitos en la respuesta y tener cuidado de no almacenar en caché por error los datos de un usuario y ofrecérselos a todos los usuarios.

Si una respuesta se puede almacenar en caché en función de su tipo MIME, pero tiene un encabezado de respuesta Cache-Control de private o no-store, o un encabezado Set-Cookie, no se almacena en caché. Para obtener más información, consulta las reglas de almacenamiento en caché.

Otros tipos de contenido, como HTML (text/html) y JSON (application/json), no se almacenan en caché de forma predeterminada para las respuestas correctas. Este tipo de respuestas suelen ser dinámicas (por usuario). Por ejemplo, carritos de la compra, páginas de productos con personalización para el usuario y respuestas de APIs autenticadas. Sin embargo, si está habilitado el almacenamiento en caché negativo, es posible que se almacenen en caché para determinados códigos de estado.

Cloud CDN no usa extensiones de archivo en la ruta de la URL para determinar si una respuesta se puede almacenar en caché, ya que muchas respuestas válidas que se pueden almacenar en caché no se reflejan en las URLs.

Contenido que se puede almacenar en caché

Cloud CDN almacena en caché las respuestas que cumplen todos los requisitos de esta sección. Algunos de estos requisitos se especifican en RFC 7234, mientras que otros son específicos de Cloud CDN.

Cloud CDN puede cambiar periódicamente el conjunto exacto de condiciones en las que almacena contenido en caché. Si quiere evitar explícitamente que Cloud CDN almacene en caché su contenido, siga las directrices de RFC 7234 para determinar cómo especificar una respuesta que no se pueda almacenar en caché. Consulta también la sección Contenido no almacenable en caché basado en encabezados de origen.

Cloud CDN almacena las respuestas en caché si se cumplen todas las condiciones siguientes.

En el caso de los segmentos de backend de Cloud Storage, sigue estas sugerencias adicionales:

• Hacer que el segmento se pueda leer públicamente. Este es el método que recomendamos para el contenido público. Con este ajuste, cualquier usuario de Internet puede ver y enumerar tus objetos y sus metadatos, excepto las listas de control de acceso. Le recomendamos que dedique contenedores específicos a los objetos públicos.

• Usa carpetas gestionadas para hacer que una parte de tu segmento se pueda leer públicamente.

• Hacer que los objetos se puedan leer públicamente. No recomendamos este enfoque, ya que utiliza un sistema de permisos antiguo específico de Cloud Storage.

• No almacenes el objeto en un segmento que tenga habilitada la opción Pago por solicitud ni en un perímetro de servicio de nube privada virtual.

• No encriptes el objeto con claves de encriptado gestionadas por el cliente ni con claves de encriptado proporcionadas por el cliente.

De forma predeterminada, cuando un objeto es público y no especifica metadatos Cache-Control, Cloud Storage le asigna un encabezado Cache-Control: public, max-age=3600. Puedes definir valores diferentes mediante los Cache-Controlmetadatos.

Para ver un ejemplo de cómo configurar un balanceador de carga de aplicación externo con un segmento de backend, consulta Configurar Cloud CDN con un segmento de backend.

Tamaño máximo

Cloud CDN aplica un tamaño máximo a cada respuesta. Las respuestas con un cuerpo mayor que el tamaño máximo no se almacenan en caché, pero se siguen enviando al cliente.

El tamaño máximo varía en función de si el servidor de origen admite solicitudes de intervalo de bytes.

Casi todos los servidores web modernos (incluidos NGINX, Apache y Varnish) admiten solicitudes de intervalo de bytes.

Contenido que no se puede almacenar en caché en función de los encabezados de origen

Hay comprobaciones que bloquean el almacenamiento en caché de las respuestas. Cloud CDN puede cambiar periódicamente el conjunto exacto de condiciones en las que almacena contenido en caché, por lo que, si quieres evitar explícitamente que Cloud CDN almacene tu contenido en caché, sigue las directrices del estándar (RFC 7234) para determinar cómo especificar una respuesta que no se pueda almacenar en caché.

Cloud CDN no almacena en caché una respuesta si no cumple los requisitos de contenido que se puede almacenar en caché o si se cumple alguna de las siguientes condiciones.

Si Cache-Control: no-store o private están presentes, pero el contenido sigue almacenándose en caché, se debe a uno de los siguientes motivos:

• La firma de URLs está configurada.
• El modo de caché de Cloud CDN se ha configurado para forzar el almacenamiento en caché de todas las respuestas.

Evitar el almacenamiento en caché

Para evitar que la información privada se almacene en caché en las cachés de Cloud CDN, haz lo siguiente:

1. Asegúrate de que el modo de caché de Cloud CDN no esté configurado en el modo FORCE_CACHE_ALL, que almacena en caché de forma incondicional todas las respuestas correctas.
2. Incluye un encabezado Cache-Control: private en las respuestas que no deban almacenarse en las cachés de Cloud CDN o un encabezado Cache-Control: no-store en las respuestas que no deban almacenarse en ninguna caché, ni siquiera en la de un navegador web.
3. No firmes URLs que proporcionen acceso a información privada. Cuando se accede al contenido mediante una URL firmada, es posible que se pueda almacenar en caché, independientemente de las directivas Cache-Control de la respuesta.
4. En el caso de las solicitudes de origen (relleno de caché) que incluyen el encabezado de solicitud Authorization, Cloud CDN solo almacena en caché las respuestas que incluyen las directivas de control de caché public, must-revalidate o s-maxage cuando el modo de caché está definido como USE_ORIGIN_HEADERS o CACHE_ALL_STATIC. De esta forma, se evita que se almacene en caché por error contenido por usuario y contenido que requiera autenticación. El modo de caché de FORCE_CACHE_ALL no tiene esta restricción.

Encabezados de respuesta personalizados

Con los encabezados de respuesta personalizados, puedes especificar encabezados que el balanceador de carga de aplicaciones clásico añade a las respuestas procesadas en el proxy. Los encabezados de respuesta personalizados te permiten reflejar el estado de la caché a tus clientes, los datos geográficos de los clientes y tus propios encabezados de respuesta estáticos.

Para obtener instrucciones, consulta el artículo Configurar encabezados de respuesta personalizados.

Claves de caché

Cada entrada de la caché de Cloud CDN se identifica mediante una clave de caché. Cuando llega una solicitud a la caché, esta convierte el URI de la solicitud en una clave de caché y, a continuación, la compara con las claves de las entradas almacenadas en caché. Si encuentra una coincidencia, la caché devuelve el objeto asociado a esa clave.

En el caso de los servicios de backend, Cloud CDN usa de forma predeterminada el URI de solicitud completo como clave de caché. Por ejemplo, https://example.com/images/cat.jpg es el URI completo de una solicitud concreta del objeto cat.jpg. Esta cadena se usa como clave de caché predeterminada. Solo se mostrarán resultados que coincidan exactamente con esta cadena. Las solicitudes de http://example.com/images/cat.jpg o https://example.com/images/cat.jpg?user=user1 no coinciden.

En el caso de los backend buckets, la clave de caché predeterminada se compone del URI sin el protocolo ni el host. De forma predeterminada, solo los parámetros de consulta que conoce Cloud Storage se incluyen en la clave de caché (por ejemplo, "generation").

Por lo tanto, para un determinado contenedor de backend, los siguientes URIs se resuelven en el mismo objeto almacenado en caché:

• http://example.com/images/cat.jpg
• https://example.com/images/cat.jpg
• https://example.com/images/cat.jpg?user=user1
• http://example.com/images/cat.jpg?user=user1
• https://example.com/images/cat.jpg?user=user2
• https://media.example.com/images/cat.jpg
• https://www.example.com/images/cat.jpg

Puede cambiar qué partes del URI se usan en la clave de caché. Aunque el nombre de archivo y la ruta siempre deben formar parte de la clave, puedes incluir u omitir cualquier combinación de protocolo, host o cadena de consulta al personalizar la clave de caché. En Usar claves de caché se describe cómo personalizar las claves de caché.

Además de incluir u omitir toda la cadena de consulta, puede usar partes de la cadena de consulta mediante listas de inclusión y listas de exclusión.

Lista de inclusión de cadenas de consulta

Puede controlar de forma selectiva qué parámetros de cadena de consulta incorpora Cloud CDN en las claves de caché. Por ejemplo, si creas una lista de inclusión de user, entonceshttps://example.com/images/cat.jpg?user=user1&color=blue se crea una clave de caché https://example.com/images/cat.jpg?user=user1 que también coincide con https://example.com/images/cat.jpg?user=user1&color=red.

Para usar esta opción, debe incluir la cadena de consulta, especificar una lista de inclusión no vacía y no especificar una lista de exclusión.

Lista de inclusión de cadenas de consulta para claves de caché de Cloud Storage

Incluir parámetros de consulta de URL en las claves de caché de los segmentos de Cloud Storage ayuda a admitir el cache busting. La invalidación de caché permite que un usuario recupere una versión nueva del archivo que se ha subido, aunque la versión anterior siga almacenada en caché de forma válida según el ajuste de TTL.

Puede usar una lista de inclusión con parámetros de cadena de consulta en la clave de caché que se usa para servir respuestas de un segmento de backend. Aunque Cloud Storage no sirve contenido diferente ni enruta en función de los parámetros de consulta, puedes incluir parámetros que te permitan invalidar la caché del contenido estático almacenado en segmentos de Cloud Storage.

Por ejemplo, puedes añadir un parámetro de consulta ?version=VERSION o ?hash=HASH que se base en el contenido subyacente. De esta forma, se limita la necesidad de invalidar el contenido de forma proactiva y se adapta a los flujos de trabajo de desarrollo web modernos, en los que los frameworks web y las URLs usan un hash del contenido para evitar que se sirvan objetos obsoletos en las implementaciones.

Como la inclusión de parámetros de consulta en la clave de caché es opcional, Cloud CDN no admite la exclusión de parámetros de consulta de una clave de caché en un backend de almacenamiento.

Lista de exclusión de cadenas de consulta

Puedes controlar de forma selectiva qué parámetros de cadena de consulta ignora Cloud CDN mediante una lista de exclusión. Por ejemplo, si crea una lista de exclusión de user, todos los parámetros de cadena de consulta excepto user se usarán en la clave de caché.

Si la lista de exclusión está configurada y la entrada es https://example.com/images/cat.jpg?user=user1&color=blue, Cloud CDN crea una clave de caché https://example.com/images/cat.jpg?color=blue que también coincide con https://example.com/images/cat.jpg?user=user2&color=blue, pero no con https://example.com/images/cat.jpg?user=user1&color=red.

Para usar esta opción, debe incluir la cadena de consulta, especificar una lista de exclusión no vacía y no especificar una lista de inclusión.

Orden de los parámetros de consulta

La clave de caché generada no depende del orden de los parámetros de consulta.

Por ejemplo, los siguientes parámetros de consulta generan la misma clave de caché:

• info=123&variant=13e&geography=US
• geography=US&variant=13e&info=123

Configuración de encabezados HTTP y cookies HTTP

Puede mejorar las tasas de aciertos de caché y la descarga de origen con los siguientes ajustes de configuración de la clave de caché:

• En el caso de los servicios de backend y los contenedores: usa encabezados HTTP como parte de las claves de caché. Para ello, incluye encabezados con nombre en la configuración de la clave de caché.
• Solo para servicios de backend: usa cookies HTTP con nombre como claves de caché, como para pruebas A/B (multivariante), lanzamientos Canary y situaciones similares.

Las solicitudes de caché que incluyen encabezados HTTP o cookies HTTP adicionales en la solicitud se almacenan en caché en la tercera solicitud en una ubicación de caché para esa clave de caché. De esta forma, se reduce el impacto de los valores de encabezado o de cookie de alta cardinalidad en las tasas de desalojo de la caché. En circunstancias normales y con un tráfico de usuarios normal, esto no debería notarse y ayuda a que el contenido popular permanezca en la caché.

Incluir encabezados de solicitud

Para almacenar en caché variaciones adicionales de una respuesta, puede incluir encabezados de solicitud adicionales en la clave de caché.

Algunas encabezados no se permiten en las claves de caché porque suelen tener una cardinalidad muy alta. En la mayoría de los casos, los valores de estos encabezados son únicos por usuario (Cookie y Authorization) o tienen miles de valores probables (Referer, User-Agent y Accept). Por ejemplo, el encabezado User-Agent puede tener más de 5000 valores únicos debido a la gran variedad de navegadores, dispositivos de usuario y sistemas operativos. Estos tipos de encabezados tendrían un impacto negativo grave en las tasas de aciertos de caché.

Solo se aceptan nombres de campos de encabezado HTTP válidos según el RFC 7230. Los nombres de los campos de encabezado no distinguen entre mayúsculas y minúsculas, y no se permiten duplicados.

También puede configurar su servidor de origen para que incluya encabezados de solicitud de clave de caché configurados en la respuesta Vary. No es obligatorio para Cloud CDN, pero puede ser útil para las cachés de nivel inferior. Para obtener más información, consulta Variar encabezados.

Cloud CDN no permite que se incluyan los siguientes encabezados en la lista de encabezados:

• Accept
• Accept-Encoding
• Authority, ya que se controla mediante la configuración (cdnPolicy.includeHost)
• Authorization, normalmente por usuario, como en los tokens de OAuth Bearer
• CDN-Loop
• Connection
• Content-MD5
• Content-Type
• Cookie
• Date
• Forwarded, a menudo por cliente o por proxy
• From
• Host, ya que se controla mediante la configuración (cdnPolicy.includeHost)
• If-Match, If-Modified-Since o If-None-Match
• Origin
• Proxy-Authorization
• Range
• Referer (o Referrer)
• User-Agent
• Want-Digest
• X-CSRFToken y X-CSRF-Token, tal como los usan Django y Ruby on Rails
• X-Forwarded-For, a menudo por cliente o por proxy
• X-User-IP
• Cualquier encabezado que empiece por lo siguiente:
  • Access-Control-, como Access-Control-Request-Headers y Access-Control-Request-Method
  • Sec-Fetch-
  • Sec-GFE-
  • Sec-Google-
  • X-Amz-
  • X-GFE-
  • X-Goog-
  • X-Google-

Usar variables personalizadas con encabezados de solicitud

Las claves de caché son útiles cuando necesitas servir contenido de forma diferente en función del dispositivo y la ubicación de cada usuario. Por ejemplo, puedes habilitar un sitio web adaptable para que muestre las imágenes adecuadas a los usuarios que estén viendo contenido en función del tipo de dispositivo o definir un idioma predeterminado útil en función de su ubicación. Puedes definir claves de caché mediante encabezados de solicitud personalizados y variables personalizadas.

Para usar variables personalizadas con encabezados de solicitud, siga estos pasos:

1. Define un encabezado de solicitud personalizado para tu servicio de backend. Incluya una o varias variables para el valor del encabezado de solicitud personalizado.
2. Actualiza la clave de caché para usar el encabezado de solicitud personalizado.

En Cloud CDN, solo puede usar las siguientes variables al definir encabezados que sean tanto encabezados de solicitud personalizados como encabezados de clave de caché:

• device_request_type
• user_agent_family
• client_region
• client_region_subdivision

Cloud CDN limita las variables para mantener el rendimiento de la caché. Es similar a los límites de los encabezados que se pueden usar como claves de caché.

Por ejemplo, si especificara X-Lat-Long:{client_city_lat_long} como encabezado de solicitud personalizado y, a continuación, añadiera X-Lat-Long a su conjunto de encabezados de clave de caché, Cloud CDN intentaría almacenar en caché una copia de la respuesta para cada valor de client_city_lat_long. Esto provocaría un uso excesivo de la caché, un vaciado innecesario del contenido y una menor oportunidad de devolver aciertos de caché.

Por estos motivos, las variables con una cardinalidad alta no se incluyen en la lista de variables que se usan para definir encabezados de solicitud personalizados y, posteriormente, claves de caché.

Mismos encabezados con valores diferentes

Supongamos que el usuario envía varios encabezados con el mismo nombre y con valores diferentes. Por ejemplo:

My-Header: Value1
My-Header: Value2

En este caso, Cloud CDN modifica la solicitud asumiendo que el encabezado debe seguir la convención estándar que permite que algunos encabezados tengan varios valores. Cloud CDN las combina en una lista separada por comas para enviarlas al backend, por lo que es como si el cliente hubiera enviado lo siguiente:

My-Header: Value1, Value2

Incluir cookies con nombre

Una cookie HTTP es un emparejamiento name=value y una solicitud puede incluir varias cookies HTTP, ya sea separadas por un punto y coma en la misma línea o como encabezados de solicitud Cookie independientes con una cookie por encabezado.

Puedes proporcionar una lista de hasta cinco nombres de cookies.

Los agentes de usuario (como los navegadores web) suelen limitar a 4 KB el número de cookies almacenadas por dominio. Asegúrate de no enviar demasiadas cookies (o cookies demasiado grandes), ya que es posible que el agente de usuario no envíe todas las cookies en una solicitud. Esto puede influir en si un usuario recibe una respuesta específica almacenada en caché.

Si sirve su contenido estático desde un nombre de host diferente al que usa para emitir cookies, asegúrese de que el atributo Domain de la cookie (y el atributo Path) permita que la cookie se envíe junto con las solicitudes de contenido estático.

Si una solicitud incluye varias instancias del mismo nombre de cookie, solo se tiene en cuenta la primera.

Directivas de control de caché

Las directivas de control de caché HTTP afectan al comportamiento de Cloud CDN, tal como se indica en la siguiente tabla.

N/A significa que una directiva no se aplica a una solicitud o respuesta.

Siempre que sea posible, Cloud CDN se esfuerza por cumplir el RFC (RFC 7234 de HTTP), pero prioriza la optimización de la descarga de la caché y la minimización del impacto que pueden tener los clientes en la tasa de aciertos y en la carga general del origen.

En las respuestas que usan el encabezado Expires de HTTP/1.1:

• El valor del encabezado Expires debe ser una fecha HTTP válida, tal como se define en RFC 7231.
• Si se indica una fecha anterior, una fecha no válida o el valor 0, significa que el contenido ya ha caducado y debe volver a validarse.
• Si hay un encabezado Cache-Control en la respuesta, Cloud CDN ignora el encabezado Expires.

La presencia de un encabezado Expires válido y futuro en la respuesta permite que esta se almacene en caché y no requiere que se especifiquen otras directivas de caché.

El encabezado Pragma de HTTP/1.0, si está presente en una respuesta, se ignora y se envía tal cual al cliente. Las solicitudes de clientes con este encabezado se envían al origen y no influyen en la forma en que Cloud CDN sirve una respuesta.

Vary encabezados

La cabecera Vary indica que la respuesta varía en función de las cabeceras de solicitud del cliente. Además del URI de solicitud, Cloud CDN respeta los encabezados Vary que los servidores de origen incluyen en las respuestas. Por ejemplo, si una respuesta especifica Vary: Accept, Cloud CDN usa una entrada de caché para las solicitudes que especifican Accept: image/webp,image/*,*/*;q=0.8 y otra para las solicitudes que especifican Accept: */*.

En la tabla de la sección Contenido no almacenable en caché se enumeran los encabezados Vary que permiten almacenar contenido en caché. Otros valores de encabezado Vary impiden que se almacene contenido en caché.

El modo de caché FORCE_CACHE_ALL no anula este comportamiento. Los encabezados Vary son importantes para evitar el envenenamiento de la caché entre varias respuestas posibles del servidor de origen. Sería peligroso que FORCE_CACHE_ALL provocara que esas respuestas se almacenaran en caché.

Las cabeceras Vary se usan a veces cuando se sirve contenido comprimido. Cloud CDN no comprime ni descomprime las respuestas (a menos que se haya habilitado la compresión dinámica), pero puede servir respuestas que el servidor de origen haya comprimido. Si tu servidor de origen elige si sirve contenido comprimido o sin comprimir en función del valor del encabezado de solicitud Accept-Encoding, asegúrate de que la respuesta especifique Vary: Accept-Encoding.

Cuando se usan cabeceras HTTP en la clave de caché, Cloud CDN almacena en caché varias copias de la respuesta en función de los valores de las cabeceras de solicitud especificadas, de forma similar a la compatibilidad con Vary, pero sin que el servidor de origen tenga que especificar explícitamente ninguna cabecera de respuesta Vary. Si el origen especifica los encabezados de clave de caché en la respuesta Vary, Cloud CDN trata la respuesta correctamente, como si los encabezados no se hubieran mencionado en la respuesta Vary.

Tiempos de vencimiento y solicitudes de validación

El tiempo de caducidad de una entrada de caché define el tiempo durante el que esta sigue siendo válida. El valor proporcionado por s-maxage (max-age o expires) permite volver a validar automáticamente el contenido almacenado en caché obsoleto generado por los usuarios.

Cuando Cloud CDN recibe una solicitud, busca la entrada de caché correspondiente y comprueba su antigüedad. Si la entrada de caché existe y está lo suficientemente actualizada, la respuesta se puede proporcionar desde la caché. Si ha pasado el tiempo de vencimiento, Cloud CDN intenta volver a validar la entrada de caché poniéndose en contacto con uno de tus back-ends. Esto se hace antes de servir la respuesta, a menos que habilites serve-while-stale, en cuyo caso la revalidación se realiza de forma asíncrona.

En algunos modos de caché, puedes definir valores de TTL. Para obtener más información, consulta Usar la configuración de TTL y las anulaciones.

El modo de caché afecta a la forma en que se determina la actualización.