Saltar para o conteúdo 
O cache do navegador do WordPress muitas vezes causa respostas lentas, porque os operadores têm que Cabeçalho da cache definidas incorretamente ou não controladas de todo. Vou mostrar-lhe como as configurações incorrectas típicas devolvem 200 em vez de 304, porque é que os TTLs estão em falta e como posso configurar corretamente a cache no WordPress. Desempenho guarnição.
Pontos centrais
- TTL longo para activos estáticos evita pedidos desnecessários.
- Separação clara de caminhos estáticos e dinâmicos protege o admin e o login.
- Um sistema não misture plug-ins de cache concorrentes.
- Verificar os cabeçalhos com DevTools e estado 304.
- Armazenamento em cache no servidor e a cache do browser.
Como funciona realmente a cache do navegador no WordPress
O browser armazena ficheiros estáticos localmente, poupando assim a necessidade de os recarregar. Pedidos HTTP. Na segunda visita, lê imagens, CSS e JS da memória local e só pede alterações ao servidor. Isto reduz a quantidade de dados, os tempos de resposta são reduzidos e a deslocação parece imediatamente mais reactiva. líquido sobre. Se não houver instruções claras, o browser recarrega-se completamente de cada vez e o tempo de interação é prejudicado. Os cabeçalhos de controlo de cache corretamente definidos permitem validações 304, reduzem a largura de banda e reduzem a carga no PHP e na base de dados. Utilizo-o sistematicamente porque os utilizadores recorrentes, em particular, são os que mais beneficiam da cache persistente.
Porque é que a configuração falha frequentemente
Muitos sítios fornecem ficheiros estáticos com idade máxima-valores. Alguns plugins sobrescrevem os .htaccess uns dos outros e definem diretivas contraditórias. Muitas vezes, o site marca incorretamente os caminhos de administração, fazendo com que o conteúdo de /wp-admin ou /wp-login.php acabe na cache de forma não intencional e as sessões colidam. Também verifico a diferença entre a primeira chamada e a chamada recorrente, uma vez que isto explica claramente as experiências reais dos utilizadores; a comparação enquadra-se no seguinte Primeira chamada vs. chamada de retorno. Se continuar a utilizar cadeias de caracteres de consulta sem controlo de versão, criará ficheiros antigos na memória e questionar-se-á sobre obsoleto Estilos.
Definir corretamente os cabeçalhos da cache do WP
Controlo a duração com Controlo da cache e Expires, e evito ETags ambíguas em ambientes multi-servidor. Para o Apache, defino Expires para valores significativos e defino „public, max-age“ para os activos. Para o Nginx, adiciono diretivas add_header e certifico-me de que o HTML tem tempos curtos ou „no-store“ se o conteúdo for personalizado. Também desativo os cabeçalhos ETag se os balanceadores de carga ou proxies não gerarem esses valores de forma consistente. Desta forma, imponho um comportamento claro no browser e evito Revalidações com cada clique.
ExpiresActive On
ExpiresByType image/jpeg "acesso mais 1 ano"
ExpiresByType image/png "acesso mais 1 ano"
ExpiresByType text/css "acesso mais 1 mês"
ExpiresByType application/javascript "acesso mais 1 mês"
Header set Cache-Control "public, max-age=31536000" "expr=%{CONTENT_TYPE} =~ m#^(image/|font/|application/javascript)#"
Header set Cache-Control "no-cache, no-store, must-revalidate" "expr=%{REQUEST_URI} =~ m#(wp-admin|wp-login.php)#"
Cabeçalho ETag não definido# Nginx
localização ~* .(jpg|jpeg|png|gif|ico|webp|avif|css|js|woff2?)$ {
add_header Cache-Control "public, max-age=31536000";
}
localização ~* /(wp-admin|wp-login.php)$ {
add_header Cache-Control "no-store";
}
Diretivas de controlo de cache alargadas na vida quotidiana
Para além de „max-age“ e „no-store“, as diretivas modernas garantem uma estabilidade notável. „immutable“ indica ao navegador que um ficheiro não será alterado enquanto o nome do ficheiro permanecer o mesmo - ideal para activos com versões. „stale-while-revalidate“ permite que uma cópia expirada seja entregue enquanto é actualizada em segundo plano. „stale-if-error“ mantém uma cópia pronta se a Origem devolver brevemente erros. „s-maxage“ destina-se a proxies/CDNs e pode ter valores diferentes de „max-age“. Também importante: „public“ permite o armazenamento em cache em proxies partilhados; „private“ é restrito ao browser. „no-cache“ não significa „não armazenar em cache“, mas sim „é permitido armazenar em cache, mas revalidar antes de utilizar“ - uma diferença crucial em relação a „no-store“.
# Exemplo do Apache 2.4 (cache de activos ainda mais robusto)
Header set Cache-Control "public, max-age=31536000, immutable, stale-while-revalidate=86400, stale-if-error=259200" "expr=%{REQUEST_URI} =~ m#.(css|js|woff2?|png|jpe?g|webp|avif)$#"
Header set Cache-Control "no-cache, must-revalidate" "expr=%{CONTENT_TYPE} =~ m#^text/html#"# Exemplo Nginx (redireccionamentos 304/Include)
location ~* .(css|js|woff2?|png|jpe?g|webp|avif)$ {
add_header Cache-Control "public, max-age=31536000, immutable, stale-while-revalidate=86400, stale-if-error=259200" always;
}
localização ~* .html$ {
add_header Cache-Control "no-cache, must-revalidate" always;
}Durações de cache recomendadas por tipo de ficheiro
Escolho os horários de acordo com a frequência das mudanças, não com o hábito, porque Activos envelhecem de forma muito diferente. As imagens, os logótipos e os ícones mantêm-se normalmente actualizados durante muito tempo, enquanto as CSS/JS recebem iterações mais frequentes. Os tipos de letra da Web raramente mudam, mas exigem cabeçalhos CORS consistentes. O HTML serve frequentemente de contentor para conteúdos dinâmicos e pode, por isso, ser curto ou apenas revalidado. As APIs devem ter regras claramente definidas para que os clientes possam trabalhar corretamente com JSON evitar.
| Tipo de ficheiro | Recomendação de controlo da cache | Nota |
|---|---|---|
| Imagens (jpg/png/webp/avif/svg) | public, max-age=31536000 | Utilizar a cache anual com o controlo de versões de ficheiros |
| CSS/JS | público, max-age=2592000 | Anexar a versão ao nome do ficheiro para actualizações |
| Tipos de letra (woff/woff2) | public, max-age=31536000 | Definir corretamente Access-Control-Allow-Origin |
| HTML (páginas) | no-cache, must-revalidate ou short max-age | Muito cuidado com os conteúdos dinâmicos |
| API REST (json) | private, max-age=0, must-revalidate | Diferenciar de acordo com o parâmetro |
Evitar conflitos com plugins
Utilizo no máximo Plugin de cache e verificar se o alojamento já especifica regras a nível do servidor. Combinações como o W3 Total Cache e o WP Super Cache criam frequentemente diretivas duplicadas que se anulam mutuamente. O WP Rocket oferece uma configuração rápida, mas precisa de exclusões claras para caminhos dinâmicos e comércio eletrónico. Em qualquer caso, verifico o .htaccess gerado depois de o guardar para reconhecer cabeçalhos ilógicos. Em seguida, testo páginas críticas, como checkout, login e painéis personalizados, para verificar se estão corretas Contornar.
Caching e cookies: utilizadores com sessão iniciada, WooCommerce, sessões
O HTML para utilizadores com sessão iniciada não deve ser armazenado na cache pública. O WordPress define cookies como wordpress_logged_in_, WooCommerce complementado woocommerce_items_in_cart, wp_woocommerce_session_ e outros. Em vez do excesso de Vary: Cookie Ignoro completamente as caches para estes pedidos. Isto mantém os processos de checkout estáveis e as áreas personalizadas corretas. Também utilizo regras do lado do servidor que definem cabeçalhos mais restritivos quando os cookies são reconhecidos.
# Apache: Reconhecendo cookies e definindo cabeçalhos de desvio
SetEnvIfNoCase Cookie "wordpress_logged_in_|woocommerce_items_in_cart|wp_woocommerce_session" has_session
Header set Cache-Control "private, no-store" env=has_session# Nginx: desvio baseado em cookies
if ($http_cookie ~* "(wordpress_logged_in|woocommerce_items_in_cart|wp_woocommerce_session)") {
add_header Cache-Control "private, no-store" always;
}Muitos plug-ins de cache oferecem caixas de seleção para isso (WooCommerce/Cart/Excluir checkout). Importante: Nonces (_wpnonce) nos formulários e a API Heartbeat geram alterações frequentes. Certifico-me de que o HTML de frontend com nonces não é permanentemente armazenado em cache ou funciona através de „no-cache, must-revalidate“.
Tratamento direcionado da HTML: personalizado vs. geral
Nem todas as páginas são iguais. Os artigos, as páginas de destino e as páginas jurídicas podem frequentemente ser armazenados em cache com um TTL curto ou revalidação. Os arquivos, as páginas de pesquisa, os painéis de controlo, as áreas de conta e os checkouts permanecem dinâmicos. Se estiver em causa o armazenamento de páginas em cache, sigo a seguinte prática: apenas armazenar em cache HTML público sem cookies, caso contrário „privado“ ou „no-store“. Se estiver a testar a micro-caching (por exemplo, 30-60 segundos para páginas muito frequentadas e não personalizadas), deve definir exclusões rigorosas para parâmetros de consulta e sessões. O WordPress tem com DONOTCACHEPAGE uma constante que os modelos podem definir em páginas complicadas - utilizo-o sistematicamente para evitar erros.
Combinar o armazenamento em cache do lado do servidor de forma sensata
A cache do browser termina no cliente, mas também alivio o servidor com a cache de páginas, objectos e códigos de operação para Picos de carga. O cache de páginas fornece HTML estático antes mesmo de o PHP começar. O Redis ou o Memcached reduzem as consultas à base de dados para pedidos repetidos e reduzem visivelmente o TTFB. O OPcache fornece fragmentos de bytecode PHP pré-compilados, reduzindo assim o tempo de execução. No final, o que conta é uma ligação limpa entre a cache do servidor e a cache do browser, para que a segunda visita seja mais ou menos um sucesso. instantâneo obras.
Integração de CDN sem surpresas
As CDNs utilizam a sua própria lógica TTL e respondem a „s-maxage“. Por conseguinte, faço uma distinção clara: „max-age“ para os navegadores, „s-maxage“ para o Edge. Se as implantações estiverem pendentes, eu aciono uma purga direcionada em vez de destruir globalmente o „Cache Everything“. Importante: Apenas armazenar HTML em cache no Edge se não houver cookies envolvidos. Caso contrário, são criados estados incorrectos porque a cache do Edge partilha respostas personalizadas. Para ativos, defino TTLs longos e confio na versão do nome do arquivo. As CDNs podem ignorar strings de consulta - outra razão para manter as versões no nome do ficheiro. A normalização do cabeçalho (sem valores „Vary“ supérfluos, „Content-Type“ consistente) evita chaves de cache inchadas.
Passo-a-passo: instalação limpa
Começo com um plugin e ativo a cache do navegador para CSS, JS, imagens e tipos de letra antes de ativar o .htaccess finalizar. Em seguida, defino um max-age elevado para os activos estáticos e forneço HTML com tempos curtos ou regras no-cache. Desactivo os ETags se estiverem envolvidos vários servidores e confio no Last-Modified plus 304. Depois, desencadeio um pré-carregamento para que as páginas importantes estejam imediatamente disponíveis como cópias estáticas. Por fim, verifico os caminhos da loja, de início de sessão e de administração para que nenhum conteúdo privado seja armazenado no memória temporária terra.
Diagnóstico prático com CLI e verificações de cabeçalho
As DevTools são obrigatórias, mas eu aprofundo os testes CLI. A curl -I mostra o cabeçalho sem descarregamento; com -H Simulo condições. Por exemplo, verifico se as revalidações devolvem realmente 304, se a „Idade“ aumenta a partir de um proxy/CDN e se os cookies desactivam o caching.
# Mostrar cabeçalho
curl -I https://example.com/style.css
Simular a revalidação do # (If-Modified-Since)
curl -I -H "If-Modified-Since: Tue, 10 Jan 2023 10:00:00 GMT" https://example.com/style.css
Teste # com cookie (deve forçar o bypass)
curl -I -H "Cookie: wordpress_logged_in_=1" https://example.com/Certifico-me de que os activos têm um valor longo de „controlo de cache“, idealmente „imutável“. O HTML deve ter „no-cache“ ou um TTL curto. Se ainda recebo 200 em vez de 304, muitas vezes há redireccionamentos em jogo que invalidam ETags/Last-Modified. Além disso, „add_header“ no Nginx só se aplica a respostas 200 por padrão - com „always“ eu também defino os cabeçalhos para 304 e 301/302.
Teste e validação de cabeçalhos
Abro o DevTools, recarrego a página uma vez, limpo a cache e recarrego para obter 304 vs. 200 para observar. No painel de rede, verifico o controlo da cache, a idade, o ETag/load-modified e os tamanhos das respostas. Se ainda houver acessos diretos em vez de revalidações, verifico se há conflitos com redireccionamentos, cookies ou cadeias de consulta. Para os casos mais complicados, este artigo sobre as armadilhas dos cabeçalhos ajuda-me: Cabeçalho da cache de sabotagem. Repito a verificação após cada atualização de plug-in porque as alterações às regras são frequentemente feitas silenciosamente. passar.
Controlo de versões, CDN e eliminação de cache
Eu penduro o Versão aos nomes dos ficheiros (style.23.css em vez de style.css?ver=23) para que os navegadores mantenham longas caches e continuem a carregar novos conteúdos imediatamente. Uma CDN distribui ficheiros estáticos globalmente, define os seus próprios TTLs em PoPs de ponta e reduz drasticamente os RTTs. Importante: só armazenar HTML em cache na CDN se não for necessária personalização, caso contrário, serão criados estados incorrectos. Durante a implementação, altero o número da versão automaticamente para que os utilizadores nunca fiquem presos a scripts antigos. É assim que eu combino os TTLs rígidos do navegador com a segurança Quebra de cache.
Limpar o controle de versão em compilações do WordPress
O mais fiável é um pipeline de construção que escreve hashes em nomes de ficheiros (por exemplo. app.9f3c.css). O WordPress carrega então exatamente este ficheiro - os navegadores podem mantê-lo durante um ano graças ao „imutável“. Como alternativa, se os nomes dos ficheiros não puderem ser alterados, defino o número da versão dinamicamente a partir da data do ficheiro. Isto mantém as cadeias de consulta corretas e fiáveis.
// functions.php (versão de recurso via filemtime)
add_action('wp_enqueue_scripts', function () {
$css = get_stylesheet_directory() . '/dist/style.css';
$ver = file_exists($css) ? filemtime($css) : null;
wp_enqueue_style('theme', get_stylesheet_directory_uri() . '/dist/style.css', [], $ver);
});Importante: Se o nome do ficheiro contiver versões, pode ser definido „imutável“. Se utilizar apenas cadeias de consulta, os navegadores devem ser capazes de revalidar para que as actualizações cheguem de forma fiável. Também me certifico de que as ferramentas de compilação limpam os ficheiros antigos para que as CDNs não armazenem um número desnecessariamente grande de variantes.
Guardar em cache e carregar corretamente as fontes da Web
As fontes Web precisam de TTLs longos, cabeçalhos CORS corretos e pré-carregamento opcional para que Saltos de layout não aparecem. Coloco os ficheiros woff2 no mesmo domínio ou defino Access-Control-Allow-Origin de forma limpa. Além disso, defina font-display: swap para que o texto permaneça visível imediatamente enquanto o tipo de letra está a carregar. Se quiser otimizar o tempo de carregamento dos seus tipos de letra, encontrará dicas úteis aqui: Carregar fontes da Web mais rapidamente. Com cabeçalhos de cache limpos e uma pré-conexão a CDNs, encurto visivelmente o FOUT/FOIT e asseguro uma Renderização-Resultados.
Ajustar corretamente os tipos de letra, CORS e Vary
As fontes de outra origem requerem CORS. Eu defino Controlo de acesso - Permitir origem (por exemplo, para o seu próprio domínio ou „*“ para verdadeiramente público) e evitar uma Variar: Origem, que inflaciona as chaves da cache. Recomendado para fontes: público, max-age=31536000, imutável. O pré-carregamento melhora o First Paint, mas não altera o TTL - o pré-carregamento e o hard caching complementam-se. Também não estou a esquecer que a entrega comprimida (br/gzip) a Vary: Aceitar-Codificação é necessário para que os proxies se separem corretamente.
Padrões de erro típicos e soluções rápidas
Se aparecer um código antigo após uma atualização, o Versionamento no nome do ficheiro. Se o navegador recarregar completamente todas as vezes, os cabeçalhos definem instruções contraditórias ou os proxies removem-nas no caminho. Se um checkout for cancelado, o site está provavelmente a armazenar em cache páginas do lado da sessão ou respostas da API. Se os caminhos de administração entrarem na cache, as exclusões para wp-admin e login estão em falta ou um plugin está a armazenar em cache globalmente. Resolvo isto desactivando passo a passo, consolidando cabeçalhos, excluindo caminhos críticos e, finalmente, o efeito com o estado 304 confirmar.
Pormenores frequentemente negligenciados que fazem uma grande diferença
- Nginx add_header não se aplica a 304/redirects sem „always“ - os cabeçalhos da cache ficam então em falta para as validações. Eu defino sempre „always“.
- Expirações vs. controlo da cache: „O “Cache-Control„ tem prioridade, o “Expires" serve de alternativa para clientes antigos. Evitar informações duplicadas e contraditórias.
- ETag em configurações multi-servidor: ETags inconsistentes destroem 304. Desactivo ETags ou utilizo validadores fracos e confio em „Last-Modified“.
- Variar ao mínimo: „O “Vary: Accept-Encoding„ é obrigatório para a compressão, o “Vary: Cookie" incha as caches de borda - é melhor contornar o cookie.
- SVG e tipo MIME: Correto
imagem/svg+xmldefinir, dar um TTL longo e considerar SVGs em linha para ícones críticos. - Evitar cadeias de redireccionamento: Cada 301/302 pode perder validadores e forçar 200 - URLs limpos sem cascatas.
- Utilizar a prioridade/precarregamento de forma direcionada:
fetchpriority="high"ou pré-carregamento para activos críticos acelera a primeira chamada; o armazenamento em cache é eficaz para os utilizadores que regressam. - Diferenciar REST-API: Os JSON públicos, que raramente mudam, podem ser armazenados em cache por um breve período; os pontos finais com tokens/cookies são estritamente „privados“.
Brevemente resumido
Eu confio na clareza RegrasTTLs longos para activos, respostas HTML curtas ou revalidadas, controlo de versões e um único plugin de cache. Depois, combino a cache do browser com a cache de páginas, objectos e códigos de operação para reduzir a carga do servidor. Verifico o DevTools, procuro o 304, verifico os cabeçalhos e elimino conflitos com redireccionamentos ou cookies. Para o teste prático, comparo as medições na primeira chamada e nas chamadas repetidas e concentro-me nas melhorias visíveis. Se seguir estes passos, pode levar o WordPress a um nível fiável de cache do navegador. Velocidade e mantém os utilizadores e os motores de busca satisfeitos.
