CDN Cache Headers: Aprenda a inspecionar

Os response header (cabeçalhos de resposta) fazem com que o cliente e o servidor transmitam informações adicionais com a solicitação ou resposta HTTP. Normalmente são compostos por um nome seguido por dois pontos, como por exemplo, x-cache:

Provavelmente você já deve ter se deparado com algum dos response headers citados abaixo:

• content-encoding: Especifica o algoritmo de compressão.
• content-type: Especifica o tipo de mídia do recurso.
• date: Indica a data e hora que a mensagem foi gerada.
• set-cookie: Envia cookies do servidor para o usuário.
• content-length: Tamanho do corpo da mensagem em decimal.

Além dos response headers citados acima, também é frequente encontrar response headers de cache. Os mais frequentes são:

• age: Tempo em segundos em que o objeto está em cache.
• cache-control: Especifica diretivas para mecanismos de cache em requisições e respostas. Entre as principais diretivas estão: no-cache, max-age, public, private, no-cache.
• expires: Data/hora que a resposta passa a ser considerada como obsoleta.
• x-cache: Apresenta qual o status de cache do asset inspecionado. Pode ser MISS (não cacheado), HIT (entregue por cache) ou BYPASS (entregue diretamente pela infraestrutura).

Como inspecionar os response headers?

Google Chrome:

Inspecionar response headers é algo bem simples de ser feito. Em seu Google Chrome, basta segurar CTRL + SHIFT + I. Feito isso, acesse a aba de “Network” e “Headers”.

Firefox:

O processo de inspecionar response headers no Firefox é o mesmo do Google Chrome. Basta segurar CTRL + SHIFT + I,  e selecionar a opção “rede” ou “network”, dependendo do idioma de sua instalação.

Terminal: 

E caso prefira inspecionar os response headers via terminal, é possível utilizar o comando “curl -I”, conforme vemos abaixo:

CDN Cache Headers: Quais os mais frequentes?

Cada solução de CDN personaliza seus headers, o que acaba gerando bastante confusão para webmasters que estão familiarizados com response headers de cache convencional.

Abaixo, confrima os principais response headers enviados pela GoCache:

• x-gocache-cachestatus: BYPASS
  • Item entregue diretamente pela infraestrutura, sem influência de cache.
• x-gocache-cachestatus: HIT
  • Item entregue em cache pela CDN.
• x-gocache-cachestatus: MISS
  • Item elegível a cache que ainda não está armazenado na CDN. Na próxima requisição um MISS deve virar um HIT.
• x-gocache-cachestatus: EXPIRED
  • Item com cache expirado. Na próxima requisição um EXPIRED deve virar um HIT.
• x-gocache-image: optimized
  • Imagem otimizada pelo conversor de imagens da GoCache
• x-gocache-image: unmodified
  • Imagem não foi modificada/otimizada pelo conversor de imagens da GoCache

E caso esteja em dúvida sobre outros response headers, citamos abaixo exemplos de outras soluções de CDN: 

• cf-cache-status: DYNAMIC
  • Entregue diretamente pela infraestrutura, sem influência de cache.
• cf-cache-status: HIT
  • Entregue em cache.
• cf-cache-status: MISS
  • Elegível a cache, mas ainda não foi entregue pela CDN.
• cf-cache-status: EXPIRED
  • Item que estava em cache, mas expirou.
• cf-ray: local de entrega
  • Indica o pop que serviu um determinado asset. Por exemplo, GRU (SP), ATL (Atlanta), BOS (Boston)

• x-cache: HIT from CloudFront
  • O response header HIT é gerado sempre que um asset é entregue diretamente pelo CloudFront.
• x-cache: MISS from CloudFront
  • O response header MISS quer dizer que o CloudFront ainda não tem o conteúdo salvo em seu edge, logo será necessário consultar o servidor de origem.
• x-cache: BYPASS from CloudFront
  • Sempre que o response header BYPASS for apresentado quer dizer que o CloudFront não fará cache desse asset e a entrega será sempre feita diretamente pela origem.
• x-amz-cf-pop: Localização de entrega
  • Indica por onde o asset foi entregue. Exemplo, GIG51-C2 (RIO), GRU1-C1 (São Paulo).

new RDStationForms(‘newsletter-artigos-blog-842f5cbb60b7ed599409’, ‘UA-47041721-1’).createForm();