Visão geral do armazenamento em cache

Uma resposta armazenável em cache é uma resposta HTTP que o Cloud CDN pode armazenar e recuperar rapidamente, possibilitando tempos de carregamento mais rápidos. Nem todas as respostas HTTP são armazenáveis em cache.

Modos de cache

Com os modos de cache, é possível controlar os fatores que determinam se o Cloud CDN armazena seu conteúdo.

O Cloud CDN oferece três modos de cache, que definem como as respostas serão armazenadas em cache, se o Cloud CDN vai respeitar as diretivas de cache enviadas pela origem e como os TTLs do cache serão aplicados.

Os modos de cache disponíveis são mostrados na tabela a seguir:

Modo de cache Comportamento
CACHE_ALL_STATIC Armazena em cache automaticamente respostas bem-sucedidas com conteúdo estático que não seja não armazenável em cache. Respostas de origem que definem diretivas de armazenamento em cache válidas também são armazenadas em cache.

Esse é o comportamento padrão para os back-ends ativados pelo Cloud CDN criados usando a CLI do Google Cloud ou a API REST.
USE_ORIGIN_HEADERS Requer respostas de origem para definir diretivas de cache e cabeçalhos de cache válidos. As respostas bem-sucedidas sem essas diretivas são encaminhadas pela origem.
FORCE_CACHE_ALL Armazena incondicionalmente as respostas em cache, substituindo as diretivas de cache definidas pela origem. Esse modo não é apropriado se o back-end disponibiliza conteúdo particular por usuário (identificável pelo usuário), como HTML dinâmico ou respostas da API.

As respostas de erro podem ser armazenadas em cache, mesmo na ausência de diretivas de cache válidas.

Antes de definir o modo de cache como FORCE_CACHE_ALL, considere os seguintes comportamentos:

  • Em URLs assinados ou cookies assinados, FORCE_CACHE_ALL substitui a idade máxima especificada usando a configuração de idade máxima da entrada de cache no console do Google Cloud ou na opção gcloud --signed-url-cache-max-age.

  • O FORCE_CACHE_ALL muda o time to live (TTL) de qualquer conteúdo armazenado em cache anteriormente. Essa alteração pode fazer com que algumas entradas que foram consideradas atualizadas anteriormente (devido ao uso de TTLs mais longos nos cabeçalhos de origem) sejam consideradas desatualizadas e fazer com que algumas entradas que foram consideradas desatualizadas anteriormente sejam consideradas atualizadas.

  • O FORCE_CACHE_ALL substitui as diretivas de cache (Cache-Control e Expires), mas não substitui outros cabeçalhos de resposta de origem. Em particular, um cabeçalho Vary pode suprimir o armazenamento em cache, mesmo que o modo de cache seja FORCE_CACHE_ALL. Para mais informações, consulte Cabeçalhos Vary.

Para instruções de configuração, consulte Como definir o modo de cache.

Conteúdo estático

O conteúdo estático é sempre igual, mesmo quando acessado por usuários diferentes. O CSS usado para customizar o site e o JavaScript que fornece conteúdo de interatividade, de vídeo e de imagem normalmente não mudam para cada usuário em um determinado URL (chave de cache) e, portanto, se beneficiam do armazenamento em cache na rede de borda global do Cloud CDN.

Quando o modo de cache é definido como CACHE_ALL_STATIC e uma resposta não tem diretivas de armazenamento em cache explícitas no cabeçalho Cache-Control ou Expires, o Cloud CDN armazena automaticamente essa resposta em cache para o seguinte:

  • Recursos da Web, incluindo CSS (text/css), JavaScript (application/javascript) e todas as fontes da Web, inclusive WOFF2 (font/woff2)
  • Imagens, incluindo JPEG (image/jpg) e PNG (image/png)
  • Vídeos, incluindo H.264, H.265 e MP4 (video/mp4)
  • Arquivos de áudio, incluindo MP3 (audio/mpeg) e MP4 (audio/mp4)
  • Documentos formatados, incluindo PDF (application/pdf)

Veja um resumo na tabela a seguir.

Categoria Tipos MIME
Recursos da Web text/css text/ecmascript text/javascript application/javascript
Fontes Qualquer Content-Type que corresponda a font/*
Imagens Qualquer Content-Type que corresponda a image/*
Vídeos Qualquer Content-Type que corresponda a video/*
Áudio Qualquer Content-Type que corresponda a audio/*
Tipos de documento formatado application/pdf e application/postscript

O Cloud CDN inspeciona o cabeçalho de resposta HTTP Content-Type, que reflete o tipo MIME do conteúdo exibido.

Observe o seguinte:

  • O software servidor da Web de origem precisa definir o Content-Type de cada resposta. Muitos servidores da Web definem automaticamente o cabeçalho Content-Type, incluindo NGINX, Varnish e Apache.

  • O Cloud Storage define o cabeçalho Content-Type automaticamente quando é usado o console do Google Cloud ou a CLI do Google Cloud para fazer upload de conteúdo.

  • O Cloud Storage sempre fornece um cabeçalho Cache-Control para o Cloud CDN. Se nenhum valor for escolhido de maneira explícita, ele enviará um valor padrão. Como resultado, todas as respostas do Cloud Storage são armazenadas em cache de acordo com os valores padrão do Cloud Storage, a menos que você ajuste explicitamente os metadados de controle de cache para objetos no Cloud Storage ou use o modo FORCE_CACHE_ALL para substituir os valores enviados pelo Cloud Storage.

  • Se você quiser armazenar em cache os tipos de conteúdo text/html e application/json, defina cabeçalhos Cache-Control explícitos na resposta. Tenha cuidado para não armazenar em cache, por engano, os dados de um usuário e disponibilizá-los para todos os usuários.

Se uma resposta puder ser armazenada em cache com base no tipo MIME, mas tiver um cabeçalho de resposta Cache-Control de private ou no-store, ou um cabeçalho Set-Cookie, ela não será armazenada em cache. Para saber mais, consulte regras de capacidade de armazenamento em cache.

Outros tipos de conteúdo, como HTML (text/html) e JSON (application/json), não são armazenados em cache por padrão nas respostas. Esses tipos de respostas normalmente são dinâmicos (por usuário). Os exemplos incluem carrinhos de compras, páginas de produtos com personalização do usuário e respostas da API autenticadas. Entretanto, o armazenamento em cache negativo, se ativado, ainda pode fazer com que eles sejam armazenados em cache para determinados códigos de status.

O Cloud CDN não usa extensões de arquivo no caminho do URL para determinar se uma resposta é armazenável em cache porque muitas respostas armazenáveis em cache válidas não são refletidas nos URLs.

Conteúdo armazenável em cache

O Cloud CDN armazena em cache as respostas que atendem a todos os requisitos desta seção. Alguns desses requisitos são especificados no documento RFC 7234 e outros são específicos para o Cloud CDN.

O Cloud CDN pode alterar periodicamente o conjunto exato de condições em que ele armazena conteúdo em cache. Se você quiser impedir explicitamente que o Cloud CDN armazene em cache o conteúdo, siga as diretrizes no documento RFC 7234 para determinar como especificar uma resposta garantida não armazenável em cache. Consulte também a seção conteúdo não armazenável em cache baseado em cabeçalhos de origem.

O Cloud CDN armazenará as respostas em cache se todas as condições a seguir forem verdadeiras.

Atributo Requisito
Disponibilizado por Serviço de back-end, bucket de back-end ou um back-end externo com o Cloud CDN ativado
Em resposta a Solicitação GET:
Código de status

200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 ou 501.
Atualização

A resposta tem um cabeçalho Cache-Control com uma diretiva max-age ou s-maxage ou um cabeçalho Expires com um carimbo de data/hora no futuro.

Para respostas armazenáveis em cache sem uma idade (por exemplo, com no-cache), a diretiva public precisa ser explicitamente fornecida.

Com o modo de cache CACHE_ALL_STATIC, se não houver qualquer diretiva de atualização, uma resposta com o tipo de conteúdo estático ainda será qualificada para armazenamento em cache.

Com o modo de cache FORCE_CACHE_ALL, qualquer resposta é qualificada para armazenamento em cache. Isso pode resultar no armazenamento em cache de conteúdo particular por usuário. Defina FORCE_CACHE_ALL apenas em back-ends que não estejam disponibilizando conteúdo particular ou conteúdo dinâmico, como buckets do Cloud Storage.

Se armazenamento em cache negativo estiver ativado e o código de status corresponder a um status para o qual o armazenamento em cache negativo especifica um TTL, a resposta será qualificada para armazenamento em cache, mesmo sem diretivas de atualização explícitas.
Conteúdo

Para origens HTTP/1, a resposta precisa conter um cabeçalho Content-Length, Content-Range ou Transfer-Encoding: chunked válido.

Para origens que usam versões mais avançadas do protocolo HTTP (HTTP/2 e posteriores), a resposta não precisa ter esses cabeçalhos.
Tamanho Menor ou igual ao tamanho máximo

Para respostas com tamanhos entre 10 MiB e 100 GiB, consulte as outras restrições para armazenamento em cache descritas em solicitações de intervalo de bytes.

Em buckets de back-end do Cloud Storage, siga estas sugestões adicionais:

Por padrão, quando um objeto é público e não especifica metadados Cache-Control, o Cloud Storage atribui um cabeçalho Cache-Control: public, max-age=3600 ao objeto. É possível definir valores diferentes usando metadados Cache-Control.

Para ver um exemplo de como configurar um balanceador de carga de aplicativo externo com um bucket de back-end, consulte Como configurar o Cloud CDN com um bucket de back-end.

Tamanho máximo

O Cloud CDN aplica um tamanho máximo para cada resposta. Qualquer resposta com um corpo maior que o tamanho máximo não é armazenada em cache, mas ainda é entregue ao cliente.

O tamanho máximo varia dependendo se o servidor de origem é compatível com solicitações de intervalo de bytes.

O servidor de origem é compatível com solicitações de intervalo de bytes O servidor de origem não é compatível com solicitações de intervalo de bytes
100 GiB (107.374.182.400 bytes) 10 MiB (10.485.760 bytes)

Quase todos os servidores da Web modernos (incluindo NGINX, Apache e Varnish) são compatíveis com solicitações de intervalo de bytes.

Conteúdo não armazenável em cache com base em cabeçalhos de origem

Existem verificações que bloqueiam o armazenamento em cache das respostas. O Cloud CDN pode alterar periodicamente o conjunto exato de condições em que ele armazena conteúdo em cache. Portanto, se você quiser impedir explicitamente que o Cloud CDN armazene seu conteúdo em cache, siga as diretrizes da norma (RFC 7234) para determinar como especificar uma resposta não garantida armazenável em cache.

O Cloud CDN não armazenará em cache uma resposta se ela não atender aos requisitos de Conteúdo armazenável em cache ou se qualquer uma das seguintes condições for verdadeira.

Atributo Requisito
Disponibilizado por Serviço de back-end ou back-end externo que não tem o Cloud CDN ativado
Cookie Tem um cabeçalho Set-Cookie
Cabeçalho Vary Tem um valor diferente 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, ou um dos cabeçalhos configurados para fazer parte das configurações da chave de cache.
Diretiva de resposta A resposta tem um cabeçalho Cache-Control com a diretiva no-store ou private (a menos que use o modo de cache FORCE_CACHE_ALL, caso em que o cabeçalho Cache-Control é ignorado)
Diretiva de solicitação A solicitação tem uma diretiva Cache-Control: no-store
Autorização de solicitação A solicitação tem um cabeçalho Authorization, a menos que seja substituído pela resposta Cache-Control.
Tamanho Maior que o tamanho máximo

Se Cache-Control: no-store ou private está presente, mas o conteúdo ainda está sendo armazenado em cache, isso ocorre por um dos seguintes motivos:

  • A assinatura de URL está configurada.
  • O modo de cache do Cloud CDN está definido para forçar o armazenamento de todas as respostas.

Evitar o armazenamento em cache

Para evitar que informações particulares sejam armazenadas nos caches do Cloud CDN, faça o seguinte:

  1. Verifique se o modo de cache do Cloud CDN não está definido como FORCE_CACHE_ALL, que armazena todas as respostas incondicionalmente.
  2. Inclua um cabeçalho Cache-Control: private em respostas que não devem ser armazenadas em caches do Cloud CDN ou um cabeçalho Cache-Control: no-store em respostas que não devem ser armazenadas em cache algum, nem mesmo no cache de um navegador da Web.
  3. Não assine URLs que forneçam acesso a informações particulares. Quando o conteúdo é acessado usando um URL assinado, ele é potencialmente qualificado para armazenamento em cache, independentemente de quaisquer diretivas Cache-Control na resposta.
  4. Em solicitações de origem (preenchimento de cache) que incluem o cabeçalho da solicitação Authorization, o Cloud CDN armazena em cache somente as respostas que incluem as diretivas de controle de cache public, must-revalidate ou s-maxage quando o modo de cache é definido como USE_ORIGIN_HEADERS ou CACHE_ALL_STATIC. Isso impede o armazenamento em cache acidental de conteúdo por usuário e de conteúdo que exija autenticação. O modo de cache FORCE_CACHE_ALL não tem essa restrição.

Cabeçalhos de resposta personalizados

Com cabeçalhos de resposta personalizados, é possível especificar cabeçalhos que o balanceador de carga de aplicativo clássico adiciona a respostas encaminhadas por proxy. Cabeçalhos de resposta personalizados permitem refletir o status de cache para os clientes, os dados geográficos dos clientes e os seus próprios cabeçalhos de resposta estática.

Para instruções, consulte Configurar cabeçalhos de resposta personalizados.

Chaves de cache

Cada entrada de cache do Cloud CDN é identificada por uma chave de cache. Quando uma solicitação chega ao cache, ele converte o URI da solicitação em uma chave de cache, depois compara com as chaves das entradas em cache. Se encontrar uma correspondência, o cache retornará o objeto associado a essa chave.

Em serviços de back-end, o padrão do Cloud CDN é usar o URI de solicitação completo como chave de cache. Por exemplo, https://example.com/images/cat.jpg é o URI completo de uma solicitação específica para o objeto cat.jpg. Essa string é usada como chave de cache padrão. Somente as solicitações com uma string idêntica a essa são correspondentes. As solicitações para http://example.com/images/cat.jpg ou https://example.com/images/cat.jpg?user=user1 não são correspondentes.

Nos buckets de back-end, o padrão é que a chave de cache consista no URI sem o protocolo ou o host. Por padrão, somente parâmetros de consulta conhecidos no Cloud Storage são incluídos como parte da chave de cache (por exemplo, "generation").

Assim, em um determinado bucket de back-end, os seguintes URIs são resolvidos para o mesmo objeto armazenado em cache:

  • 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

É possível alterar quais partes do URI são usadas na chave do cache. Embora o nome de arquivo e o caminho sempre façam parte da chave, é possível incluir ou omitir qualquer combinação de protocolo, host ou string de consulta ao personalizar a chave de cache. A seção Como usar as chaves de cache mostra como personalizá-las.

Parte do URI Personalização URLs de exemplo que têm a mesma chave de cache
Protocolo Omita o protocolo da chave de cache.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Host Omita o host da chave de cache.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
String de consulta

Omita a string de consulta da chave de cache.

Omita ou inclua partes da string de consulta de maneira seletiva.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

Além de incluir ou omitir toda a string de consulta, é possível usar partes dela com listas de inclusão e de exclusão.

Lista de inclusão da string de consulta

É possível controlar quais são os parâmetros da string de consulta que o Cloud CDN incorpora às chaves de cache. Por exemplo, se você criar uma lista de inclusão de user, https://example.com/images/cat.jpg?user=user1&color=blue criará uma chave de cache de https://example.com/images/cat.jpg?user=user1 que também corresponde a https://example.com/images/cat.jpg?user=user1&color=red.

Para usar essa opção, é preciso incluir a string de consulta, especificar uma lista de inclusão não vazia e não especificar uma lista de exclusão.

Lista de inclusão da string de consulta para chaves de cache do Cloud Storage

A inclusão de parâmetros de consulta de URL em chaves de cache para buckets do Cloud Storage ajuda no suporte a cache busting. O cache busting permite que um usuário recupere uma nova versão do arquivo que foi enviado, mesmo que a versão anterior ainda esteja armazenada em cache de maneira válida com base na configuração do TTL.

É possível usar uma lista de inclusão com parâmetros de string de consulta na chave de cache usada para disponibilizar respostas de um bucket de back-end. O Cloud Storage não disponibiliza conteúdos ou rotas diferentes com base nos parâmetros de consulta, mas é possível incluir parâmetros que permitam aplicar cache busting ao conteúdo estático armazenado em buckets do Cloud Storage.

Por exemplo, é possível anexar um parâmetro de consulta ?version=VERSION ou ?hash=HASH com base no conteúdo subjacente. Isso limita a necessidade de invalidar proativamente o conteúdo e se alinha com fluxos de trabalho de desenvolvimento moderno da Web, em que frameworks e URLs da Web usam um hash do conteúdo para evitar a disponibilização de objetos desatualizados nas implantações.

Como a inclusão de parâmetros de consulta na chave de cache é apenas para permissão, o Cloud CDN não é compatível com a exclusão de parâmetros de consulta para um bucket de back-end.

Lista de exclusões da string de consulta

Para controlar, de maneira seletiva, os parâmetros de string de consulta que o Cloud CDN ignora, use uma lista de exclusão. Por exemplo, se for criada uma lista de exclusão de user, todos os parâmetros de string de consulta, exceto user, serão usados na chave de cache.

Com a lista de exclusão configurada e uma entrada de https://example.com/images/cat.jpg?user=user1&color=blue, o Cloud CDN cria uma chave de cache de https://example.com/images/cat.jpg?color=blue que também corresponde a https://example.com/images/cat.jpg?user=user2&color=blue, mas não a https://example.com/images/cat.jpg?user=user1&color=red.

Para usar essa opção, é preciso incluir a string de consulta, especificar uma lista de exclusão não vazia e não especificar uma lista de inclusão.

Ordem do parâmetro de consulta

A chave de cache gerada não depende da ordem dos parâmetros de consulta.

Por exemplo, os seguintes parâmetros de consulta geram a mesma chave de cache:

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

Configurações de cabeçalhos HTTP e cookies HTTP

É possível melhorar as taxas de ocorrência em cache e o descarregamento de origem com as seguintes configurações de chave de cache:

  • Para serviços e buckets de back-end: use cabeçalhos HTTP como parte das chaves de cache ao incluir cabeçalhos nomeados na configuração da chave de cache.
  • Somente para serviços de back-end: use cookies HTTP nomeados como chaves de cache, por exemplo, para testes A/B (multivariáveis), canários e cenários semelhantes.

As solicitações de cache que incluem cabeçalhos ou cookies HTTP adicionais na solicitação são armazenadas em cache na terceira solicitação em um local de cache dessa chave de cache. Isso reduz o impacto dos altos valores de cabeçalhos ou cookies de cardinalidade nas taxas de remoção de cache. Em circunstâncias e condições de tráfego do usuário normais, isso pode não ser perceptível e ajuda a garantir que o conteúdo em alta permaneça armazenado em cache.

Incluir cabeçalhos da solicitação

Para armazenar em cache mais variações de uma resposta, é possível incluir outros cabeçalhos de solicitação na chave de cache.

Alguns cabeçalhos não são permitidos em chaves de cache porque normalmente são de cardinalidade muito alta. Na maioria dos casos, os valores desses cabeçalhos são exclusivos por usuário (Cookie, Authorization) ou consistem em milhares de valores prováveis (Referer, User-Agent, Accept). Por exemplo, o cabeçalho User-Agent pode ter mais de 5.000 valores exclusivos, considerando a grande variedade de navegadores, dispositivos do usuário e sistemas operacionais. Esses tipos de cabeçalho teriam um impacto negativo grave nas taxas de ocorrência em cache.

Somente nomes de campo de cabeçalho HTTP válidos são aceitos de acordo com a norma RFC 7230. Os nomes dos campos de cabeçalho não diferenciam maiúsculas de minúsculas e cópias são rejeitadas.

Opcionalmente, é possível configurar o servidor de origem para incluir cabeçalhos da solicitação de chave de cache configurados na resposta Vary. Ele não é necessário para o Cloud CDN, mas pode ser útil para caches downstream. Para mais informações, consulte Cabeçalhos Vary.

O Cloud CDN não permite que os seguintes cabeçalhos sejam incluídos na lista de cabeçalhos:

  • Accept
  • Accept-Encoding
  • Authority, porque é controlado pela configuração (cdnPolicy.includeHost)
  • Authorization, normalmente por usuário, como em tokens Bearer do OAuth
  • CDN-Loop
  • Connection
  • Content-MD5
  • Content-Type
  • Cookie
  • Date
  • Forwarded, geralmente por cliente ou por proxy