Imagine que uma biblioteca altere o horário de funcionamento de hoje em seu site, mas alguns visitantes continuem vendo o horário antigo. Primeiro, separe as possibilidades: o original no servidor não foi atualizado, o navegador reutilizou uma resposta armazenada ou um servidor intermediário entregou uma versão anterior? Atualizar a tela várias vezes, por si só, não revela em qual etapa está a causa.
O cache HTTP armazena respostas recebidas e as reutiliza quando as condições permitem. Este artigo relaciona as instruções de armazenamento e revalidação do Cache-Control com ETag e respostas 304, usando um horário público fictício. As trocas abaixo são exemplos abreviados para explicar os princípios, não medições de uma biblioteca real ou de um servidor específico. O objetivo é explicar quais respostas devem poder ser reutilizadas e quando, em vez de recomendar a eliminação de todo cache.
1. Separar armazenamento, verificação e compartilhamento
Ao ler uma política de cache, anote três perguntas separadas: a resposta pode ser armazenada, a cópia pode ser usada imediatamente na próxima requisição e pode ser compartilhada entre usuários? Permitir armazenamento não significa permitir qualquer reutilização; verificar a atualização também não autoriza compartilhamento. O padrão de cache HTTP RFC 9111 define essas condições por diretivas distintas. A explicação abaixo considera diretivas de resposta sem um argumento adicional com nomes de campos.
| Pergunta a decidir | Diretiva de resposta relacionada | Significado a distinguir |
|---|---|---|
| É proibido armazenar a resposta? | no-store | Proíbe o armazenamento para reutilização posterior |
| É preciso verificar antes de reutilizar? | no-cache | Permite armazenar, mas exige validação bem-sucedida antes da reutilização |
| Vários usuários podem compartilhá-la? | private | Exclui o armazenamento em caches compartilhados sem proibir também o cache privado |
Para um horário público alterado com frequência no mesmo endereço, por exemplo, pode-se avaliar a exigência de verificar a cópia antes de usá-la. Uma tela personalizada já difere desse horário nas condições de compartilhamento. private diz respeito a caches compartilhados; não substitui login nem verificações de autorização. Reunir configurações com finalidades diferentes em uma frase pode levar a definir incorretamente o público da informação ao tentar melhorar a velocidade.
Na tabela de políticas, registre o motivo de cada diretiva, não apenas seu nome. Anote se o horário é informação pública cujas mudanças precisam ser verificadas, se o logotipo é um arquivo de conteúdo fixo ou se o mesmo endereço contém informações individuais. Essa tabela é um ponto de partida para classificar respostas reais, não uma configuração pronta para todos os sites. Também diferencie a qual armazenamento ela se aplica, como o navegador ou uma CDN.
2. Não escolher no-cache e no-store apenas pelo nome
É fácil interpretar no-cache como proibição de armazenamento. Em uma resposta, porém, significa validar a cópia antes de reutilizá-la. Se o servidor confirmar que não houve alteração, o corpo armazenado poderá ser usado novamente. Já no-store determina que essa resposta não seja armazenada. O que pode ser guardado e o que precisa ser verificado na próxima requisição são coisas diferentes; não espere o mesmo comportamento das duas opções.
No contexto de cache, fresh significa que a política permite reutilizar sem validação adicional. Não garante que o responsável não tenha alterado o original nesse intervalo. Se max-age define um período de reutilização, uma resposta já armazenada pode continuar sendo escolhida mesmo após uma alteração no original durante esse prazo. Defina primeiro o atraso de atualização aceitável e relacione essa necessidade às diretivas. Não copie um prazo longo arbitrário como solução universal de desempenho.
O guia de cache HTTP da MDN explica que acrescentar no-store a uma nova resposta não apaga respostas antigas já armazenadas para a mesma URL. Se a cópia anterior ainda for utilizável e uma nova resposta não for solicitada, o novo cabeçalho também poderá não chegar. Não trate no-store como limpeza completa do cache nem como condição suficiente de privacidade. Verifique a vida útil das respostas existentes e os procedimentos de atualização dos caches sob seu controle.
3. Acompanhar uma nova visita com ETag e 304
Suponha que o endereço fictício /hours.json informe inicialmente fechamento às 18:00. O exemplo explicativo abaixo usa o formato HTTP/1.1 e mantém apenas as partes necessárias; outros cabeçalhos exigidos em uma resposta real foram omitidos. hours-v1 é um identificador de representação escolhido pelo servidor para esse exemplo, não uma fórmula de horário nem o hash real de um arquivo.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"
{"closes":"18:00"}Se o navegador armazenou essa resposta, poderá enviar depois o valor ETag em If-None-Match numa requisição condicional. Se a condição corresponder à representação atual selecionada pelo servidor e ela for considerada inalterada, a resposta será 304 Not Modified. O próximo bloco é um registro abreviado que apresenta uma requisição e sua resposta em sequência. Não é um exemplo de envio de um novo JSON de horários depois do 304.
GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"Como descreve a explicação da MDN sobre ETag, o cliente usa o corpo armazenado nesse caso. O 304 não possui um novo corpo, mas a requisição e a validação ainda envolvem comunicação. Se o responsável mudar o fechamento para 19:00 e a representação do servidor também mudar, espera-se uma resposta 200 com novo corpo e novo identificador para a condição antiga. Usar no-cache não significa receber sempre 304 nem eliminar consultas ao banco de dados.
Verifique a correspondência entre conteúdo e identificador, em vez de observar apenas o código de status. Se o conteúdo mudar e o servidor mantiver a ETag antiga, a validação poderá produzir um resultado incorreto. Por outro lado, identificadores que mudam constantemente para conteúdo igual podem aumentar os reenvios do corpo. Examine no servidor como o identificador é gerado em relação à representação escolhida. A presença de uma ETag, sozinha, não prova que a implementação está correta.
4. Distinguir documentos mutáveis de recursos com novos nomes
Um documento que muda de conteúdo na mesma URL, como o horário, pode exigir uma estratégia diferente de logotipos e scripts que recebem novos nomes quando são alterados. Se o logotipo passar de logo.a1.png para logo.b2.png, por exemplo, o novo documento deverá apontar para o novo endereço. Inserir um identificador no nome, mas sobrescrever o conteúdo do arquivo antigo, quebra o compromisso de administrar conteúdo e endereço em conjunto.
Publicar um arquivo novo não faz, por si só, os visitantes solicitarem seu novo endereço. Se o HTML recebido continuar apontando para o logotipo antigo, o recurso anterior poderá ser reutilizado. Observe, portanto, o caminho de atualização do documento que referencia o recurso, além da configuração de cache deste. Em vez de igualar a duração de armazenamento de documentos e recursos, seja capaz de explicar quanto atraso é aceitável para cada um.
Durante uma implantação, documentos antigos e novos podem coexistir temporariamente. Publicar o documento novo antes de preparar seus recursos ou apagar os antigos cedo demais gera falhas distintas. Neste exemplo fictício, é possível verificar tanto a existência dos arquivos referenciados pelo documento novo quanto o acesso aos arquivos ainda usados pelos documentos existentes. A mudança de nome é uma ferramenta de projeto de cache, não uma solução automática para toda ordem de implantação ou reversão.
5. Testar uma hipótese por vez no painel Network
Para investigar diretamente, primeiro registre uma referência com o cache permitido. Observe juntos a URL exata e seus parâmetros de consulta, a versão do horário exibida, o status da resposta, If-None-Match na requisição e Cache-Control e ETag na resposta. Cabeçalhos de requisição e resposta expressam condições de participantes diferentes, mesmo quando os nomes coincidem; registre qual lado foi lido. A referência do Network no Chrome DevTools explica como distinguir esses itens em Headers.
| Situação fictícia de teste | Registros a observar em conjunto | Conclusão precipitada a evitar |
|---|---|---|
| Solicitar novamente o mesmo horário | Requisição condicional, status e horário exibido | Um 304 significa que não houve comunicação |
| Solicitar após alterar o horário original | Corpo novo, ETag e URL realmente solicitada | O aviso de salvamento bem-sucedido prova atualização para todos os usuários |
| Solicitar com cache do navegador desativado | Diferença entre primeiro download e revisita comum | Esse resultado representa o desempenho habitual de revisitas |
| Voltar pelo botão de navegação | Ocorrência de nova requisição e tela restaurada | Ver a tela prova que houve nova validação HTTP |
Depois teste desativar o cache do navegador como uma condição separada. O ajuste Disable cache do Chrome vale enquanto o DevTools está aberto, portanto registre tanto a abertura das ferramentas quanto seu valor. É útil para examinar o primeiro download, mas diferente de testar como uma revisita normal usa cópias armazenadas. Sem anotar o ajuste, downloads sempre novos podem ser confundidos com falha do cache. Guarde as condições do experimento para poder comparar novamente com o cache permitido.
Durante a observação, evite fazer muitas alterações e requisições ao mesmo tempo. Primeiro confira uma revisita com conteúdo inalterado; depois mude apenas um horário e veja como a resposta se altera. Modificar simultaneamente URL do documento, configuração do servidor e nomes de arquivos dificulta identificar a origem do resultado. Se o 200 ou 304 esperado não aparecer, releia a requisição e a resposta reais antes de acrescentar configurações.
6. Verificar outros armazenamentos e critérios de conclusão
Desativar o cache HTTP do navegador não significa eliminar uma CDN diante do servidor ou outros caminhos de armazenamento da aplicação. Examine separadamente se um service worker trata a requisição, qual resposta um intermediário seleciona e se a aplicação mantém na tela dados já recebidos. Ver a mesma URL não significa que todas as camadas usam a mesma cópia.
Também diferencie voltar na navegação de uma nova requisição HTTP. Quando o navegador restaura uma tela de uma sessão anterior, a revalidação esperada pode não aparecer mesmo com no-cache. Interpretar isso imediatamente como prova de que o servidor ignorou o cabeçalho pode levar à causa errada. Registre separadamente se houve requisição numa nova navegação, numa atualização e no retorno, para não reunir fenômenos distintos como um problema só.
O critério de conclusão do exemplo não é apenas uma boa taxa de acertos de cache. Confira se a cópia é usada corretamente quando nada mudou, se a informação nova aparece dentro do prazo permitido e se o compartilhamento atende ao público certo. Registrar horários de alteração e observação, condições e corpo real facilita reproduzir a situação. Números de velocidade melhores não atendem à necessidade inicial se horários incorretos continuam visíveis por tempo demais.
Na operação real, revise políticas por tipo de resposta junto com procedimentos de atualização e reversão. Não copie instruções de documentos públicos para respostas pessoais nem interprete uma validação bem-sucedida como verificação de acesso concluída. Cabeçalhos transmitem regras de armazenamento e reutilização. Explicar o que foi guardado e quais verificações levaram à tela atual ajuda a diagnosticar com mais precisão uma exibição desatualizada.