Cache com as regras certas
Quais respostas podem ser reutilizadas, por quem, por quanto tempo e como confirmar que a cópia guardada ainda vale.
Reutilizar uma resposta é evitar trabalho
Uma resposta já disponível perto do visitante economiza transferência, processamento e tempo de espera. O navegador pode manter uma cópia privada para a mesma pessoa. Um intermediário pode manter uma cópia compartilhada para atender várias pessoas. As duas camadas reduzem trabalho, mas têm responsabilidades diferentes.
Cache privado pode armazenar conteúdo ligado a um único usuário quando a política permite. Cache compartilhado precisa ser mais conservador, pois uma resposta destinada a uma pessoa jamais deve aparecer para outra. Por isso a estratégia começa pela classificação da resposta: pública ou pessoal, estável ou volátil.
A chave decide se duas requisições são equivalentes
Todo cache escolhe uma resposta usando uma chave. O endereço solicitado costuma fazer parte dela, mas método, cabeçalhos e regras do intermediário também podem influenciar. Se a página varia por idioma, codificação ou outro atributo, essa variação precisa ser representada de maneira controlada.
O cabeçalho Vary informa quais campos da requisição participaram da escolha da representação. Cada variação declarada amplia o conjunto de objetos armazenados e reduz a chance de acerto. Variar uma página por muitos cookies ou cabeçalhos pode tornar o cache compartilhado quase inútil.
Fresco, desatualizado e validado são estados diferentes
Uma resposta fresca pode ser reutilizada sem consultar a origem. Ao fim do período de frescor, ela não precisa ser baixada inteira outra vez. Validadores como ETag e Last-Modified permitem perguntar se o conteúdo continua igual; quando continua, uma resposta curta confirma a cópia existente.
Essa diferença evita dois extremos: consultar a origem a cada acesso ou servir conteúdo antigo sem controle. Diretivas de Cache-Control expressam a política, incluindo tempo de frescor, armazenamento privado, proibição de armazenamento e exigência de revalidação.
Recursos versionados aceitam validade longa
Folhas de estilo, scripts, fontes e imagens podem receber endereços que mudam quando o conteúdo muda. Nesse modelo, o endereço antigo continua representando o arquivo antigo e o novo conteúdo recebe outro endereço. O recurso pode permanecer em cache por muito tempo sem impedir uma atualização.
O contrato precisa ser verdadeiro: o mesmo endereço versionado não deve passar a entregar bytes diferentes. Caso contrário, navegadores e pontos de presença passam a manter variantes incompatíveis. A versão faz parte da identidade do recurso.
HTML e dados personalizados pedem outra política
Documentos podem mudar com frequência e também carregar dados de sessão, permissões ou preferências. Uma página pública pode aceitar uma validade curta ou revalidação. Uma resposta autenticada costuma exigir cache privado ou proibição de armazenamento compartilhado, conforme o conteúdo e o risco.
Além do conteúdo velho existe o risco de vazamento: uma chave incompleta ou uma resposta personalizada marcada como pública chega ao usuário errado. Segurança e correção vêm antes da taxa de acerto.
Invalidar é parte do desenho
Toda estratégia precisa responder como uma correção urgente chega ao público. Endereços versionados evitam a invalidação de recursos estáticos. Para conteúdo mantido no mesmo endereço, expiração curta, revalidação ou remoção seletiva podem ser mais adequadas.
A operação observa acertos, erros, idade das respostas e comportamento da origem. Uma taxa alta de acerto com a chave errada só distribui mais rápido a resposta de uma pessoa para outra. A métrica útil combina redução de carga, atualização previsível e conteúdo correto em cada requisição.