CDN:Configure CDN cache expiration time

Funcionamento

Ao receber uma requisição em um ponto de presença (POP) da CDN, o sistema avalia se deve entregar uma cópia em cache ou buscar o conteúdo mais recente no servidor de origem. As etapas abaixo são processadas por ordem de prioridade, em que números menores indicam maior prioridade.

1. Diretivas de não armazenamento em cache da origem — A CDN não armazena um recurso em cache quando o servidor de origem responde com Pragma: no-cache, Cache-Control: no-cache, Cache-Control: no-store ou Cache-Control: max-age=0. Para forçar o armazenamento desses recursos, selecione Ignore Origin No-Cache Header ao configurar a regra de expiração do cache.

2. Regras de cache definidas no console — As configurações realizadas no console da CDN têm precedência, exceto quando a origem envia explicitamente uma diretiva de não armazenamento conforme descrito na etapa 1. Caso múltiplas regras do console correspondam à mesma requisição, aquela com maior peso prevalece. Se os pesos forem idênticos, a regra criada primeiro é aplicada. Após uma requisição corresponder a uma regra de cache, nenhuma outra avaliação ocorre.

3. Cabeçalhos de resposta da origem — A CDN respeita os cabeçalhos de resposta HTTP do servidor de origem caso a requisição não corresponda a nenhuma regra do console da CDN, ou se a regra correspondente tiver a opção Honor Origin TTL ativada. A prioridade dos cabeçalhos, do maior para o menor, é: Cache-Control > Expires > Last-Modified > ETag.

4. Política padrão de não armazenamento — Quando a requisição não corresponde a nenhuma regra de cache no console da CDN e o servidor de origem não retorna cabeçalhos de cache como Cache-Control, a CDN aplica automaticamente uma política de não armazenamento em cache.

5. A CDN DCDN aplica políticas de cache apenas para requisições cujo servidor de origem retorne códigos de status 200, 203, 206, 300, 301, 308 ou 410. Para definir o tempo de expiração de códigos como 404, utilize a página Cache Settings > Status Code TTL.

A tabela a seguir detalha a lógica de prioridade quando várias regras de cache do console correspondem a uma mesma requisição:

A tabela abaixo explica como cada cabeçalho de resposta da origem é tratado:

Lógica de correspondência de regras de cache

As regras de expiração do cache da CDN oferecem dois tipos de configuração com comportamentos distintos de correspondência:

• Directory: Corresponde por prefixo de caminho. Por exemplo, ao configurar /static/, todos os recursos dentro desse diretório serão abrangidos (como /static/image/1.jpg e /static/css/style.css). Definir / abrange todos os caminhos. O caminho do diretório deve começar com barra (/), e cada regra aceita apenas um diretório.

• File Extension: Corresponde exatamente pela extensão do arquivo. Insira as extensões sem pontos e separe-as por vírgulas (por exemplo, jpg,css,js). São aceitos apenas caracteres alfanuméricos, sem restrições quanto aos tipos específicos. É possível configurar os seguintes grupos:

  • Extensões comuns de recursos estáticos: jpg, png, gif, css, js, html

  • Extensões de arquivos de fonte: ttf, otf, woff, woff2, eot

  • Extensões de páginas dinâmicas: php, aspx, jsp

  • Qualquer outra extensão alfanumérica

Observe os pontos importantes sobre a correspondência de regras de cache:

• Quando diversas regras de cache correspondem à mesma requisição (por exemplo, uma regra de diretório e outra de extensão), prevalece aquela com maior Weight. Em caso de empate no peso, a regra criada primeiro vence. Consulte Funcionamento para mais detalhes.

• Ao associar uma condição de regra (configurada no Mecanismo de Regras) a uma regra de cache, múltiplas condições seguem a lógica AND; a requisição precisa atender a todas elas para haver correspondência.

• Caso defina uma regra geral de não armazenamento para todas as extensões dinâmicas (como aspx), certifique-se de que isso não afete recursos estáticos que devam permanecer em cache. Para armazenar arquivos de fonte, crie uma regra dedicada com extensões como ttf,otf,woff,woff2,eot.

Procedimento

Aplicar alterações de regra imediatamente

Para que novas regras tenham efeito imediato em toda a rede, limpe manualmente o cache existente. Se você alterou uma regra, remova o cache atual usando o recurso Purge and prefetch resources. Caso tenha adicionado uma nova regra, pré-busque o recurso através do recurso prefetch resource.

Validação

Após concluir a configuração, utilize o comando curl ou as ferramentas de desenvolvedor do navegador para inspecionar os cabeçalhos de resposta HTTP de um recurso e confirmar se o cache opera conforme o esperado. Para detalhes sobre quando uma mudança de regra entra em vigor, consulte Aplicar alterações de regra imediatamente.

curl -I "https://your.domain.com/path/to/file.jpg"

Melhores práticas

• Adote nomes de arquivo versionados (recomendado) — Sempre que atualizar um recurso estático como style.css, renomeie-o incluindo uma versão ou hash, por exemplo, style-v2.css ou style-a1b2c3d.css, e ajuste a referência no HTML. Essa abordagem garante que os usuários recebam o conteúdo atualizado instantaneamente, eliminando a necessidade de limpar manualmente o cache da CDN. É a forma mais segura de gerenciar atualizações de conteúdo em cache.

• Otimize o uso do cache do navegador — Ative a opção Follow POP Cache Policy para diminuir requisições repetidas à CDN, acelerar o carregamento das páginas e economizar tráfego da CDN.

• Evite tempos de cache excessivamente curtos — Durações muito breves forçam a CDN a buscar conteúdo na origem constantemente, anulando os benefícios da aceleração e elevando tanto o tráfego quanto os custos do servidor de origem.

• Tenha cautela com caches muito longos — Prazos extensos podem impedir que os clientes recebam atualizações de conteúdo rapidamente. Para informações que mudam com frequência, lembre-se de limpar o cache ou utilizar nomes de arquivo versionados.

• Cenários de jogos e arquivos pequenos — Recursos pequenos típicos da indústria de jogos (arquivos de configuração, pacotes de assets) que sofrem atualizações esporádicas (semanais ou quinzenais) devem ter expiração de cache de 15 dias ou alinhada ao ciclo real de atualização. Esse equilíbrio preserva a performance de aceleração sem comprometer a entrega de novidades. Caches curtos demais geram buscas frequentes na origem e reduzem a eficiência; caches longos demais podem entregar conteúdo obsoleto aos jogadores. (Recomendado) Utilize o recurso purge and prefetch para renovar proativamente o cache sempre que houver mudanças no conteúdo.

• Arquivos robots.txt e sitemap.xml — Esses arquivos influenciam diretamente a indexação por mecanismos de busca. Configure a duração de cache deles separadamente para evitar que regras amplas de extensão os mantenham em cache por tempo excessivo, atrasando atualizações críticas. (Recomendado) Para atingir apenas esses dois arquivos, escolha Directory como tipo, insira o caminho exato (como /robots.txt) no campo Object e defina um peso alto para sobrescrever regras gerais de extensão. Se preferir configurar por extensão, estabeleça um cache entre 1 hora e 1 dia para txt,xml. Lembre-se de que regras de extensão afetam todos os arquivos daquele tipo, não apenas robots.txt e sitemap.xml. Sitemaps com atualizações frequentes devem ter cache de no máximo 1 hora.

Solução de problemas

Para orientações sobre como resolver falhas na aplicação do cache, misses de cache, baixa taxa de acerto ou conteúdo desatualizado, consulte Troubleshoot cache issues.

Apêndice: Mecanismos de controle de cache HTTP

Esta seção apresenta conceitos fundamentais do protocolo. Para entender o comportamento correspondente nos POPs, veja Funcionamento. O protocolo HTTP emprega três categorias de cabeçalhos para gerenciar o cache:

1. Validação por tempo de expiração

   Cliente e servidor acordam um prazo de validade quando o recurso é solicitado. Dentro desse período, a cópia em cache permanece válida. Passado esse tempo, ela se torna obsoleta.

   No HTTP, os cabeçalhos abaixo são os mais usados para controlar a expiração do cache:

   Cabeçalho	Versão do protocolo	Descrição	Exemplo	Tipo
   Pragma	HTTP/1.0	Determina se o conteúdo pode ser armazenado. Geralmente assume o valor no-cache, impedindo o cache. Seu uso visa principalmente compatibilidade com servidores restritos ao HTTP/1.0.	Pragma: no-cache	Requisição/Resposta
   Expires	HTTP/1.0	O cabeçalho Expires define a data e hora exatas em que o conteúdo em cache perde a validade. Valores inválidos, como 0, indicam que o recurso já expirou.	Expires: Wed, 21 Oct 2022 07:28:00 GMT	Resposta
   Cache-Control	HTTP/1.1	Oferece controle flexível do cache por meio de diversas diretivas. É o principal cabeçalho utilizado por clientes modernos, como navegadores, para essa finalidade.	Três exemplos que impedem o armazenamento: Cache-Control: no-cache; Cache-Control: no-store; Cache-Control: max-age=0. Exemplo de validade de 1 hora: Cache-Control: max-age=3600.	Requisição/Resposta

2. Validação por tag de recurso

   O servidor envia uma etiqueta identificadora (como ETag) na resposta inicial. Em requisições subsequentes para o mesmo recurso, o cliente devolve essa tag para validação. Se nada mudou, o servidor responde com o código HTTP 304, permitindo o uso da cópia local. Caso contrário, transmite o conteúdo atualizado.

   Os cabeçalhos HTTP a seguir são comumente empregados para validar versões de cache:

   Cabeçalho	Versão do protocolo	Descrição	Exemplo	Tipo
   Last-Modified	HTTP/1.0	Informa a data da última modificação do recurso.	Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT	Resposta
   ETag	HTTP/1.1	Fornece um identificador exclusivo para uma versão específica do recurso. A comparação de ETags revela se houve alterações. Sem mudanças, o servidor de origem evita enviar uma resposta completa.	ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"	Resposta

3. Negociação de conteúdo

   Softwares de cache utilizam uma chave para indexar objetos armazenados em disco. No HTTP/1.0, a URL do recurso servia como chave. Contudo, uma mesma URL pode hospedar diferentes representações de um recurso. Para diferenciá-las, são necessárias informações adicionais do cliente, como os cabeçalhos Accept-Language e Accept-Charset. Visando suportar a negociação de conteúdo, o HTTP/1.1 introduziu o cabeçalho Vary na mensagem de resposta, listando quais cabeçalhos de requisição são necessários para tal negociação.

   A negociação de conteúdo geralmente recorre ao cabeçalho HTTP Vary para distinguir cópias em cache distintas, possibilitando que clientes variados recebam versões adequadas ao solicitarem o mesmo recurso: