no-cache parece uma ordem direta: não guarde isto. Só que o HTTP escolheu um nome capaz de pregar peça até em quem trabalha com web há anos. A diretiva permite armazenar a resposta; o que ela proíbe é reutilizá-la sem antes consultar o servidor.
Essa diferença separa uma resposta rápida com 304 Not Modified de um download completo, mas também separa uma configuração segura de um vazamento de conteúdo personalizado por uma CDN. Cache não é apenas performance. É uma decisão sobre validade, compartilhamento e privacidade.
Antes das diretivas: qual cache está guardando a resposta?
O navegador mantém um cache privado ligado àquele usuário. Entre ele e a aplicação podem existir caches compartilhados: proxy corporativo, reverse proxy, CDN ou uma camada gerenciada na borda. A mesma resposta pode atravessar mais de uma dessas camadas.
Por isso, dizer apenas “pode cachear” não basta. Uma página pública pode ser compartilhada entre visitantes. Um painel autenticado não pode aparecer para outra pessoa, embora ainda possa se beneficiar do cache privado do próprio navegador.
no-cache: pode guardar, mas precisa revalidar
Com Cache-Control: no-cache, o cache pode armazenar a resposta. Antes de usá-la novamente, porém, deve perguntar ao servidor se ela continua válida. É aí que entram validadores como ETag e Last-Modified.
Se o navegador envia If-None-Match com a ETag conhecida e o conteúdo não mudou, o servidor responde 304, sem reenviar o corpo. Ainda existe uma viagem pela rede, mas não existe o custo de transferir e processar a resposta inteira.
É uma escolha comum para HTML e recursos que mudam mantendo a mesma URL. O cliente recebe a versão atual sem abrir mão da revalidação eficiente.
no-store: não armazene esta resposta
Cache-Control: no-store é a diretiva que impede caches privados e compartilhados de armazenar a resposta. Ela faz sentido quando guardar o conteúdo é inadequado, como em dados extremamente sensíveis ou respostas descartáveis.
Não é uma borracha retroativa. Enviar no-store hoje não garante a remoção de uma cópia antiga que já tenha sido armazenada para a mesma URL. Também não substitui HTTPS nem controles de autorização.
Usá-la em toda página por reflexo cobra um preço. Além de eliminar revalidação e reutilização, no-store pode reduzir os benefícios do back/forward cache do navegador. A opção mais restritiva não é automaticamente a mais correta.
private: o navegador pode, a CDN não
Cache-Control: private impede que caches compartilhados guardem a resposta, mas permite armazenamento no cache privado. Para HTML ou APIs personalizados depois do login, essa separação é decisiva.
Uma combinação prática é Cache-Control: private, no-cache: o navegador pode guardar a resposta daquele usuário, mas precisa revalidá-la; proxies e CDNs não podem compartilhá-la. Se a aplicação varia conteúdo por cookie, a chave do cache e o cabeçalho Vary também precisam fazer parte da revisão.
max-age, s-maxage e arquivos imutáveis
max-age define por quantos segundos uma resposta permanece fresca. Enquanto estiver nesse período, o cache pode reutilizá-la sem consultar a origem. s-maxage faz papel semelhante especificamente para caches compartilhados e pode substituir max-age nessas camadas.
Arquivos estáticos com hash no nome são o cenário mais seguro para cache longo. Se app.8f3a2.js nunca muda de conteúdo, ele pode receber public, max-age=31536000, immutable. Uma nova versão gera outra URL, e não uma disputa para invalidar a antiga.
Já um arquivo chamado apenas app.js, sobrescrito a cada deploy, não tem a mesma garantia. Cache longo e URL mutável formam a receita clássica para o usuário continuar executando código antigo.
Receitas iniciais, não respostas universais
- HTML público que muda:
no-cachecomETagouLast-Modified. - Asset versionado:
public, max-age=31536000, immutable. - Página ou API personalizada: começar por
private, no-cachee validar a chave de variação. - Resposta que não deve ser armazenada:
no-store, sem tratá-lo como substituto de segurança. - Conteúdo público na CDN: avaliar
s-maxagee uma estratégia explícita de purge ou versionamento.
Como diagnosticar sem adivinhar
Abra a aba Network, faça duas requisições e observe Cache-Control, Age, ETag, Last-Modified e o status da segunda resposta. Um 304 mostra revalidação; uma resposta marcada como disk cache ou memory cache indica reutilização local; um cabeçalho Age costuma denunciar passagem por cache compartilhado.
Depois repita o teste autenticado e anônimo. Confira se cookies, autorização e parâmetros realmente criam variantes separadas. O cache que acelera uma página pública não deve receber permissão para misturar usuários.
O mapa mental mais útil é simples: no-cache controla reutilização sem validação; no-store controla armazenamento; private controla compartilhamento; e max-age controla frescor. O nome engana, mas os papéis não precisam continuar confusos.
stale-while-revalidate compra latência com uma janela de desatualização
Depois de max-age, um cache pode servir a resposta antiga enquanto revalida em segundo plano durante a janela de stale-while-revalidate. Isso funciona bem para conteúdo em que alguns segundos de atraso valem uma resposta imediata. Para saldo, permissão ou inventário crítico, a mesma troca pode ser incorreta.
Cache-Control: public, max-age=60, stale-while-revalidate=300must-revalidate faz o oposto depois que a resposta fica stale: sem validação bem-sucedida, o cache não deve reutilizá-la. Escolha a diretiva a partir do risco de dado antigo, não como receita de performance.
Vary define quantas respostas diferentes existem
Se a resposta muda por Accept-Encoding, idioma ou outro header, o cache precisa dessa dimensão. Um Vary ausente pode misturar variantes; um Vary: User-Agent pode fragmentar o cache até ele quase nunca acertar. Respostas autenticadas não devem virar públicas apenas porque esqueceram private ou um bypass na CDN.
Assets com hash produzidos por uma ferramenta de build combinam com immutable. HTML de SSR exige separar conteúdo público de personalização e autenticação. O header correto depende de qual representação o cache realmente está guardando.
- teste HIT, MISS, revalidação e resposta stale;
- inspecione
Age, ETag e headers adicionados pela CDN; - troque usuário, idioma e cookie no teste de isolamento;
- invalide uma versão antiga e confirme o comportamento de fallback.