Saltar para o conteúdo 
HTTP condicional Os pedidos reduzem os custos de transmissão, garantindo que o cliente só carrega um recurso completamente se este tiver sido efetivamente alterado desde o último pedido. Vou mostrar como Validação da cache com ETag, Last-Modified, If-None-Match, If-Modified-Since e 304 Not Modified funciona de forma fiável e os tempos de carregamento são visivelmente reduzidos.
Pontos centrais
- Validação em vez do download completo: 304 poupa largura de banda e tempo.
- ETag e Last-Modified trabalham em conjunto para um controlo limpo.
- Controlo da cache define a frescura, expira apenas os suplementos.
- Condições prévias como os processos de escrita seguros If-Match.
- Segurança requer privado/não armazenar para conteúdos sensíveis.
O que fazem os pedidos condicionais na vida quotidiana
Eu fixo Condicional para fazer uma pergunta clara ao servidor: Preciso mesmo de transferir novos dados ou a minha cache é suficiente? O browser ou um proxy envia condições, o servidor verifica se um ficheiro foi alterado e responde com 304 Not Modified sem corpo. Este padrão mantém HTML, CSS, JavaScript, imagens e respostas de API actualizadas e reduz significativamente a carga na infraestrutura. Para activos válidos mais longos, utilizo valores longos de max-age e asseguro que estão actualizados através de validação. Se você tiver o Estratégias de controlo da cache tira o máximo partido das caches sem correr o risco de ficar com conteúdos desactualizados.
Cabeçalhos que permitem a validação da cache
Para uma fiabilidade Cache-O cliente precisa de sinais claros da resposta para tomar decisões. Utilizo o Cache-Control para a frescura e as regras, o Expires ocasionalmente como suplemento e o Last-Modified e o ETag para a validação efectiva. Last-Modified fornece um tempo de modificação que pode ser verificado rapidamente, enquanto ETag fornece um identificador de versão que também é usado para conteúdo dinâmico. Continua a ser importante: no-cache significa validar antes de utilizar, não eliminar. Se aplicar estas semânticas corretamente, conseguirá reduzir significativamente o tráfego de dados, mantendo o conteúdo atualizado. Conteúdo.
Sequência de um pedido condicional sem desvios
Na primeira chamada, o cliente guarda o ficheiro e os valores de validação, tais como ETag ou Last-Modified na cache. Mais tarde, o recurso expira ou requer uma nova verificação antes de ser utilizado, e o cliente envia If-None-Match ou If-Modified-Since. O servidor compara as informações com o estado atual e devolve 200 OK com um novo corpo ou 304 Not Modified sem carga útil. O cliente continua então a utilizar a cópia existente e poupa a transmissão, a carga de trabalho TLS e o tempo. Este ping-pong parece discreto, mas o Efeito sobre a sensação de carga e a carga do servidor é clara.
ETag vs. Last-Modified em comparação direta
Eu uso Última modificação Gosto de utilizar os carimbos de data/hora como referência rápida e simples, mas utilizo ETags para um controlo mais preciso. Os carimbos temporais podem atingir os seus limites com intervalos de alteração muito curtos ou falsificar resultados dinâmicos. Eu crio ETags a partir de hashes de ficheiros, versões de bases de dados ou variantes de renderização, pelo que cada alteração no conteúdo gera um novo identificador. Ambos os mecanismos podem ser combinados: O cliente pode enviar If-None-Match e If-Modified-Since em paralelo, e o servidor seleciona a verificação apropriada. Como garantir uma verificação fiável Validação, que se aplica igualmente aos recursos estáticos e dinâmicos.
| Critério | Última modificação | ETag |
|---|---|---|
| Exatidão | Segunda resolução, adequada para ficheiros | Identificador de versão para cada alteração de conteúdo |
| Dinâmica | Fraco com alterações frequentes e não baseadas em ficheiros | Forte para APIs e conteúdo renderizado |
| Despesas | Baixo, disponível a partir do sistema de ficheiros | Baixa a moderada, geração na aplicação/proxy |
| Conflitos | Possibilidade de desvios do relógio | Possibilidade de configuração incorrecta de etiquetas fracas/fortes |
Definições corretas para o caching do browser e APIs
Para activos estáticos, utilizo o longo idade máxima e guardar através de ETag ou hash de nome de ficheiro, para que as actualizações sejam reconhecidas imediatamente. Costumo marcar as respostas HTML e API com no-cache para que o cliente as valide antes de as utilizar sem ter de recarregar tudo de cada vez. Marco as páginas personalizadas com private para que as caches partilhadas não mostrem nada que tenha sido retido a outros. Os erros são frequentemente causados por diretivas contraditórias ou cabeçalhos de validação em falta, que evito com regras claras. Se conhecer os obstáculos típicos, pode facilmente evitá-los; bons exemplos disto podem ser encontrados no artigo sobre Armadilhas de cabeçalho no caching, que gosto de me orientar.
Utilizar códigos de estado e condições de forma eficaz
Eu organizo Códigos de estado claramente: 200 OK entrega o conteúdo, 304 Not Modified confirma a utilização da cache e 412 Precondition Failed cancela se uma condição não for satisfeita. Para operações de escrita seguras, utilizo If-Match para que as actualizações só tenham efeito se o ETag corresponder à versão esperada. Ler com If-None-Match ou If-Modified-Since evita cargas supérfluas e mantém os clientes sincronizados. O comportamento consistente é importante: O mesmo ponto final deve responder de forma idêntica para condições prévias idênticas. Para SEO e bots, presto atenção à forma como as caches e os crawlers interpretam as mensagens de estado; uma boa visão geral de Códigos de estado HTTP e rastreio ajuda a tomar decisões limpas.
Segurança e proteção de dados para caching
Trato os conteúdos sensíveis com não armazenar e, assim, não lhes dá qualquer hipótese de acabarem na cache do browser ou do proxy. Marco as páginas personalizadas com Cache-Control: private e verifico que não aparecem dados pessoais em URLs armazenados em cache a longo prazo. Concebo os ETags de forma neutra, sem permitir que se tirem conclusões sobre contas de utilizador ou IDs internos. Desactivo sistematicamente todo o armazenamento em cache para visualizações de início de sessão e fluxos bancários. Se combinar minimização de dados, diretivas adequadas e cabeçalhos limpos, reduz o risco e protege os seus dados. Confidencialidade.
Implementação: Passos para o servidor e a aplicação
No início, separo estático de recursos dinâmicos e decidir onde os prazos longos fazem sentido e onde a validação tem prioridade. No Nginx, no Apache ou num servidor de aplicações, configuro o controlo da cache e ativo last-modified e ETags, colocando a geração de ETags na aplicação para pontos finais dinâmicos. Ao processar pedidos de entrada, avalio If-None-Match e If-Modified-Since e respondo com 304 se a condição corresponder. Para operações de escrita, utilizo If-Match e devolvo 412 em caso de desvios para evitar a substituição. Isto cria um comportamento consistente que utiliza as caches de forma eficiente e ao mesmo tempo Correção garante.
Utilizar de forma sensata as métricas, os testes e o controlo
Verifico o Rede-tab do DevTools para verificar se os recursos estão a vir da cache, se estão a ser validados ou se foram carregados recentemente. Monitorizo o estado, os valores de idade, as ETags e o tamanho da resposta transferida. Sob carga, meço a latência, o volume de transferência e a CPU do servidor para ver o efeito real das 304 respostas. Os registos do proxy inverso mostram se as caches partilhadas estão a fazer o seu trabalho e quantas validações são bem sucedidas. Utilizo estes dados para ajustar a idade máxima, as diretivas de controlo da cache e as estratégias ETag até que os tempos de resposta e Taxa de acerto votar.
Desempenho do alojamento: Porque é que os pedidos condicionais poupam dinheiro
Qualquer 304-A resposta da cache partilhada poupa largura de banda, reduz a sobrecarga de TLS e encurta o tempo de resposta, o que é particularmente importante para muitos pedidos semelhantes. Nas configurações de alojamento com proxies inversos, equilibradores de carga e CDN, obtenho o maior efeito quando permito ou excluo especificamente as caches partilhadas. Menos transferências significam também, muitas vezes, custos de tráfego mais baixos em euros e mais reservas para picos de carga reais. A experiência do utilizador também é melhorada porque as visualizações de página repetidas e as pesquisas de API respondem mais rapidamente. Desta forma, realizo o potencial de desempenho que as actualizações de hardware por si só não podem proporcionar e utilizo os Infra-estruturas melhor.
Erros comuns e soluções pragmáticas
Contraditório Cabeçalho como "no-cache" emparelhado com "expires far in the future" confundem as caches; estabeleço regras claras sem duplicação. A falta de ETags para endpoints dinâmicos leva a descarregamentos completos desnecessários; adiciono um identificador fiável e avalio se não houver correspondência. Valores de max-age demasiado curtos desperdiçam potencial com ficheiros raramente alterados; estico os prazos e ainda os protejo com validação. O caching agressivo de HTML atrasa as alterações visíveis; combino o no-cache com o ETag e mantenho o conteúdo atualizado. Com decisões claras sobre atualidade, validação e validade, resolvo estes obstáculos e reforço a Planeamento.
Utilizar o Vary de forma limpa e controlar as representações
Para garantir que os pedidos condicionais funcionam de forma segura em caches partilhados, certifico-me de que utilizo o Variar. O cabeçalho define quais os cabeçalhos do pedido que influenciam a representação. Exemplos típicos são Aceitar codificação (gzip, br), Aceitar idioma e Aceitar. Se forneço conteúdos por língua, defino Vary: Accept-Language para que um proxy não partilhe a versão alemã em resposta a um pedido francês. Para conteúdos personalizados, dispenso deliberadamente o Vary: Cookie e, em vez disso, utilizo Controlo da cache: privado, para evitar uma explosão incontrolável de chaves de cache. Para os recursos que só são entregues com autorização válida, utilizo private ou asseguro uma separação clara com Vary: Authorisation ou Vary nos cabeçalhos relevantes. A consistência é importante: o conjunto selecionado de dimensões Vary tem de permanecer estável, caso contrário, a taxa de acerto da cache e os benefícios da validação entrarão em colapso porque estão constantemente a ser criadas novas variantes.
ETags fortes vs. fracos, compressão e igualdade de bytes
ETags fortes caracterizam representações idênticas byte a byte e permitem uma validação exacta, também em combinação com pedidos de alcance. ETags fracos (W/...) apenas indicam igualdade de conteúdo, não necessariamente bytes idênticos. Na prática, utilizo ETags fortes se puder gerar um identificador único para cada representação (incluindo a compressão). Assim que um proxy inverso utiliza gzip ou brotli em tempo real, adapto a geração de ETags ou mudo para ETags fracos, para que o servidor e o cliente não reconheçam erradamente bytes diferentes como idênticos. Uma variante robusta consiste em criar o ETag a partir dos bytes finais da resposta entregue e, ao mesmo tempo, utilizar Vary: Aceitar-Codificação a ser definido. Isto garante que „gzip“ e „br“ recebem cada um os seus próprios ETags válidos. Nos casos em que não posso garantir a igualdade de bytes (por exemplo, carimbos de data/hora diferentes em HTML), escolho ETags fracos que ainda permitem respostas 304 fiáveis, desde que o significado da página não tenha mudado.
Controlo da cache na afinação fina: s-maxage, must-revalidate, stale-while-revalidate
Além de idade máxima Utilizo especificamente diretivas mais finas. s-maxagem dirige-se exclusivamente Caches partilhadas (CDNs, proxies) e permite-me fazer cache de forma mais agressiva do que no browser. deve revalidar obriga os clientes a não utilizarem conteúdos expirados de forma heurística, mas a validarem-nos sempre - útil para dados críticos. revalidar proxy aborda esta obrigação especificamente para as caches partilhadas. Com obsoleto-enquanto-revalidado Permito que uma cópia ligeiramente desactualizada seja entregue temporariamente enquanto a validação é executada em segundo plano; os utilizadores vêem algo imediatamente e o pedido seguinte beneficia de metadados frescos. estagnação em caso de erro como uma rede de segurança: Se a Origem falhar ou retornar erros, o cache pode entregar a última cópia conhecida por um tempo definido. Para ativos com hash de compilação, eu combino max-age longo com imutável, uma vez que o nome do ficheiro muda com o conteúdo e as validações intermédias são desnecessárias. Para HTML e APIs, a validação sem cache mais validador continua a ser o padrão de ouro para garantir a atualidade e ainda poupar largura de banda.
Outras condições e métodos: HEAD, gama e conflitos de escrita
Os pedidos condicionais não se limitam a GET. A HEAD-request apenas fornece cabeçalhos e é ideal para validações rápidas sem um corpo. Para arquivos grandes eu uso Gama-pedidos; com Se-Faixa Certifico-me de que as áreas parciais só são enviadas se o recurso ainda corresponder à versão esperada - caso contrário, respondo com 200 e um corpo completo. Para operações de escrita, asseguro a consistência com Se-correspondência ab: PUT, PATCH ou DELETE só funcionam se o ETag do cliente corresponder à versão atual; caso contrário, respondo com 412 Precondition Failed. Quando quero impor condições prévias, por exemplo com recursos propensos a conflitos, uso 428 Precondition Required para fazer com que os clientes usem If-Match. Escolho deliberadamente entre o 409 Conflito e o 412: o 412 assinala a violação de condições prévias, o 409 realça os conflitos de conteúdo (por exemplo, regras de lógica empresarial). Esta clareza facilita as implementações dos clientes e evita sobreposições cegas.
Personalização, cookies e proteção de dados na prática
Nas páginas personalizadas, assinalo as respostas com privado ou não armazenar. Evito codificar os estados dos utilizadores em etiquetas electrónicas porque essas etiquetas electrónicas „por utilizador“ podem involuntariamente tornar-se marcadores de localização. Em vez disso, faço uma distinção rigorosa entre representações públicas e privadas. Só coloco cookies na chave da cache (Vary: Cookie) se for absolutamente necessário, porque aumentam o número de variantes e reduzem drasticamente a taxa de acerto. Para as respostas autorizadas da API, limito-me a Controlo da cache: privado e, se necessário, para Vary no formato do cabeçalho de autorização. É assim que asseguro que as caches partilhadas não partilham inadvertidamente respostas confidenciais. Em aplicações com conteúdo misto (estrutura básica pública, subáreas personalizadas), confio no cache fragmentado ou no ESI/SSI de borda, enquanto as partes críticas permanecem privadas. O resultado é a proteção dos dados sem uma queda no desempenho.
Funcionamento: CDNs, substitutos e invalidações
Nas configurações CDN, combino s-maxagem com validadores claros e - se disponíveis - utilizar diretivas específicas de substitutos para controlar as caches de borda separadamente do navegador. A revalidação reduz a carga na Origin, mas, ocasionalmente, é necessária uma invalidação definitiva (por exemplo, uma correção de segurança). Então, eu planeio duas maneiras: Quebra de cache através de hashes de nomes de ficheiros para activos estáticos e Purga/Invalidação para HTML e APIs. Isso evita „tempestades de purga“ e ainda mantém um tempo curto para atualização. Também é importante ter uma chave de cache consistente na CDN (incluindo host, caminho, parâmetros de consulta e cabeçalhos Vary relevantes). Para os parâmetros de consulta, diferencio conscientemente entre parâmetros semânticos (por exemplo, ?lang=) e parâmetros puramente relacionados com o rastreio; ignoro estes últimos na chave da cache para evitar a fragmentação. Isso mantém a cadeia de cache do navegador, proxy intermediário e CDN transparente e previsível.
304 em pormenor: Atualizar corretamente o cabeçalho e os metadados
Também um 304-A resposta contém metadados importantes. Entrego novamente Date, Cache-Control, ETag/Last-Modified e - se relevante - Expires e Vary para que o cliente possa atualizar as suas entradas na cache. Content-Type e Content-Encoding não têm necessariamente de ser repetidos, mas podem contribuir para a clareza. É importante que o 304 não contenha uma carga útil de corpo e que eu envie validadores consistentes: Alterar o ETag no 304 sem alterar a representação gera confusão. Se as diretrizes forem ajustadas (por exemplo, max-age mais longo), o cliente pode adotar os metadados sem ter de recarregar o corpo - uma pequena alavanca com um grande impacto no desempenho percebido.
Estratégias de teste e depuração para uma validação limpa
Verifico especificamente os seguintes pontos no DevTools: da cache do disco vs. da memória cache vs. revalidado; Status 200/304; cabeçalho Age em respostas de caches compartilhadas; consistência ETag/Last-Modified e o efeito de Vary. Para testes reproduzíveis, desactivei temporariamente a cache do browser ou utilizei um modo privado. No lado do servidor, avalio os registos no rácio 200/304, o tamanho médio da resposta e a utilização da CPU. Os sinais de aviso são, por exemplo, muitas respostas 200 a recursos com intervalos de alteração curtos (falta de validadores), loops de revalidação (tempos divergentes/desvio do relógio) ou um número invulgarmente elevado de variantes por URL (Vary excessivo). Utilizo testes de carga para verificar como s-maxage, stale-while-revalidate e if-none-match se comportam sob pressão - e ajusto as diretivas até que o débito e a latência coincidam.
Casos extremos e predefinições robustas
Nem todos os recursos têm regras de alteração claras. Defino padrões cuidadosos para sitemaps, feeds ou painéis gerados: sem cache mais ETag/Last-Modified. Com relógios instáveis entre sistemas a montante, evito comparações rígidas de segundos e prefiro ETags que sejam independentes de carimbos de data/hora. Se a compressão for variável (diferentes níveis de gzip), incluo o resultado da compressão na geração do ETag ou mudo para ETags fracos. E se os clientes pedirem sem validadores, envio sinais claros: Ou uma frescura clara (max-age/immutable) ou uma validação clara (no-cache + ETag). Estes predefinições robustas garantir que mesmo os clientes incompletos ou defeituosos não desencadeiem picos de carga indesejados.
Breve resumo
Ligar pedidos condicionais Velocidade e atualidade, fazendo com que os clientes só recuperem recursos completos quando o conteúdo tiver sido alterado. Utilizo o controlo de cache para garantir a atualidade, combino last-modified e ETag para verificações fiáveis e respondo consistentemente com 304 se as condições forem cumpridas. Isolo os conteúdos personalizados e confidenciais com private ou no-store para que nenhum dado acabe em caches partilhadas. As medições no DevTools, os registos e as métricas mostram-me onde posso esticar os prazos ou apertar a lógica de validação. Se pensar nestes blocos de construção em conjunto, conseguirá páginas mais rápidas, uma carga reduzida no servidor e um mais redondo Experiência do utilizador sem desperdício de dados.
