...
logótipo de alojamento web

Estratégias de controlo da cache HTTP no alojamento: dominar a otimização da Web

Utilizo o alojamento de controlo de cache para controlar especificamente a forma como os navegadores, proxies e CDNs armazenam conteúdos em cache, de modo a que as páginas carreguem mais rapidamente e se mantenham actualizadas. Para o fazer, utilizo diretivas como max-age, no-cache ou no-store e, assim, equilibrar o desempenho, a atualidade e a carga do servidor para HTML, activos e APIs.

Pontos centrais

A panorâmica seguinte mostra as alavancas mais importantes para Otimização da Web com controlo de cache.

  • Conceção TTLIdade máxima longa para activos, tempos curtos ou revalidação para HTML.
  • ValidaçãoETag e Last-Modified reduzem o tráfego de dados com respostas 304.
  • Controlos de bordas-maxage, stale-while-revalidate e stale-if-error para CDNs.
  • VersionamentoNomes de ficheiros com hash/versão permitem caches agressivos.
  • MonitorizaçãoVerificar continuamente as taxas de acerto da cache, as quotas 304 e o TTFB.

O que torna o controlo da cache tão eficaz no alojamento?

Transfiro o trabalho do servidor de origem para o Cache, reduzir a latência e poupar largura de banda. Um cabeçalho de controlo de cache corretamente definido controla o tempo de validade dos ficheiros e quando o cliente os solicita ao servidor. Planeio longos períodos de validade para activos como imagens, CSS e JS, enquanto o HTML permanece por um curto período de tempo ou é sempre validado. Isto significa que os utilizadores encontram respostas em cache com mais frequência e ainda recebem atual Conteúdo. Evito os obstáculos típicos, como cabeçalhos contraditórios ou falta de versões, desde o início, por exemplo, com isto Guia de correção da cache.

Noções básicas: Combinar diretivas corretamente

Com idade máxima Defino o tempo de vida em segundos, como 31536000 para um ano para recursos estáticos. no-cache obriga o cliente a validar antes da utilização, mas não proíbe o armazenamento. no-store exclui qualquer armazenamento e protege respostas sensíveis, como dados de pagamento. public permite o armazenamento em cache em armazenamento partilhado, como CDNs, private limita-se à cache do browser. immutable indica que o ficheiro permanece inalterado, o que pode ser alterado com Versionamento (por exemplo, app.v1.2.js) são uma excelente adição.

Definir claramente os cabeçalhos Vary e as chaves da cache

Certifico-me de que os objectos armazenados em cache correspondem ao tipo de pedido. O VariarO cabeçalho -header pertence, portanto, a todas as estratégias de cache sérias. Influencia a chave da cache e impede a reutilização incorrecta:

  • Aceitar codificaçãoObrigatório com gzip/br, para que as variantes comprimidas e não comprimidas sejam armazenadas em cache separadamente.
  • Aceitar idiomaUtilizar apenas se estiver realmente a fornecer conteúdos dependentes da língua - caso contrário, existe o risco de fragmentação.
  • Biscoito: Evito um Vary: Cookie, porque isso destrói as taxas de acerto da cache. Em vez disso, faço uma segmentação específica de acordo com os cookies relevantes (por exemplo, variante A/B) ou removo os cookies irrelevantes no limite.
  • AutorizaçãoOs conteúdos que dependem de cabeçalhos de autenticação não são armazenados em caches partilhados ou são deliberadamente codificados se o fornecedor de CDN o suportar.
# Apache: cabeçalhos Vary significativos para HTML e activos

  Fusão de cabeçalhos Vary "Accept-Encoding"


  Cabeçalho merge Vary "Accept-Encoding"

Também defino regras claras de chave de cache em CDNs: Não incluo na chave os parâmetros de consulta que só são utilizados para rastreio (por exemplo, utm_*). Isto evita a explosão de chaves sem comprometer a atualidade.

Prática: Configuração no Apache e no Nginx

No Apache, defino regras no diretório .htaccess ou no VirtualHost. Separo o HTML dos activos, dou aos ficheiros estáticos uma vida útil longa e protejo o HTML com revalidação. Evito conflitos com cabeçalhos Expires, os browsers modernos respeitam principalmente o controlo da cache. No Nginx, imponho posições corretas de add_header e asseguro-me de que nenhuma instrução a jusante as substitui. É assim que controlo Cache do navegador consistente em toda a pilha.

Header set Cache-Control "public, max-age=31536000, immutable"


  Header set Cache-Control "no-cache, must-revalidate"

localização ~* \.(css|js|png|jpg|svg|woff2)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}
localização ~* \.(html)$ {
  add_header Cache-Control "no-cache, must-revalidate";
}

Cache somente de CDN para HTML

Se o navegador deve sempre verificar, mas o Edge tem permissão para armazenar em cache, defino tempos de vida diferentes para o cliente e a CDN:

# Apache: Navegador revalidado, Edge armazenado em cache 5 minutos

  Header set Cache-Control "public, max-age=0, s-maxage=300, must-revalidate, stale-while-revalidate=30, stale-if-error=86400"
  Mesclagem de cabeçalho Vary "Accept-Encoding"


# Nginx
localização ~* \.(html)$ {
  add_header Cache-Control "public, max-age=0, s-maxage=300, must-revalidate, stale-while-revalidate=30, stale-if-error=86400";
  add_header Vary "Accept-Encoding";
}

Validação: utilizando ETag e Last-Modified efetivamente

Eu combino Controlo da cache com ETag e Last-Modified para revalidar de forma controlada. Após a expiração, o navegador envia If-None-Match ou If-Modified-Since; o servidor responde com 304 se o recurso não tiver sido alterado. Isto poupa bytes e reduz significativamente o tempo de CPU na Origem. Importante: as ETags devem ser consistentes, caso contrário, ocorrerão erros desnecessários apesar do conteúdo inalterado. Em clusters, eu desativo ETags fracas ou crio hashes fortes para que o reabilitação permanece fiável.

Consistência em ambientes multi-servidor

Certifico-me de que os ETags não se baseiam em caraterísticas baseadas em inodes que diferem entre nós. Forneço um hash estável (artefacto de construção) ou confio na última modificação quando as implementações são atómicas. Para respostas dinâmicas, utilizo ETags de aplicação que correspondem exatamente ao hash do payload. Se a revalidação for mais dispendiosa do que a nova renderização, respondo deliberadamente com 200 e um TTL curto - a medição decide.

Estratégias por tipo de recurso

Faço a diferenciação de acordo com o tipo de conteúdo, porque HTML, activos, APIs e respostas sensíveis têm diferentes Requisitos. Os TTLs longos para ficheiros com versões fornecem os melhores valores, enquanto que o HTML deve ser gerido de forma rigorosa. Planeio tempos de vida curtos para as APIs e integro a tolerância a falhas. Evito qualquer armazenamento de respostas pessoais ou confidenciais. Aqueles que se aprofundam nas interfaces beneficiam de padrões compactos para Armazenamento em cache da API no alojamento, que adapto às caraterísticas da resposta.

Tipo de recurso Diretiva recomendada Motivo
Activos estáticos (imagens, CSS, JS) público, max-age=31536000, imutável Armazenamento longo; impedimento do controlo de versões Stale-Conteúdo
Páginas HTML no-cache, must-revalidate Conteúdo fresco através de reabilitação
APIs public, max-age=300, stale-if-error=86400 Prazo curto, utilizável para Erros
Dados sensíveis não armazenar Sem armazenamento de Proteção de dados-Razões

Códigos de estado, redireccionamentos e páginas de erro

  • 301 pode e deve ser armazenado em cache (TTL longo), uma vez que é permanente. Eu versiono os URLs de destino para facilitar alterações posteriores.
  • 302/307 são temporários - TTL curto ou revalidação, caso contrário, existe o risco de existirem caminhos incorrectos na cache.
  • 404 Coloco em cache durante um curto período de tempo (por exemplo, 60-300s) para que os hotlinks defeituosos não sobrecarreguem o Origin sem bloquear as verdadeiras recriações.
  • 500+ Não coloco na cache, mas deixo o Edge estagnação em caso de erro para fornecer aos utilizadores as informações mais recentes.

Diretivas alargadas para CDNs e Edge

Com s-maxagem Separo o tempo de vida na cache do edge do tempo de vida no browser. stale-while-revalidate continua a fornecer conteúdo expirado enquanto o edge actualiza em segundo plano. stale-if-error mantém as páginas acessíveis durante interrupções no backend e aumenta a conversão e a confiança. must-revalidate força uma verificação após a expiração e evita renovações indesejadas. Este controlo paga diretamente nas taxas de acerto da cache e Escalonamento especialmente durante os picos de tráfego.

Cabeçalhos substitutos e de extremidade

Em configurações com renderização de bordas, também utilizo cabeçalhos substitutos (por exemplo. Controlo substituto) para definir mais TTLs específicos de CDN e políticas obsoletas sem alterar o comportamento do navegador. Desta forma, separo estritamente o utilizador final da estratégia de ponta e mantenho o meu controlo sobre ambos os níveis.

Invalidação e libertações

Planeio a invalidação de forma consciente: os activos com versões raramente precisam de purgas, enquanto os percursos HTML e API precisam delas com mais frequência. Defino rotinas claras para:

  • Purga por URL/Padrão para correcções e erros.
  • Purgas baseadas em etiquetas (se suportado) para invalidar o conteúdo relacionado com a temática.
  • Implementações faseadasPrimeiro, implemente os activos e, em seguida, HTML com novas referências - isto evita referências quebradas.

WordPress: Implementar o armazenamento em cache de forma segura

No WordPress, ativo os cabeçalhos através de plugins ou do meu próprio código e observo a Modelo-estrutura. Os ficheiros estáticos em wp-includes e uploads recebem TTLs longos e imutáveis, as páginas recebem no-cache com must-revalidate. Cuidado com os utilizadores com sessão iniciada: os cookies privados e diferenciados impedem a personalização incorrecta na cache. Elimino os obstáculos típicos com regras claras e um olhar sobre estes Erro de cache do WordPress. Se necessário, adiciono o caching de páginas do lado do servidor e o OPCache para tornar a execução do PHP percetível. diminuições.

<?php
função add_cache_headers() {
    se (!is_admin()) {
        header('Cache-Control: public, max-age=31536000, immutable', true);
    }
}
add_action('send_headers', 'add_cache_headers');

Desativar a personalização e os cookies

Certifico-me de que Set-Cookie não está definido em todas as páginas. Os cookies desnecessários impedem o armazenamento em cache partilhado. Entrego explicitamente para os utilizadores com sessão iniciada:

# Exemplo de cabeçalho para sessões com sessão iniciada
Cache-Control: private, no-store, max-age=0
Vary: Accept-Encoding

As páginas de listagem e de pormenor sem personalização, por outro lado, obtêm todo o poder da CDN. Quando a personalização é necessária, trabalho com fragmentos de borda ou pequenas cargas úteis de API e coloco o resto em cache de forma agressiva.

Erros comuns e como os corrijo

Demasiado baixo TTL gera trabalho desnecessário do servidor e tempos de resposta mais elevados. Cabeçalhos em falta ou contraditórios obrigam os navegadores a adotar um comportamento heurístico e prejudicam o desempenho. Sem o controlo de versões, arrisco-me a ter activos desactualizados, apesar das longas caches. Estratégias ETag diferentes em vários servidores levam a falhas; asseguro hashes consistentes ou desativo ETags nesses servidores. Também verifico se os intermediários, como os gateways, têm as suas próprias Cabeçalho e substituir.

Evitar o caching heurístico

Se nem o Cache-Control nem o Expires estiverem definidos, os navegadores adivinham. Por isso, desligo sempre as diretivas explícitas e limpo os problemas antigos (por exemplo. Pragma: no-cache de proxies antigos) para obter um comportamento determinista.

Strings de consulta e eliminação da cache

Eu uso o cache busting através de hashes de nomes de ficheiros (style.abc123.css) em vez de strings de consulta. Muitas caches tratam consultas diferentes como objectos separados e, assim, aumentam o número de objectos; com ficheiros inalterados, por outro lado, um novo hash leva a uma invalidação limpa.

Monitorização, testes e métricas

Meço os efeitos e faço correcções específicas em vez de fazer mudanças radicais, porque os dados superam o instinto claro. Utilizo o curl para verificar os cabeçalhos, o DevTools para simular as primeiras e repetidas visualizações e o Lighthouse para avaliar o efeito nos índices. Do lado do servidor e da CDN, monitorizo as taxas de acerto da cache, as quotas 304, as gravações de bytes e o TTFB. Os registos mostram-me se o HTML é realmente revalidado e se os recursos raramente são solicitados novamente. Isto permite-me reconhecer as falhas numa fase inicial e melhorar direcionado.

Sinais de diagnóstico adicionais

  • Idade-header mostra há quanto tempo um objeto está na cache - ideal para verificar a s-maxage.
  • Estado da cache (se disponível) revela HIT/MISS/STALE e a fonte (BROWSER, CDN, ORIGIN).
  • Tempo do servidor Utilizo-o para os meus próprios marcadores (por exemplo, cache;desc=“revalidated“) para tornar os caminhos visíveis nas ferramentas.

Automatizo as verificações no pipeline CI/CD: Após cada implementação, um pequeno catálogo de testes valida cabeçalhos, códigos de estado e tamanhos de resposta para as principais rotas. As regressões são detectadas imediatamente.

SEO e efeitos comerciais

Uma entrega mais rápida reforça o Core Web Vitals, reduz as devoluções e aumenta a Visibilidade. Cada viagem de ida e volta evitada reduz os custos do servidor e minimiza o risco de picos de carga. Com sítios de tráfego intenso, poupo mensalmente um volume de dados considerável que, consoante a tarifa, pode atingir montantes de três dígitos em euros. Uma taxa de acerto de cache elevada também estabiliza os tempos de resposta para campanhas e vendas. Quem aumenta o desempenho de forma previsível, geralmente também aumenta o Conversão.

Lista de controlo prática em 7 passos

(1) Inventariar ficheiros e separar HTML, activos, APIs e respostas sensíveis; estes Segmentação facilita as regras. (2) Introduzir o controlo de versões para CSS/JS/imagens; utilizar hashes em nomes de ficheiros e definir imutável. (3) Definir "no-cache" e "must-revalidate" para HTML; manter as páginas actualizadas e controláveis. (4) Definir TTLs curtos para APIs e stale-if-error para mitigar falhas. ficar. (5) Ativar ETag ou Last-Modified de forma consistente; verificar as quotas 304. (6) Sincronizar os cabeçalhos CDN e Origin; utilizar s-maxage para Edge. (7) Medir as taxas de acerto, TTFB e poupança de bytes; otimizar iterativamente e documentar as decisões.

Casos práticos e amostras adicionais

  • APIs com pedidos condicionaisPermito explicitamente respostas GET/HEAD na cache partilhada (pública) com um TTL e ETag curtos. Só coloco em cache as respostas POST se forem definidas com precisão e inalteradas - permanecem não armazenáveis por defeito.
  • Ficheiros grandes e pedidos de alcancePara os Media, eu entrego Accept-Ranges: bytes e TTLs longos; o Edge alivia a Origem ao retomar os downloads.
  • Imagens responsivasSe emitir diferentes variantes de imagem consoante o dispositivo, codifico-as especificamente (por exemplo, de acordo com o DPR ou a largura) e evito uma variação descontrolada em demasiados sinais.
  • Sem transformaçãoSe a qualidade da imagem ou a criptografia forem críticas, utilizo Cache-Control: no-transform, para que os proxies não alterem o recurso.

Resumo para levar

Utilizo o Cache-Control especificamente para Desempenho, para harmonizar prazos e custos. Os TTLs longos e o controlo de versões para os activos, a revalidação para o HTML e os prazos curtos para as APIs proporcionam bons resultados fiáveis. O ETag e o Last-Modified reduzem o tráfego de dados, enquanto as políticas de s-maxage e stale utilizam o edge caching. A monitorização torna os efeitos visíveis e mostra onde devo apertar o cerco. Isto mantém o alojamento rápido, controlável e económico atrativo.

Artigos actuais