Cache não é apenas um botão para deixar um site mais rápido. Ele é uma decisão sobre onde uma resposta pode ser reutilizada, por quanto tempo e com quais garantias. Quando essa decisão é bem feita, arquivos chegam ao visitante a partir de um ponto próximo e o servidor de origem recebe menos trabalho. Quando é feita sem critério, uma pessoa pode receber dados de outra, uma atualização pode demorar a aparecer ou uma sessão pode ser exposta.
A diferença central é simples: conteúdo estático tende a ser igual para muitas pessoas, enquanto conteúdo dinâmico depende de contexto. Imagens, folhas de estilo, fontes, JavaScript versionado e documentos que mudam raramente são bons candidatos ao cache. Já um painel com saldo, um carrinho de compras ou uma página moldada por login precisa de regras mais cuidadosas. A fronteira, porém, não é absoluta. Uma resposta dinâmica pode ser armazenada quando a aplicação consegue definir sua variação e sua validade.
O que muda entre conteúdo estático e dinâmico
Conteúdo estático é um arquivo que pode ser entregue repetidamente sem ser recalculado para cada visita. Um navegador pode guardar uma cópia local, e uma CDN pode manter outra em seus pontos de presença. Na próxima solicitação, o usuário recebe o recurso do cache em vez de esperar uma viagem até a origem. Isso reduz latência, consumo de banda e quantidade de requisições no servidor principal.
Conteúdo dinâmico é montado a partir de fatores como identidade, localização, horário, dispositivo, parâmetros da requisição ou dados recém-alterados. Uma página inicial personalizada, uma busca e uma API autenticada se enquadram nessa categoria. O fato de ser dinâmico não significa que nunca possa ser cacheado. Significa que o cache precisa respeitar as chaves de variação, os cabeçalhos e o risco de entregar uma representação antiga.
Como o cache estático funciona no navegador e na CDN
No cache do navegador, os cabeçalhos HTTP orientam por quanto tempo um recurso pode ser considerado fresco. Diretivas como max-age, public e immutable ajudam a expressar essa política. Um nome de arquivo com versão, como app.8f31.js, permite usar uma validade longa: quando o conteúdo muda, o endereço também muda. Assim, a aplicação não depende de apagar manualmente cópias espalhadas.
A CDN amplia esse modelo. Na primeira solicitação, o ponto de presença pode buscar o arquivo na origem e armazená-lo. Solicitações seguintes são atendidas no ponto mais próximo, desde que a resposta ainda esteja válida. A arquitetura não elimina a origem: ela cria uma camada intermediária que absorve acessos repetidos. Por isso, a configuração de DNS, TLS, compressão, limites e invalidação continua sendo parte do desenho.
Um erro comum é invalidar tudo a cada publicação. Essa escolha garante frescor, mas destrói a vantagem do cache e pode gerar picos de tráfego. Outra abordagem é usar TTL curto para recursos que mudam com frequência e nomes versionados para recursos imutáveis. O equilíbrio depende da tolerância a conteúdo antigo, da frequência de deploy e do custo de recomputar a resposta.
Como o edge pode acelerar conteúdo dinâmico
O conteúdo dinâmico também pode ser processado mais perto do visitante. Funções executadas no edge conseguem ler a requisição, aplicar regras, consultar dados permitidos e produzir uma resposta sem mandar tudo para um servidor distante. Essa estratégia é útil para redirecionamentos, personalização limitada, testes controlados e composição de páginas. Ela não transforma automaticamente qualquer resposta em conteúdo público.
Para cachear uma resposta dinâmica com segurança, defina quais entradas realmente alteram o resultado. O idioma, o país ou um parâmetro explícito podem fazer parte da chave; cookies de sessão e tokens privados normalmente exigem bypass. Também é importante separar dados públicos de dados pessoais. Uma resposta com informação de conta não deve compartilhar o mesmo objeto de cache de uma página anônima.
Como escolher a estratégia sem criar armadilhas
Comece classificando cada rota, não o site inteiro. Para cada endpoint ou recurso, registre se ele é público, quais entradas alteram a resposta, qual atraso é aceitável e como uma atualização será propagada. Depois, escolha a camada: navegador para reduzir viagens repetidas do mesmo usuário, CDN para distribuir conteúdo público, ou edge para aplicar lógica simples perto do usuário. A origem continua responsável por dados e regras que não podem ser compartilhados.
Observe os cabeçalhos reais e os resultados em produção. Idade do objeto, acertos, erros, latência por região e taxa de revalidação revelam se o cache está ajudando. Teste também publicação, logout, troca de permissões, falha da origem e expiração. Um teste que mede somente a primeira visita não mostra o comportamento da camada armazenada.
O guia da Cloudflare explica a diferença entre conteúdo estático e dinâmico, o funcionamento do cache e o papel de tecnologias de edge. Consulte a fonte original para comparar os conceitos e os exemplos: https://www.cloudflare.com/learning/cdn/caching-static-and-dynamic-content
Antes de ativar uma regra nova, escreva exemplos de requisições que devem compartilhar resposta e exemplos que jamais podem compartilhar. Essa pequena matriz torna visíveis diferenças de usuário, idioma e permissão que costumam ficar escondidas em testes felizes. Ela também facilita revisar a configuração durante uma troca de CDN ou mudança de framework.
Na prática, a melhor política costuma ser conservadora com dados personalizados e agressiva com arquivos versionados. Não há mérito em obter um hit alto se a resposta está errada. O objetivo é entregar o conteúdo correto com menos distância, menos processamento repetido e uma regra de invalidação que a equipe consiga testar e operar.
