Fundamentos de Cache que Todo Desenvolvedor Web Deveria Conhecer

Feb 24, 2026 · 4 min read

Fundamentos de Cache que Todo Desenvolvedor Web Deveria Conhecer

Seus usuários acabaram de clicar em um botão e nada aconteceu por três segundos. A consulta ao banco de dados terminou, o servidor respondeu, mas os mesmos dados que carregaram ontem tiveram que viajar por toda a internet novamente. Este é o problema que o cache resolve.

Entender os fundamentos de cache HTTP não é opcional para desenvolvedores frontend. É a diferença entre uma aplicação ágil e uma que parece quebrada. Este guia cobre o que você precisa saber sobre cache do navegador vs. cache CDN, cabeçalhos Cache-Control e mecanismos de validação como ETag e Last-Modified.

Principais Conclusões

Defina cabeçalhos Cache-Control explícitos em cada resposta para evitar heurísticas imprevisíveis do navegador.
Use valores longos de max-age combinados com cache busting (nomes de arquivo com hash de conteúdo) para recursos estáticos.
Use no-cache com ETag ou Last-Modified para conteúdo que precisa permanecer atualizado.
Sempre marque conteúdo personalizado ou autenticado como private para evitar vazamento de dados através de caches compartilhados.

O Que É Cache e Por Que É Importante

Cache armazena uma cópia de dados mais próxima de onde é necessária. Quando seu navegador solicita uma imagem, ele pode salvar essa imagem localmente. A próxima requisição pula a rede completamente.

Os ganhos de desempenho são dramáticos. Por exemplo, uma consulta ao banco de dados pode levar dezenas de milissegundos, enquanto a leitura de um cache do navegador é tipicamente quase instantânea e evita uma ida e volta pela rede completamente.

O cache oferece três benefícios principais:

Latência reduzida: Os dados viajam distâncias menores.
Menor carga no servidor: Menos requisições chegam à sua origem.
Melhor experiência do usuário: As páginas carregam mais rápido em visitas repetidas.

Entendendo as Camadas de Cache

As requisições passam por múltiplos caches antes de alcançar seu servidor. Cada camada serve a um propósito diferente.

Cache do Navegador (Cache Privado)

O cache do navegador fica no dispositivo do usuário. Ele armazena respostas que apenas aquele usuário deveria ver. Quando você marca uma resposta como private, ela permanece aqui e nunca é compartilhada com outros usuários.

É aqui que o conteúdo personalizado pertence — perfis de usuário, respostas de API autenticadas, qualquer coisa vinculada a uma sessão específica.

Cache CDN (Cache Compartilhado)

Um cache CDN fica entre os usuários e seu servidor de origem, distribuído por localizações geográficas. Quando um usuário em Tóquio solicita seu pacote JavaScript, a CDN o serve de um servidor edge próximo em vez do seu data center de origem.

CDNs se destacam no cache de recursos estáticos: imagens, CSS, JavaScript e fontes. Eles também podem fazer cache de respostas de API públicas, embora isso exija configuração cuidadosa.

Cache no Lado do Servidor

Além do cache HTTP, servidores frequentemente mantêm seus próprios caches usando ferramentas como Redis ou Memcached. Como desenvolvedor frontend, você não configurará estes diretamente, mas entender que eles existem ajuda você a raciocinar sobre por que algumas respostas de API são mais rápidas que outras.

Cabeçalhos Cache-Control: As Diretivas Principais

O cabeçalho Cache-Control informa aos caches como lidar com respostas. Estas são as diretivas que você usará com mais frequência:

Diretiva	Significado
`max-age=3600`	Fazer cache por 3600 segundos (1 hora)
`no-cache`	Armazene, mas revalide antes de usar
`no-store`	Não armazene esta resposta em lugar algum
`private`	Apenas o cache do navegador pode armazenar isto
`public`	Qualquer cache pode armazenar isto

Um erro comum: no-cache não significa “não fazer cache”. Significa “sempre verificar com o servidor antes de usar a cópia em cache”. Use no-store quando você realmente não quiser cache algum.

Para recursos estáticos com nomes de arquivo com hash, use cache agressivo:

Cache-Control: public, max-age=31536000

Para páginas HTML que mudam frequentemente (e especialmente para conteúdo sensível ou altamente dinâmico):

Cache-Control: no-cache, private

ETag e Last-Modified: Mecanismos de Validação

Quando o conteúdo em cache expira, os navegadores nem sempre precisam baixar tudo novamente. Cabeçalhos de validação permitem revalidação eficiente.

Last-Modified contém um timestamp. Em requisições subsequentes, o navegador envia um cabeçalho If-Modified-Since com aquele timestamp. Se nada mudou, o servidor retorna 304 Not Modified — sem corpo, largura de banda mínima.

ETag contém um identificador único (frequentemente um hash de conteúdo). Em requisições subsequentes, o navegador envia um cabeçalho If-None-Match com aquele identificador. Mesmo resultado: um 304 se o conteúdo não mudou.

ETags são mais precisos que timestamps porque detectam mudanças reais de conteúdo, não apenas horários de modificação de arquivo. Um arquivo poderia ser salvo novamente sem mudar seu conteúdo, atualizando seu timestamp mas não seu ETag.

Cache Busting para Recursos Estáticos

Você quer recursos estáticos em cache pelo maior tempo possível, mas também precisa que os usuários obtenham atualizações quando você faz deploy. Cache busting resolve isso mudando a URL quando o conteúdo muda.

Ferramentas de build modernas adicionam hashes de conteúdo aos nomes de arquivo:

bundle.a1b2c3d4.js
styles.e5f6g7h8.css

Quando você faz deploy de código novo, o hash muda, a URL muda, e os navegadores buscam a nova versão. Os arquivos antigos em cache simplesmente expiram naturalmente.

Armadilhas Comuns a Evitar

Fazer cache de conteúdo autenticado publicamente: Sempre use private para dados específicos do usuário. Vazar dados de um usuário para outro através de um cache compartilhado é um problema sério de segurança.

Cache excessivo de respostas de API: Dados dinâmicos precisam de TTLs curtos ou no-cache. Preços desatualizados durante o checkout causam problemas reais.

Esquecer de definir cabeçalhos: Sem cabeçalhos Cache-Control explícitos, navegadores podem aplicar cache heurístico baseado em metadados de resposta, o que pode levar a comportamento que você não pretendia.

Conclusão

Cache não é algo que você configura uma vez e esquece. Defina cabeçalhos Cache-Control explícitos em cada resposta. Combine valores longos de max-age com nomes de arquivo com hash de conteúdo para recursos estáticos. Use no-cache junto com ETag ou Last-Modified para conteúdo que precisa permanecer atualizado, e sempre marque conteúdo personalizado como private. Verifique seus cabeçalhos no DevTools, confirme o comportamento da sua CDN e teste o que os usuários realmente experimentam.

Perguntas Frequentes

no-cache informa ao navegador que ele pode armazenar a resposta, mas deve revalidar com o servidor antes de usá-la. no-store informa ao navegador para não salvar a resposta de forma alguma. Use no-store para dados sensíveis como detalhes bancários, e no-cache para conteúdo que muda frequentemente mas se beneficia de revalidação condicional.

Abra o DevTools do seu navegador, vá para a aba Network (Rede), e selecione qualquer requisição. A seção Response Headers (Cabeçalhos de Resposta) mostra os valores de Cache-Control, ETag e Last-Modified. Observe também a coluna de tamanho. Se disser disk cache ou memory cache, a resposta foi servida do cache do navegador em vez da rede.

Depende dos dados. Dados públicos que raramente mudam, como categorias de produtos, podem usar valores curtos de max-age. Dados específicos do usuário ou que mudam frequentemente devem usar no-cache com cabeçalhos de validação ou no-store. Sempre marque respostas autenticadas como private para evitar que CDNs sirvam dados de um usuário para outro.

Hashes de conteúdo permitem que você defina tempos de vida de cache muito longos para recursos estáticos enquanto ainda entrega atualizações instantaneamente. Quando o conteúdo do arquivo muda, o hash muda, produzindo uma nova URL que ignora qualquer cache existente. Esta técnica é chamada de cache busting e é a abordagem padrão usada por ferramentas como Webpack, Vite e Rollup.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.