Cache HTTP para sites: velocidade sem servir conteúdo desatualizado

Resposta direta: uma política de cache eficiente combina a duração adequada com a natureza do conteúdo. Arquivos estáticos com nome versionado — como CSS, JavaScript e imagens de build — podem receber cache longo, porque uma nova versão terá outra URL. HTML dinâmico e dados personalizados exigem validação frequente ou uma política privada. Use cabeçalhos como Cache-Control, ETag e Last-Modified conforme a arquitetura, e teste tanto navegador quanto CDN. “Cache mais longo” não é sinônimo de “site mais rápido” se os usuários ficarem presos a uma versão antiga ou receberem dados de outra pessoa.

Cache reutiliza uma resposta armazenada em um navegador ou cache compartilhado para evitar novo processamento e transferência desnecessários. Isso pode reduzir latência e carga da origem. O comportamento, porém, depende de diretivas HTTP, da camada de CDN e de regras do produto. Um cabeçalho que se aplica ao navegador pode não ser igual a uma configuração de cache de borda, então revise toda a cadeia.

Separe conteúdo público de informação personalizada

Comece classificando recursos. Imagens, fontes, CSS e JavaScript com URL única por versão são candidatos comuns a cache longo. Uma página pública que muda ao longo do dia pode ser armazenada por período menor ou exigir revalidação. Conta autenticada, carrinho, dados pessoais e respostas baseadas em cookies precisam ser tratadas com muito mais cautela para impedir que um cache compartilhado entregue informação de uma sessão a outra.

Cache-Control oferece diretivas para navegadores e caches compartilhados. “public” permite armazenamento em cache compartilhado quando apropriado; “private” limita a resposta ao cache privado do usuário; “no-store” evita armazenamento da resposta; “no-cache” permite armazenar mas exige validação antes de reutilizar. Os nomes parecem intuitivos, mas no-cache não significa que nada será armazenado. Leia o padrão e considere o produto de cache em uso.

Uma matriz simples para começar

Para um asset de build que muda de nome a cada versão, uma política de longa duração pode ser segura, pois a URL antiga representa o conteúdo antigo e o HTML novo aponta para outra URL. Para HTML público, configure uma janela curta ou revalidação que respeite as exigências de atualização. Para uma resposta personalizada e sensível, evite cache compartilhado e verifique cabeçalhos de autorização e cookies. A matriz é um ponto inicial, não substitui análise da aplicação.

O cache pode usar ETag ou Last-Modified para uma validação condicional. Se o recurso não mudou, o servidor pode responder que a cópia continua válida sem transferir todo o corpo novamente. Essa estratégia pode reduzir bytes, mas ainda envolve uma requisição de rede. Para páginas que mudam com frequência, a revalidação pode ser melhor que servir cópia potencialmente desatualizada por muito tempo.

Versionamento de assets evita o problema da cópia antiga

Quando a URL contém uma impressão digital de conteúdo ou versão — como um hash no nome — cada build gera um endereço novo para conteúdo novo. Isso permite que o cliente guarde a versão antiga e que o HTML atualizado passe a referenciar a nova. O cache longo funciona porque não é necessário substituir o conteúdo sob a mesma URL. Sem versionamento, um usuário pode manter um arquivo antigo por dias, causando incompatibilidade entre JavaScript e HTML.

Antes de aplicar, confirme como o framework nomeia arquivos de build, como o CDN interpreta query strings e se o HTML é revalidado depois do deploy. Se a plataforma usa URL estável para arquivos mutáveis, configure expiração menor e purge controlado ao publicar. Purge global pode ser útil em incidente, mas depender de limpeza manual para cada deploy é frágil e reduz o benefício do cache.

Exemplo: campanha com landing page atualizada

Uma empresa altera um formulário, publica o novo HTML e troca um script. Se o HTML novo aponta para um arquivo com hash novo, navegador e CDN podem manter o asset anterior sem quebrar a página recém-publicada. Se a página muda mas a URL do JavaScript permanece igual e o cache tem duração longa, o visitante pode carregar código antigo junto com marcação nova. A correção é alinhar build, nomes, invalidação e headers, não reduzir o cache indiscriminadamente de todos os recursos.

Faça deploy em uma cópia de teste e inspecione resposta final e cabeçalhos. Limpe somente o cache necessário para validar a nova versão, confirme a URL do asset e repita em janela anônima e dispositivo móvel. Evite assumir que um reload forçado representa a experiência normal: pode ignorar cache e mascarar falhas vistas por visitantes recorrentes.

Como evitar vazamento e dados desatualizados

Uma CDN pode servir a mesma resposta para muitos usuários. Se a resposta depende de cookie, autorização, idioma ou query string, avalie se essas dimensões alteram o conteúdo e se o cache está configurado para variar adequadamente. Uma diretiva Vary pode participar da chave de cache, mas ampliar demais as variantes reduz a reutilização e pode criar comportamento difícil de depurar. Defina explicitamente quais parâmetros importam.

Não confie apenas em “no-store” como forma de apagar uma cópia antiga já armazenada. A documentação do MDN explica que no-store impede armazenamento novo, mas não apaga necessariamente uma resposta previamente guardada. Se o conteúdo sensível foi servido antes com cabeçalhos permissivos, invalide a cópia na camada pertinente e corrija a origem. Revise headers de resposta em páginas de login, pagamentos, formulários com dados e áreas privadas.

Faça testes com dois usuários distintos, duas sessões e navegação autenticada/desconectada. Compare status, Age, ETag, Cache-Control e conteúdo. Observe se um usuário recebe página do outro, se a resposta usa a versão atual e se uma API entrega informação personalizada via cache compartilhado. Em conteúdo sensível, uma falha de isolamento é mais séria do que perder parte da economia de transferência.

Medir impacto sem supor melhoria

Registre o estado antes da mudança: bytes transferidos, taxa de acerto do cache, quantidade de requisições ao servidor, LCP e experiência móvel. Depois aplique a política em um conjunto restrito ou em ambiente de teste. Avalie em visitas recorrentes e frias, pois cache afeta cada uma de modo diferente. A primeira visita ainda precisa buscar recursos; a reutilização aparece em retornos ou entre pessoas para uma CDN pública.

Cheque cache hit e miss na CDN, tempo de resposta, revalidações e erros. Uma taxa de acerto alta é boa somente se a resposta correta está sendo entregue. Acompanhe incidentes após deploy: erros de versão antiga, formulários quebrados, personalização inconsistente e dados atualizados com atraso. Se o conteúdo é notícia, preço ou disponibilidade de agenda, o tempo aceitável pode ser bem diferente de um logo ou biblioteca de estilos.

Quando a página não ganha velocidade, examine outras causas: servidor lento, imagem grande, renderização bloqueada, JavaScript de terceiros ou conexão inicial. Cache não reduz todo tipo de espera. Em uma landing page de tráfego pago, a consistência entre anúncio e destino e o envio correto do formulário continuam tão importantes quanto velocidade.

Checklist de cache

• Inventariar HTML, assets versionados, APIs públicas e respostas personalizadas.
• Definir política por classe de recurso, distinguindo browser cache e CDN.
• Usar URLs versionadas para arquivos estáticos que recebem cache longo.
• Configurar ETag ou Last-Modified quando a revalidação for adequada.
• Inspecionar Cache-Control, Vary, Age e status em origem e borda.
• Testar usuários, cookies e dados privados para excluir resposta cruzada.
• Observar versão após deploy, cache hit, LCP e erros antes de ampliar.

A Open Leads desenvolve experiências digitais e páginas de conversão. Veja os serviços e outros conteúdos técnicos no blog. A política de cache correta é parte da qualidade do site, mas deve ser projetada com o ciclo de atualização e a privacidade em mente.

Para sites institucionais, uma política conservadora costuma combinar cache de longa duração para arquivos estáticos versionados com revalidação para HTML que muda com frequência. Isso não é uma prescrição universal: páginas personalizadas, autenticadas ou com conteúdo sensível exigem cabeçalhos apropriados e podem não ser compartilháveis em cache. Revise cookies, cabeçalhos de autorização e regras do CDN antes de tornar uma resposta pública. Uma configuração incorreta pode exibir informação de outro usuário.

Durante deploys, invalidação ampla é simples, mas pode causar um pico de solicitações à origem e eliminar o benefício do cache. Versionar nomes de arquivos permite publicar novos assets sem esperar que cópias antigas expirem. Para templates dinâmicos, use uma janela de revalidação compatível com a frequência de atualização e monitore cabeçalhos de resposta, idade do objeto e taxa de acerto. Teste uma rota por tipo de conteúdo em vez de assumir que uma única regra vale para o domínio inteiro.

Perguntas frequentes

Cache-Control no-cache proíbe o armazenamento?

Não. Em geral, permite armazenamento, mas exige validação antes de reutilizar. Para evitar armazenamento, no-store expressa uma intenção diferente, embora não apague cópias antigas.

Posso usar max-age longo em todas as páginas?

Não sem avaliar atualização, personalização e segurança. Assets com URL versionada podem aceitar duração longa; HTML dinâmico e dados pessoais normalmente pedem outra política.

Como evitar que visitantes vejam arquivos antigos?

Use URLs versionadas para assets mutáveis e faça o HTML novo apontar para a versão correspondente. Verifique também configurações de CDN e invalidação durante deploy.

ETag substitui o cache?

Não. ETag permite validar se uma representação mudou. A política de cache continua determinando quando e como o cliente deve revalidar.

Como descubro se a CDN está servindo a versão correta?

Inspecione headers de origem e borda, repita testes em sessão nova e recorrente e verifique conteúdo, idade e hash do arquivo. Não avalie somente pelo cache hit.

Quer transformar tráfego em oportunidades reais? A Open Leads integra mídia paga, mensuração e criação de sites focados em conversão. Conheça os serviços da Open Leads.

Fontes consultadas

Consulte os materiais originais usados na pesquisa deste artigo.

• HTTP caching — MDN Web Docs
• RFC 9111: HTTP Caching — RFC Editor / IETF
• Cache-Control header — Cloudflare Developers