Descripción general del almacenamiento en caché

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

Modos de almacenamiento en caché

Con los modos de almacenamiento en caché, puedes controlar los factores que determinan si Cloud CDN almacena en caché tu contenido.

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

Los modos de almacenamiento en caché disponibles se muestran en la siguiente tabla:

Modo de almacenamiento en caché	Comportamiento
CACHE_ALL_STATIC	Almacena en caché de forma automática las respuestas exitosas con contenido estático que, de otra forma, no se puede almacenar en caché. Las respuestas de origen que establecen directivas de almacenamiento en caché válidas también se almacenan en caché. Este es el comportamiento predeterminado para los backends habilitados para Cloud CDN que se crean con Google Cloud CLI o la API de REST.
USE_ORIGIN_HEADERS	Requiere respuestas de origen exitosas para establecer directivas y encabezados de almacenamiento en caché válidos. Las respuestas exitosas sin estas directivas se reenvían desde el origen.
FORCE_CACHE_ALL	Almacena en caché las respuestas exitosas sin excepción y se anulan las directivas de caché que estableció el origen. Este modo no es apropiado si el backend entrega contenido privado por usuario (lo que permita identificarlo), como respuestas de la API o HTML dinámicas.

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

Antes de configurar el modo de almacenamiento en caché en FORCE_CACHE_ALL, considera los siguientes comportamientos:

• Para las URLs o cookies firmadas, FORCE_CACHE_ALL anula la antigüedad máxima especificada a través del parámetro de configuración Antigüedad máxima de la entrada en la caché en la consola de Google Cloud o en la opción gcloud --signed-url-cache-max-age.

• FORCE_CACHE_ALL cambia el tiempo de actividad (TTL) de cualquier contenido que se haya almacenado en caché con anterioridad. Este cambio puede hacer que algunas entradas que antes se consideraron actualizadas (debido a tener unos TTL más largos de los encabezados de origen) se consideren inactivas, y puede causar que algunas entradas que antes se consideraron inactivas se consideren actualizadas.

• FORCE_CACHE_ALL anula las directivas de caché (Cache-Control y Expires), pero no anula otros encabezados de respuesta de origen. En particular, un encabezado Vary podría suprimir el almacenamiento en caché incluso si el modo de caché es FORCE_CACHE_ALL. Para obtener más información, consulta Encabezados Vary.

Para obtener instrucciones de configuración, consulta Configura el modo de almacenamiento en caché.

Contenido estático

El contenido estático es siempre el mismo, incluso cuando acceden usuarios diferentes. El CSS que usas a la hora de diseñar tu sitio y JavaScript, para proporcionar interactividad, video y contenido de imagen, no suelen cambiar para cada usuario de una URL determinada (clave de caché), de modo que se benefician de almacenarse en caché en la red perimetral global de Cloud CDN.

Cuando configuras el modo de almacenamiento en 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é esa respuesta de forma automática para lo siguiente:

• Activos web, como 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)
• Videos, incluidos H.264, H.265 y MP4 (video/mp4)
• Archivos de audio, incluidos MP3 (audio/mpeg) y MP4 (audio/mp4)
• Documentos con formato, incluido PDF (application/pdf)

En la siguiente tabla, se proporciona un resumen.

Categoría	Tipos de MIME
Elementos web	text/css text/ecmascript text/javascript application/javascript
Fuentes	Cualquier Content-Type que coincida con font/*
Imágenes	Cualquier Content-Type que coincida con image/*
Videos	Cualquier Content-Type que coincida con video/*
Audio	Cualquier Content-Type que coincida con audio/*
Tipos de documentos con formato	application/pdf y application/postscript

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

Ten en cuenta lo siguiente:

• El software del servidor web de origen debe configurar el Content-Type para cada respuesta. Muchos servidores web configuran de forma automática el encabezado Content-Type, incluidos NGINX, Varnish y Apache.

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

• Cloud Storage siempre brinda un encabezado Cache-Control a Cloud CDN. Si no se elige un valor de forma explícita, se envía un valor predeterminado. Como resultado, todas las respuestas exitosas de Cloud Storage se almacenan en caché según los valores predeterminados de Cloud Storage, a menos que ajustes de forma explícita los metadatos de control de caché para los objetos en Cloud Storage o uses el modo FORCE_CACHE_ALL para anular los valores que envía Cloud Storage.

• Si deseas almacenar en caché tipos de contenido text/html y application/json, debes configurar encabezados Cache-Control explícitos en la respuesta, con cuidado de no almacenar en caché los datos de un usuario y entregarlos a todos los usuarios por accidente.

Si una respuesta se puede almacenar en caché según su tipo de MIME, pero tiene un encabezado de respuesta Cache-Control de private ono-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 obtener respuestas exitosas. Estos tipos de respuestas suelen ser dinámicas (por usuario). Algunos ejemplos son los carritos de compras, las páginas de productos con la personalización del usuario y las respuestas de la API autenticadas. Sin embargo, si el almacenamiento en caché negativo está habilitado, aún puede hacer que estos se almacenen para ciertos códigos de estado.

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

Contenido que se puede almacenar en caché

Cloud CDN almacena en caché las respuestas que cumplen con todos los requisitos de esta sección. El RFC 7234 especifica algunos de estos requisitos, y otros son característicos de Cloud CDN.

Cloud CDN puede cambiar periódicamente el conjunto de condiciones exacto en el que se almacena en caché el contenido. Si deseas evitar de forma explícita que Cloud CDN almacene en caché tu contenido, sigue los lineamientos de RFC 7234 para determinar cómo especificar una respuesta garantizada no almacenable en caché. Consulta también la sección Contenido que no se puede almacenar en caché según los encabezados de origen.

Cloud CDN almacena las respuestas en caché si se cumplen todas las condiciones que figuran a continuación.

Atributo	Requisito
Entregado por	Servicio de backend, bucket de backend o un backend externo con Cloud CDN habilitado
En respuesta a	Solicitud GET
Código de estado	200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 o 501.
Actualización	La respuesta tiene un encabezado Cache-Control con una directiva max-age o s-maxage, o un encabezado Expires con una marca de tiempo en el futuro. Para las respuestas que pueden almacenarse en caché sin una antigüedad (por ejemplo, con no-cache), se debe brindar la directiva public de forma explícita. Con el modo de almacenamiento en caché CACHE_ALL_STATIC, si no hay directivas de actualización, una respuesta exitosa con tipo de contenido estático aún es apta para el almacenar en caché. Con el modo de almacenamiento en caché FORCE_CACHE_ALL, cualquier respuesta exitosa es apta para este tipo de almacenamiento. Esto podría provocar que se almacene en caché el contenido privado por usuario. Solo debes configurar FORCE_CACHE_ALL en backends que no entreguen contenido dinámico ni privado, como buckets de Cloud Storage. Si el almacenamiento en caché negativo está habilitado y el código de estado coincide con uno para el que este almacenamiento especifica un TTL, la respuesta es apta para el almacenamiento en caché, incluso sin directivas de actualización explícitas.
Contenido	Para los orígenes HTTP/1, la respuesta debe contener un encabezado Content-Length, Content-Range o Transfer-Encoding: chunked válido. En el caso de los orígenes que usan versiones más avanzadas del protocolo HTTP (HTTP/2 y posteriores), la respuesta no necesita tener esos encabezados.
Tamaño	Menor o igual que el tamaño máximo. Para las respuestas con tamaños entre 10 MiB y 100 GiB, consulta las restricciones adicionales de capacidad de almacenamiento en caché que se describen en las solicitudes de rango de bytes.

Para los buckets de backend de Cloud Storage, sigue estas sugerencias adicionales:

• Haz que el bucket sea legible de forma pública. Este es el enfoque que recomendamos para el contenido público. Con esta configuración, cualquier persona en Internet puede ver y enumerar tus objetos y sus metadatos, sin incluir las LCA. Se recomienda dedicar buckets específicos para objetos públicos.

• Usa carpetas administradas para hacer que una parte de tu bucket sea legible de forma pública.

• Haz que los objetos individuales se puedan leer de forma pública. No recomendamos este enfoque, ya que utiliza un sistema de permisos heredado y específico de Cloud Storage.

• No almacenes el objeto en un bucket que tenga habilitada la opción Pagos del solicitante ni que resida dentro de un perímetro de servicio de la nube privada virtual.

• No encriptes el objeto con claves de encriptación administradas por el cliente ni con claves de encriptación 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 configurar diferentes valores usando los metadatos Cache-Control.

Para ver un ejemplo que muestra cómo configurar un balanceador de cargas de aplicaciones externo con un bucket de backend, consulta Configura Cloud CDN con un bucket de backend.

Tamaño máximo

Cloud CDN aplica un tamaño máximo para cada respuesta. Toda respuesta que tenga un cuerpo mayor que el tamaño máximo no se almacenará en la memoria caché, pero se entregará al cliente.

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

El servidor de origen es compatible con solicitudes de rango de bytes	El servidor de origen no es compatible con solicitudes de rango de bytes
100 GiB (107,374,182,400 bytes).	10 MiB (10,485,760 bytes)

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

Contenido que no se puede almacenar en caché según los encabezados de origen

Hay controles que bloquean el almacenamiento en caché de las respuestas. Es posible que Cloud CDN cambie periódicamente el conjunto exacto de condiciones en las que almacena en caché el contenido. Por esta razón, si deseas evitar de forma explícita que Cloud CDN almacene el contenido en caché, sigue los lineamientos del estándar (RFC 7234) para determinar cómo especificar una respuesta garantizada no almacenable en caché.

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

Atributo	Requisito
Entregado por	Servicio de backend o backend externo que no tiene habilitado Cloud CDN
Cookie	Tiene un encabezado Set-Cookie
Encabezado Vary	Tiene un valor distinto de Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, X-Goog-Allowed-Resources, X-Origin o uno de los encabezados configurados para formar parte de la configuración de la clave de caché.
Directiva de respuesta	La respuesta tiene un encabezado Cache-Control con la directiva no-store o private (a menos que se use el modo de almacenamiento en caché FORCE_CACHE_ALL, en cuyo caso se ignorará el encabezado Cache-Control).
Directiva de solicitud	La solicitud tiene una directiva Cache-Control: no-store
Solicitar autorización	La solicitud tiene un encabezado Authorization, a menos que la respuesta de control de caché lo anule.
Tamaño	Más grande que el tamaño máximo

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

• Se configuró la firma de URL
• El modo de almacenamiento en caché de Cloud CDN se configuró para forzar el almacenamiento en caché de todas las respuestas

Cómo evitar el almacenamiento en caché

Para evitar que la información privada se almacene en caché en Cloud CDN, haz lo que se detalla a continuación:

1. Asegúrate de que el modo de almacenamiento en caché de Cloud CDN no esté configurado en el modo FORCE_CACHE_ALL, que almacena en caché todas las respuestas sin excepción.
2. Incluye un encabezado Cache-Control: private en las respuestas que no deben almacenarse en cachés de Cloud CDN o un encabezado Cache-Control: no-store en las respuestas que no deben almacenarse en ninguna caché, ni siquiera en la de un navegador web.
3. No firmes URLs que brinden acceso a información privada. Cuando se accede al contenido con una URL firmada, puede ser apto para el almacenamiento en caché, sin importar las directivas Cache-Control en la respuesta.
4. Para las solicitudes de origen (llenado de caché) que incluyen el encabezado de la solicitud Authorization, Cloud CDN solo almacena en caché las respuestas que incluyen la directiva de control de caché public, must-revalidate o s-maxage cuando el modo de almacenamiento en caché está configurado en USE_ORIGIN_HEADERS o CACHE_ALL_STATIC. Esto evita el almacenamiento en caché accidental o el contenido por usuario que requiere autenticación. El modo de almacenamiento en caché 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 cargas de aplicaciones clásico agrega a las respuestas que se envían a través de proxy. Los encabezados de respuesta personalizados te permiten reflejar el estado de la caché para tus clientes, los datos geográficos del cliente y tus propios encabezados de respuesta estática.

Para obtener instrucciones, consulta Configura encabezados de respuesta personalizados.

Claves de caché

Cada entrada de caché en una memoria caché de Cloud CDN se identifica a través de una clave de caché. Cuando una solicitud ingresa a la caché, la memoria caché convierte el URI de la solicitud en una clave de caché y, luego, la compara con las claves de las entradas almacenadas en caché. Si encuentra una coincidencia, la caché devuelve el objeto asociado con esa clave.

De forma predeterminada, Cloud CDN usa el URI de solicitud completo como la clave de caché para los servicios de backend. Por ejemplo, https://example.com/images/cat.jpg es el URI completo de una solicitud específica para el objeto cat.jpg. Esta cadena se usa como la clave de caché predeterminada. Solo coinciden las solicitudes que poseen esta cadena exacta. Las solicitudes de http://example.com/images/cat.jpg o https://example.com/images/cat.jpg?user=user1 no coinciden.

En los buckets de backend, el valor predeterminado de la clave de caché consiste en el URI sin el protocolo o el host. De forma predeterminada, solo los parámetros de consulta que se conocen en Cloud Storage se incluyen como parte de la clave de caché (por ejemplo, "generación").

Por lo tanto, para un bucket de backend determinado, los siguientes URI 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

Puedes cambiar qué partes del URI se usan en la clave de caché. Si bien el nombre de archivo y la ruta de acceso siempre deben formar parte de la clave, puedes incluir, o bien omitir, cualquier combinación de protocolo, host o cadena de consulta cuando personalices la clave de caché. En Usa claves de caché se describe cómo personalizar las claves de caché.

Parte del URI	Personalización	URL de ejemplo que tienen la misma clave de caché
Protocolo	Omite el protocolo desde la clave de caché.	https://example.com/images/cat.jpg http://example.com/images/cat.jpg
Host	Omite el host de la clave de caché.	https://example.com/images/cat.jpg https://example2.com/images/cat.jpg
String de consulta	Omite la string de consulta en la clave de caché. Omite o incluye partes de la string de consulta de manera selectiva.	https://example.com/images/cat.jpg?user=user1 https://example.com/images/cat.jpg?user=user2

Además de omitir o incluir toda la cadena de consulta, puedes usar partes de esa cadena con el uso de listas de inclusiones y exclusiones.