O que é cache e por que limpar o cache resolve tantos problemas
“Já reiniciei o computador, já troquei de navegador, o site continua quebrado.” Quem trabalha com web ouve isso toda semana, e muitas vezes a pessoa nem precisava ter reiniciado nada. Bastava limpar o cache. O engano típico de quem está começando é tratar o cache como um lixo que se acumula, quando ele é uma cópia guardada de propósito para economizar tempo, e que às vezes fica velha.
$ ls ./neste-artigo
- A cópia que fica no meio do caminho
- Quem decide por quanto tempo a cópia vale
- O site “quebra” e a limpeza conserta: entenda o motivo
- Como os profissionais evitam depender do Ctrl+Shift+R
- A pergunta “isso mudou?” custa quase nada
- Quando o cache vira problema de segurança
- O próximo passo para quem está começando
O custo desse engano aparece dos dois lados. O usuário perde meia hora tentando consertar o que não está quebrado, e o dev publica uma correção, testa no próprio navegador, não vê mudança nenhuma e passa a tarde caçando um bug que já tinha resolvido.
A cópia que fica no meio do caminho
Toda vez que você abre uma página, o navegador precisa de dezenas de arquivos: HTML, CSS, JavaScript, imagens, fontes. Buscar tudo de novo a cada clique seria lento e gastaria dados à toa. Então ele guarda uma cópia local e, na próxima visita, usa essa cópia enquanto ela for considerada válida.
A mesma ideia se repete em várias camadas entre você e o servidor. Pense numa requisição para buildbase.dev.br/style.css passando por elas:
- Cache do navegador: se o arquivo está guardado e ainda “fresco”, nem sai requisição pela rede.
- CDN: se o navegador precisa buscar, a requisição cai num servidor da CDN (Cloudflare, CloudFront, Fastly) próximo de você, que pode ter uma cópia.
- Cache do servidor ou da aplicação: se a CDN não tem, o pedido chega à origem, que pode servir uma página já montada (plugins de cache no WordPress, Varnish) em vez de gerar tudo de novo.
- Cache de dados: mesmo gerando a página, a aplicação pode pegar o resultado de uma consulta pesada no Redis ou Memcached em vez de ir ao banco.
Cada camada economiza tempo. E cada uma pode, sozinha, estar servindo uma versão velha.
Quem decide por quanto tempo a cópia vale
O navegador não adivinha. Quem manda é o servidor, por meio de cabeçalhos HTTP enviados junto com cada arquivo. O principal é o Cache-Control, padronizado na RFC 9111, a especificação de cache do HTTP. Alguns valores que você vai encontrar:
| Cabeçalho | O que significa na prática |
|---|---|
| Cache-Control: max-age=3600 | Pode usar a cópia por 1 hora sem perguntar nada ao servidor |
| Cache-Control: no-cache | Pode guardar, mas precisa confirmar com o servidor antes de usar (o nome engana) |
| Cache-Control: no-store | Não guarde nada; use em dados sensíveis, como extrato bancário |
| Cache-Control: private | Só o navegador do usuário pode guardar, CDN e proxies não |
| Cache-Control: public, max-age=31536000, immutable | Guarde por um ano e nem pense em revalidar; típico de arquivos com versão no nome |
A confusão entre no-cache e no-store é clássica. Quem quer “proibir o cache” e escreve no-cache continua tendo cópias guardadas, só que revalidadas. A página de referência da MDN sobre o cabeçalho Cache-Control lista todas as diretivas com exemplos.
O site “quebra” e a limpeza conserta: entenda o motivo
O problema clássico acontece numa atualização. O site publica um HTML novo que espera um app.js novo, mas o navegador ainda tem o app.js antigo guardado com max-age de uma semana. Resultado: botões que não respondem, layout torto, erro no console. Para o usuário, o site está quebrado. Para o servidor, está tudo certo.
Limpar o cache resolve porque elimina a cópia antiga e força o download da versão atual. Outros casos comuns:
- Login em loop ou sessão estranha: cookies e dados de site guardados em conflito com a versão nova do sistema.
- Imagem antiga que não sai: você trocou o logo mantendo o mesmo nome de arquivo, e a CDN continua entregando o anterior.
- Página de erro “presa”: a CDN guardou um erro 500 de um minuto de instabilidade e passou a servi-lo a todo mundo.
- DNS desatualizado: você migrou o site de servidor, e o sistema operacional ainda guarda o IP antigo.
Para testar rápido, use Ctrl+Shift+R (ou Cmd+Shift+R no Mac), que recarrega ignorando o cache, ou abra uma janela anônima. Se lá funciona, o problema é cópia velha.
Como os profissionais evitam depender do Ctrl+Shift+R
Pedir para o cliente limpar o cache não é estratégia. A técnica que resolve de verdade se chama cache busting: cada versão de um arquivo ganha um nome diferente, geralmente com um hash do conteúdo.
<script src="/assets/app.3f9a1c.js"></script>Ferramentas como Vite, Webpack e o Next.js fazem isso automaticamente no build. Como o nome muda a cada alteração, o arquivo pode ter cache de um ano com immutable: quando o código mudar, o HTML vai apontar para um nome novo que o navegador nunca viu. O HTML em si recebe cache curto ou no-cache, para estar sempre atualizado.
Na CDN, o equivalente é a purga: depois de um deploy, você manda apagar as cópias de determinadas URLs. A maioria dos painéis tem um botão “Purge cache”, e dá para automatizar isso no pipeline de deploy.
A pergunta “isso mudou?” custa quase nada
Quando a cópia passa da validade, o navegador não precisa baixar o arquivo inteiro de novo. Ele pergunta ao servidor se algo mudou, usando uma etiqueta que recebeu da primeira vez:
GET /style.css
If-None-Match: "a1b2c3"
HTTP/1.1 304 Not ModifiedO ETag funciona como uma impressão digital do arquivo. Se continua igual, o servidor responde 304 Not Modified, sem corpo, e o navegador reaproveita o que tinha. Se mudou, vem um 200 com o arquivo novo. Abra a aba Network das ferramentas de desenvolvedor (F12), recarregue uma página e procure as linhas com 304 ou com “(disk cache)” e “(memory cache)” na coluna Size: são as camadas de cache trabalhando na sua frente.
Cache, numa frase: cache é uma cópia temporária de um dado guardada mais perto de quem vai usá-lo, para não buscá-lo de novo na origem. Limpar o cache resolve tantos problemas porque obriga o navegador (ou o servidor) a jogar fora a cópia antiga e buscar a versão atual.
Quando o cache vira problema de segurança
Cache mal configurado pode vazar dados. Se uma página de “minha conta” sai com Cache-Control: public, uma CDN pode guardar a versão de um usuário e entregar para o próximo. Já houve casos reais de lojas mostrando o carrinho ou o nome de outro cliente por causa disso.
A regra prática: tudo que depende de login ou contém dado pessoal leva private ou no-store. O guia da MDN sobre cache HTTP explica esses cenários com detalhes, e se você está montando seu vocabulário técnico, o glossário de programação do Buildbase reúne os outros termos que aparecem aqui, como CDN, DNS e HTTP.
Vale olhar também a configuração de quem fica na frente da sua origem. Ao colocar uma API atrás de um proxy reverso, como no caso das origens privadas da Cloudflare, revise as regras de cache por rota antes de liberar o tráfego, porque respostas de API raramente devem ser guardadas por padrão.
O próximo passo para quem está começando
Abra um site que você usa todo dia, aperte F12, vá à aba Network e recarregue. Clique em três ou quatro arquivos e leia o Cache-Control de cada um. Depois marque “Disable cache” e recarregue de novo, comparando o tempo total. Em dez minutos você entende mais sobre cache do que lendo qualquer definição, e passa a saber exatamente quando “limpar o cache” é a solução e quando é só superstição.
