Associe a política ao recurso, não ao servidor
Faça um inventário de URLs representativas antes de alterar cabeçalhos: página inicial, página de conteúdo, application shell, CSS, JavaScript, imagens, fontes, APIs, login, conta, checkout e downloads. Para cada uma, registre se a resposta é pública ou personalizada, se seu URL muda quando os bytes mudam e quão rápido uma correção precisa alcançar visitantes.
Monte uma matriz de políticas a partir desse inventário. Um ativo público endereçado por conteúdo (content-addressed) precisa de regra diferente do HTML em um endereço estável. Respostas sem Cache-Control ainda podem ser armazenadas heurísticamente, então regras explícitas são mais fáceis de testar.
O período em que uma resposta armazenada pode ser reutilizada; max-age fornece esse valor em segundos.
Use os termos de Cache-Control com precisão
Cache-Control informa a navegadores e caches compartilhados como armazenar e reutilizar uma resposta. max-age=N permite reutilização enquanto estiver fresh. s-maxage=N define a freshnes em caches compartilhados e sobrescreve max-age lá, mas navegadores ignoram s-maxage. public permite qualquer cache; private permite cache no navegador mas impede armazenamento em cache compartilhado.
no-cache permite armazenamento mas exige validação na origem antes da reutilização. no-store significa que caches não devem armazenar a resposta, mas não é um controle de privacidade completo. Use must-revalidate quando servir conteúdo expirado for inaceitável; uma origem indisponível então pode resultar em 504 em vez de um fallback stale.
Ele remove o armazenamento em vez de apenas exigir uma verificação; reserve-o para respostas que realmente não devem ser guardadas.
Versione ativos imutáveis antes de atribuir vida útil longa
Um URL de ativo versionado inclui uma impressão digital do conteúdo ou a versão de release, por exemplo app.4f2c.js. Quando os bytes do ativo mudam, publique um URL diferente e atualize a referência no HTML. O cache vê um recurso novo, então visitantes buscam o ativo atualizado sem que uma invalidação precise alcançar cada navegador.
Para uma representação que não mudará durante sua freshness lifetime, Cache-Control: max-age=31536000, immutable é um padrão prático. immutable indica aos clientes que suportam esse atributo para não revalidar condicionalmente enquanto estiver fresh. Não aplique isso nem um max-age de um ano a um arquivo mutável com o mesmo URL. Mantenha ativos fingerprinted anteriores enquanto HTML em cache ainda puder referenciá-los.
O HTML escolhe os URLs dos ativos, portanto o sequenciamento de release deve manter a geração referenciada.
Mantenha o HTML atual por validação, não por longos caches
O HTML geralmente tem um URL estável e voltado ao usuário e muda com conteúdo, referências a ativos, feature flags ou avisos de segurança. Um padrão público conservador para HTML é Cache-Control: no-cache com ETag e Last-Modified quando sua plataforma puder produzi-los corretamente. O navegador armazena o corpo mas faz uma requisição condicional antes de reutilizar; uma resposta inalterada pode retornar 304 Not Modified sem corpo.
ETag identifica uma versão do recurso. Em uma resposta stale, o navegador pode enviá-la em If-None-Match; se corresponder, o servidor responde 304, caso contrário envia a nova representação. A orientação de RFC prefere ambos ETag e Last-Modified em uma resposta 200 quando possível. no-cache não garante validação nas navegações Back ou Forward porque o navegador pode restaurar um snapshot do histórico de sessão.
Um ETag deve mudar quando a representação muda; teste-o entre origens e implantações.
Separe entrega pública de respostas personalizadas e sensíveis
Um cache compartilhado, como um CDN, pode reutilizar uma resposta para múltiplos usuários. Não permita que ele reutilize HTML ou dados de API específicos de conta entre usuários. Para conteúdo personalizado que pode viver no navegador, private, no-cache é um ponto de partida sensato: impede armazenamento compartilhado e exige validação. Um cabeçalho Set-Cookie sozinho não impede o cache.
Para respostas que não devem ser armazenadas, use no-store e revise o código da aplicação, regras do CDN, service workers, armazenamento do navegador, logs e páginas de erro. Cabeçalhos sozinhos não são um programa de privacidade, conformidade ou segurança de pagamento. Tenha revisores qualificados de segurança, privacidade e pagamentos avaliando fluxos sensíveis e requisitos aplicáveis.
Teste login, logout, troca de conta e mudanças de permissão com caches de navegador e CDN aquecidos.
Implemente mudanças de cache como um release reversível
Capture cabeçalhos base e comportamento de corpo para requisições uncached e repetidas. Em staging, implante ativos versionados primeiro, depois o HTML que os referencia, e teste HTML antigo em cache contra a nova origem. Verifique caminhos direto-origem e CDN se ambos existirem. Os cabeçalhos no painel Network do DevTools devem mostrar a política pretendida e o comportamento em requisições repetidas.
Mantenha um manifesto de release com URLs de ativos, regras de cabeçalho e versão de configuração. Se um release combinar arquivos cliente incompatíveis, restaure o HTML compatível e o comportamento da aplicação, mas não sobrescreva um arquivo fingerprinted publicado. Aponte o HTML para a geração conhecida como boa e mantenha ambas as gerações enquanto HTML em cache puder solicitá-las. Uma limpeza (purge) em cache compartilhado não pode forçar navegadores a descartar uma resposta fresh.
Transforme falhas nos testes de cabeçalho, 404s de ativos e incompatibilidades de versão em itens a incluir no checklist do próximo release.