Guia de Cache HTTP: Acelere Seu Site Sem Infraestrutura Extra

Racks de servidores em um data center

O cache é a otimização de desempenho com maior retorno que você pode implementar. Uma resposta em cache é servida em microssegundos, não tem custo e exige zero processamento do servidor. No entanto, a maioria das aplicações usa cache de forma excessiva (servindo conteúdo desatualizado) ou não usa nada (desperdiçando banda e processamento). Entender o cache HTTP transforma o que era fonte de bugs em uma ferramenta poderosa.

Como o cache HTTP funciona

Quando um navegador ou CDN recebe uma resposta, ele verifica os headers para decidir se deve fazer cache e por quanto tempo. Na próxima requisição para o mesmo recurso, ele pode servir a cópia em cache — sem sequer tocar no seu servidor.

O ciclo de vida do cache tem duas fases:

Frescor — A cópia em cache ainda é válida? Determinado por Cache-Control: max-age ou Expires.
Validação — Se estiver desatualizada, podemos confirmar com o servidor que o conteúdo não mudou? Determinado por ETag ou Last-Modified.

Cache-Control: a diretiva principal de cache

Cache-Control é o header de cache mais poderoso. É uma lista de diretivas separadas por vírgulas:

Cache-Control: public, max-age=31536000, immutable

Principais diretivas

Diretiva	Significado
`public`	Qualquer cache (navegador, CDN, proxy) pode armazenar isso
`private`	Somente o navegador do usuário final pode fazer cache (não CDNs)
`no-cache`	Deve revalidar com o servidor antes de cada uso (não significa "não faça cache")
`no-store`	Nunca fazer cache — para dados sensíveis
`max-age=N`	Fazer cache por N segundos
`s-maxage=N`	Idade máxima específica para CDN (substitui `max-age` para caches compartilhados)
`immutable`	O conteúdo nunca mudará — ignora revalidação completamente
`must-revalidate`	Quando desatualizado, deve revalidar antes de servir
`stale-while-revalidate=N`	Serve o conteúdo desatualizado por N segundos enquanto busca o novo em segundo plano

⚠️ no-cache NÃO significa "não faça cache." Significa "faça cache, mas sempre verifique se ainda é válido." Use no-store se você realmente não quiser que algo seja armazenado em cache.

Estratégia de cache por tipo de recurso

Diferentes recursos precisam de diferentes estratégias:

Assets estáticos com hash de conteúdo (CSS, JS, imagens)

Cache-Control: public, max-age=31536000, immutable

Se sua ferramenta de build adiciona um hash ao nome dos arquivos (main.a3f9b2c.js), a URL muda quando o conteúdo muda. Faça cache para sempre — qualquer nova versão recebe uma nova URL.

Páginas HTML

Cache-Control: no-cache

Ou com um TTL curto:

Cache-Control: public, max-age=60, stale-while-revalidate=3600

O HTML muda com frequência e referencia os assets com hash. Faça cache por pouco tempo ou force a revalidação.

Respostas de API

# Dados públicos (ex.: catálogo de produtos)
Cache-Control: public, max-age=300, stale-while-revalidate=600

# Dados específicos do usuário
Cache-Control: private, max-age=60

# Dados em tempo real (preços de ações, placares ao vivo)
Cache-Control: no-store

Dados sensíveis (autenticação, pagamento)

Cache-Control: no-store

Nunca fazer cache. Ponto final.

ETags e requisições condicionais

Quando uma resposta em cache expira, o navegador não a descarta simplesmente — ele pergunta ao servidor se ainda é válida. Isso é a revalidação.

ETags

Uma ETag é uma impressão digital do conteúdo da resposta:

# Servidor envia:
ETag: "a3f9b2c8d4e1"

# Próxima requisição do navegador:
If-None-Match: "a3f9b2c8d4e1"

# Se não mudou, o servidor responde:
HTTP/1.1 304 Not Modified
(sem corpo — economiza banda)

# Se mudou, o servidor responde:
HTTP/1.1 200 OK
ETag: "b7c2d4e9a1f3"
(resposta completa nova)

Uma resposta 304 Not Modified não tem corpo — apenas headers. Isso economiza toda a banda que seria gasta para baixar o conteúdo novamente.

Last-Modified

Similar, mas usa um timestamp em vez de um hash:

Last-Modified: Tue, 01 Apr 2026 10:00:00 GMT

# Navegador envia:
If-Modified-Since: Tue, 01 Apr 2026 10:00:00 GMT

ETags são mais confiáveis (timestamps podem ser imprecisos em servidores com balanceamento de carga).

Header Vary: cache por variante de requisição

O header Vary informa aos caches quais headers de requisição afetam a resposta:

Vary: Accept-Encoding

Isso armazena em cache uma cópia separada para respostas gzip e br. Usos comuns:

Vary: Accept-Encoding          # Caches separados para comprimido/não comprimido
Vary: Accept-Language          # Caches separados por idioma
Vary: Accept                   # Caches separados para respostas JSON vs HTML

⚠️ Vary: Cookie ou Vary: Authorization efetivamente desativa o cache da CDN — CDNs não conseguem fazer cache de respostas específicas por usuário.

stale-while-revalidate: atualização em segundo plano

Um dos padrões de cache modernos mais úteis:

Cache-Control: max-age=60, stale-while-revalidate=600

Serve instantaneamente do cache pelos primeiros 60 segundos (fresco)
Para requisições entre 60–660 segundos: serve a cópia desatualizada imediatamente, mas busca uma versão nova em segundo plano
Após 660 segundos: deve revalidar antes de servir

Os usuários sempre recebem uma resposta rápida. O cache se mantém atualizado sem forçar ninguém a esperar por uma ida e volta na rede.

Considerações sobre cache em CDN

CDNs (Cloudflare, CloudFront, Fastly) respeitam os headers Cache-Control, mas adicionam sua própria camada de complexidade:

s-maxage permite definir TTLs diferentes para a CDN e para o navegador:
```
Cache-Control: public, max-age=60, s-maxage=86400
```
O navegador faz cache por 1 minuto; a CDN faz cache por 24 horas.
Purga de cache — ao fazer deploy, purgue o cache da CDN para os assets atualizados. A maioria das CDNs oferece purga via API.
Chaves de cache — CDNs fazem cache com base na URL + headers Vary. Query strings geralmente são incluídas na chave de cache.

Testando o comportamento do cache

Use nosso API Request Builder para inspecionar headers de resposta e verificar se sua configuração de cache está funcionando:

Faça uma requisição e verifique os headers Cache-Control, ETag e Last-Modified
Faça a mesma requisição novamente — verifique o header Age (segundos desde o cache) e X-Cache: HIT
Verifique CF-Cache-Status (Cloudflare) ou X-Cache (CloudFront) para confirmar o cache na CDN

No Chrome DevTools → aba Network → clique em um recurso → aba Headers — procure por from disk cache ou from memory cache na resposta.

Configuração de cache no Nginx

Configure os headers de cache no nível do Nginx para um comportamento consistente:

# Assets estáticos — cache para sempre
location ~* \.(js|css|woff2|png|jpg|webp|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# HTML — revalidar sempre
location ~* \.html$ {
    add_header Cache-Control "no-cache";
}

# API — cache curto com stale-while-revalidate
location /api/ {
    add_header Cache-Control "public, max-age=60, stale-while-revalidate=600";
}

Use nosso Nginx Config Generator para gerar uma configuração Nginx completa e otimizada para o seu caso de uso.

Checklist de cache

Assets estáticos (CSS/JS) usam nomes de arquivos com hash de conteúdo + max-age=31536000, immutable
HTML servido com no-cache ou max-age muito curto
Respostas de API em cache com base na frequência de atualização
Dados sensíveis usam no-store
ETags ou Last-Modified habilitados para requisições condicionais
stale-while-revalidate nos endpoints de API apropriados
Headers de cache da CDN verificados e testados

O cache HTTP adequado faz seu site parecer instantâneo para visitantes recorrentes, reduz seus custos com banda e diminui a carga do servidor — tudo isso sem nenhuma infraestrutura extra.