Cache do navegador explicado: Cache-Control, ETag e ajuste de CDN

Duas camadas de cache HTTP

O navegador solicita um recurso
      ↓
① Cache forte (sem ida e volta ao servidor)
   Cache-Control: max-age=31536000
      ↓ expirado
② Cache de validação (perguntar ao servidor se mudou)
   ETag / Last-Modified → 304 Not Modified
      ↓ recurso mudou
③ Buscar novo recurso do servidor → 200 OK

Diretivas de Cache-Control

Diretiva	Significado	Exemplo de uso
`max-age=N`	Usar cache por N segundos	JS/CSS (1 ano)
`s-maxage=N`	CDN armazena em cache por N segundos	HTML (1 dia)
`no-cache`	Revalidar ETag toda vez	Respostas de API
`no-store`	Sem cache nenhum	Dados sensíveis
`immutable`	Conteúdo nunca muda	Recursos com nome hash
`stale-while-revalidate=N`	Servir conteúdo obsoleto por N segundos enquanto revalida	JSON de i18n

Configuração de cache do ToolsKu

# _next/static/chunks/app-abc123.js
Cache-Control: public, max-age=31536000, immutable

# /pt-BR/pdf/merge/index.html
Cache-Control: public, max-age=3600, s-maxage=86400

# /i18n/toolClients/pt-BR.json
Cache-Control: public, max-age=86400, stale-while-revalidate=604800

Cache de validação ETag

# Primeira requisição
GET /api/config HTTP/1.1
→ 200 OK
   ETag: "abc123"
   Cache-Control: no-cache

# Requisição subsequente
GET /api/config HTTP/1.1
   If-None-Match: "abc123"
→ 304 Not Modified (corpo vazio, economiza banda)

ETags são derivadas de um hash do conteúdo. Conteúdo inalterado retorna 304 e o navegador usa sua cópia local.

Arquitetura de cache CDN

O ToolsKu está implantado no Alibaba Cloud OSS + CDN:

O usuário solicita https://www.toolsku.com/pt-BR/
      ↓
Nó de borda CDN (Pequim / Xangai / Guangzhou)
      ↓ acerto de cache → resposta direta (TTFB ~20ms)
      ↓ falha de cache
Origem OSS (Pequim)
      ↓ retorna recurso + preenche o cache CDN
CDN → usuário

Design de chave de cache

As chaves CDN geralmente são URL + string de consulta. Atenção a:

?v=123 e ?v=456 são entradas de cache diferentes
Requisições com Accept-Language podem dividir o cache (cabeçalho Vary)
O ToolsKu usa localidades baseadas em caminho (/zh-CN/, /en/) para evitar problemas com Vary

Armadilhas comuns de cache

1. JS atualizado, mas os usuários veem a versão antiga

Causa: O JS antigo está fortemente cacheado; o novo HTML referencia novos nomes de arquivo, mas o JS antigo permanece em cache.

Solução: Nomes de arquivo com hash de conteúdo (padrão do Next.js _next/static/chunks/app-[hash].js). Mudança de conteúdo → mudança de hash → invalidação natural.

2. Cache de HTML oculta conteúdo atualizado

Solução: max-age mais curto + s-maxage no HTML, ou purgar ativamente via API de atualização da CDN.

3. Cache do Service Worker vs cache HTTP

O handler fetch do Service Worker pode interceptar todas as requisições — prioridade sobre o cache HTTP. Incremente a versão do cache nas atualizações do SW e delete caches antigos.

Ferramentas de depuração de cache

Chrome DevTools → Network: Coluna Size ((disk cache) / (memory cache) / tamanho real)
Cabeçalhos de resposta: Verificar Cache-Control, ETag, Age
ToolsKu Referência de códigos de status HTTP: Entender 200, 304, 404, etc.

Resumo

Um bom cache é fundamental para o desempenho web. Cache forte + cache de validação + nós de borda CDN dão ao ToolsKu um TTFB de aproximadamente ~50ms na primeira pintura. Entender Cache-Control e ETag é um trabalho fundamental de desempenho frontend.