Browser caching WordPress: corrigir o aviso

Tipo Performance & Velocidade

Nome do erro Aviso de cache do navegador no WordPress EN: WordPress leverage browser caching warning

Severidade Atenção

Descrição O aviso de browser caching no WordPress aparece quando os arquivos estáticos do site são servidos sem cabeçalho de validade (expires), forcando o navegador a baixar tudo de novo a cada visita. A correção e definir expires headers no servidor.

O que é o aviso de browser caching WordPress?

Browser caching e a instrucao que diz ao navegador por quanto tempo guardar localmente arquivos estáticos do site (imagens, CSS, JavaScript e fontes), evitando baixa-los de novo a cada página. Quando esses arquivos saem do servidor sem o cabeçalho de validade, ferramentas como GTmetrix, PageSpeed Insights e Lighthouse disparam o aviso ‘Serve static assets with an efficient cache policy’ (antigo ‘Leverage browser caching’). No WordPress com Apache ou LiteSpeed, o WP Rocket grava esses cabeçalhos automaticamente no .htaccess via mod_expires e mod_headers; em Nginx a regra precisa ser adicionada no bloco do servidor manualmente, porque o .htaccess não e lido.

Como identificar

GTmetrix ou PageSpeed Insights aponta ‘Serve static assets with an efficient cache policy’ (antes chamado ‘Leverage browser caching’) listando seus próprios CSS, JS e imagens
No relatório, a coluna de cache (Cache TTL / Expiry) aparece como ‘None’, ‘0s’ ou ‘No expiration set’ nos arquivos do seu domínio
A nota de performance sobe na primeira visita mas as visitas repetidas continuam lentas, sem reaproveitar arquivos do cache local
Nas DevTools do navegador, aba Network, a coluna Size mostra o tamanho real do arquivo em vez de ‘(disk cache)’ ao recarregar a página
Após ativar o WP Rocket o aviso some para os arquivos do site, mas permanece para scripts externos como Google Analytics, Google Fonts e Facebook pixel

Antes de começar: Faca uma copia do .htaccess antes de editar. Uma diretiva mal fechada nesse arquivo derruba o site inteiro com erro 500, e basta restaurar a copia para voltar ao ar.

Como prevenir

Mantenha o WP Rocket ativo: ele regrava os Expires headers no .htaccess sempre que e atualizado ou reconfigurado
Depois de instalar plugins de segurança que mexem no .htaccess, confira se o bloco entre os marcadores do WP Rocket continua presente
Em sites Nginx, deixe a regra de cache de estáticos versionada na configuração do servidor para não se perder em migracoes de hospedagem
Hospede localmente Google Fonts e scripts de analytics quando possível, para que herdem o cache longo do seu próprio servidor

Causa

O servidor não envia cabeçalho Expires nem Cache-Control max-age para arquivos estáticos, entao o navegador trata cada CSS, JS e imagem como sempre vencido e baixa de novo.
O site roda em Nginx, onde o WP Rocket não consegue gravar as regras de cache, porque o Nginx ignora o arquivo .htaccess e exige diretivas no bloco server.
O módulo mod_expires ou mod_headers do Apache esta desativado, fazendo o bloco que o WP Rocket escreve no .htaccess não ter efeito.
Um plugin de segurança ou o painel da hospedagem sobrescreve o .htaccess depois do WP Rocket, removendo o bloco de Expires headers gravado entre os marcadores BEGIN WP Rocket e END WP Rocket.
O aviso vem de recursos de terceiros (Google Analytics, Google Tag Manager, Google Fonts, Facebook pixel) servidos do domínio deles com validade curta, fora do alcance do cache do seu servidor.

Como resolver

Confirme quais arquivos disparam o aviso: Rode o site no PageSpeed Insights ou GTmetrix e abra a auditoria de cache. Separe os arquivos do seu próprio domínio (que você controla) dos de terceiros (Google, Facebook), porque so os primeiros são corrigidos no servidor.
Ative o cache no WP Rocket (Apache ou LiteSpeed): Basta ter o WP Rocket ativo. Ele grava as regras de Expires headers e Cache-Control no .htaccess automaticamente, definindo validade de 1 ano para CSS e JavaScript, 4 meses para imagens e fontes, 1 hora para feeds e 0 segundo para HTML.
Verifique se o bloco foi gravado no .htaccess: Abra o arquivo .htaccess na raiz do site por FTP ou gerenciador de arquivos e confirme que o bloco de Expires headers existe entre os marcadores BEGIN WP Rocket e END WP Rocket. Se você mantiver o site no Apache sem plugin de cache, adicione o bloco de Expires headers do exemplo de código desta página acima da regra principal do WordPress.
```
BEGIN WP Rocket
END WP Rocket
```
Confirme que mod_expires e mod_headers estão ativos no Apache: Se o bloco esta no .htaccess mas o aviso continua, o módulo do Apache pode estar desligado. Em servidores com acesso ao terminal, habilite os módulos e reinicie o Apache.
```
sudo a2enmod expires headers
sudo systemctl restart apache2
```
Adicione a regra no bloco server se o site rodar em Nginx: No Nginx o .htaccess não e lido, entao o WP Rocket não corrige sozinho. Peca a hospedagem ou edite a configuração do site para incluir a diretiva de validade dos arquivos estáticos e recarregue o Nginx.
```
location ~* .(css|js|png|jpg|jpeg|webp|woff2|svg)$ {
    expires 4M;
    add_header Cache-Control "public";
}
sudo nginx -t
sudo systemctl reload nginx
```
Limpe o cache e teste de novo: Limpe o cache do WP Rocket e do CDN, recarregue o site sem cache do navegador e rode o teste novamente. O aviso deve sumir para todos os arquivos do seu domínio. Os scripts de terceiros tendem a permanecer e não prejudicam o ranqueamento.

APACHE

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/html "access plus 0 seconds"
    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"
    ExpiresByType image/jpeg "access plus 4 months"
    ExpiresByType image/png "access plus 4 months"
    ExpiresByType image/webp "access plus 4 months"
    ExpiresByType image/svg+xml "access plus 4 months"
    ExpiresByType font/woff2 "access plus 4 months"
    ExpiresByType application/rss+xml "access plus 1 hour"
    ExpiresDefault "access plus 1 month"
</IfModule>
<IfModule mod_headers.c>
    Header unset Pragma
    Header append Cache-Control "public"
</IfModule>

Perguntas frequentes

O que significa o aviso leverage browser caching no WordPress?

Significa que arquivos estáticos do site (CSS, JS, imagens e fontes) estão sendo servidos sem um cabeçalho de validade, entao o navegador baixa tudo de novo a cada visita. Definir expires headers no servidor resolve e melhora as visitas repetidas.

O WP Rocket corrige o browser caching sozinho?

Sim, em servidores Apache e LiteSpeed. Ao ativar, o WP Rocket grava as regras de Expires e Cache-Control no .htaccess automaticamente. Em Nginx, a regra precisa ser adicionada no bloco do servidor manualmente, porque o .htaccess não e lido.

Por que o aviso continua mesmo com o WP Rocket ativo?

Em geral por dois motivos: o site roda em Nginx (onde o .htaccess não vale) ou o aviso aponta scripts de terceiros como Google Analytics, Google Fonts e Facebook pixel, servidos do domínio deles com validade curta e fora do alcance do seu servidor.

Quanto tempo de cache cada tipo de arquivo deve ter?

O padrão do WP Rocket e 1 ano para CSS e JavaScript, 4 meses para imagens, fontes e mídia, 1 semana para favicon, 1 hora para feeds e 0 segundo para o HTML, que precisa refletir mudancas de conteúdo na hora.

Preciso editar o .htaccess na mao?

Não, se o WP Rocket estiver ativo em Apache ou LiteSpeed. A edição manual so e necessaria quando você não usa um plugin de cache, quando os módulos mod_expires e mod_headers estão desativados ou quando o servidor e Nginx.

O aviso de scripts de terceiros prejudica meu ranqueamento?

Quase nada. Como Google Analytics e Facebook pixel são servidos pelos próprios fornecedores com validade curta, você não controla esse cache. Hospedar fontes e scripts localmente reduz o número de avisos, mas o impacto residual no SEO e mínimo.

Como confirmo que o cache do navegador foi aplicado?

Abra as DevTools do navegador, va na aba Network e recarregue a página. Os arquivos estáticos devem mostrar '(disk cache)' na coluna Size. Outra forma e rodar o teste no PageSpeed Insights e ver se o aviso sumiu para os arquivos do seu domínio.

Atenção

Como corrigir o cache do WP Rocket que quebra listings do JetEngine no WordPress

O cache do WP Rocket que quebra listings do JetEngine acontece quando otimizacoes como Delay JavaScript Execution, Remove Unused CSS e o cache de página servem uma versão estática que não executa o JavaScript ou não carrega o CSS de que o Listing Grid e o JetSmartFilters precisam para renderizar conteúdo dinâmico.

Atenção

Como corrigir o cache do WP-Optimize em páginas de curso do Tutor LMS

O cache do WP-Optimize em páginas de curso do Tutor LMS quebra quando o cache de página estático é servido a alunos logados: a versão deslogada congelada esconde o conteúdo liberado, o progresso e os botões de matrícula, porque o WP-Optimize entrega o mesmo arquivo HTML para todos sem o cache por usuário ativado.

Atenção

Como corrigir o erro de preload no WP Rocket no WordPress

O preload do WP Rocket não funciona quando o WP-Cron não roda, quando o sitemap esta vazio ou inacessivel, quando a extensão SimpleXML do PHP esta desativada ou quando o site não consegue completar uma requisicao de loopback, impedindo o robo de pre-carregar o cache.

Informativo

Como corrigir o lazy load de vídeos do YouTube no WP Rocket

O lazy load de vídeos do YouTube no WP Rocket adia o carregamento dos iframes e troca o embed por uma miniatura; ele falha quando o tema usa CSS de proporção no container, quando o plugin Complianz bloqueia o iframe ou quando o vídeo está num bloco que o WP Rocket não processa.

Atenção

Como corrigir o editor lento pelo Heartbeat Control do Perfmatters no WordPress

O Heartbeat Control do Perfmatters deixa o editor lento quando a frequencia do Heartbeat e alongada demais ou o Heartbeat e bloqueado dentro do editor de posts, atrasando o autosave, o bloqueio de post e as atualizações em tempo real do WordPress.

Atenção

Como corrigir o erro de permissão ao limpar o banco no WP-Optimize

O erro de permissão no banco do WP-Optimize trava a limpeza quando o usuário MySQL definido no wp-config.php não tem o privilégio que o comando OPTIMIZE TABLE exige para recriar a tabela. O plugin marca cada otimização como falha e o overhead não cai. A correção é conceder o GRANT correto ao usuário do banco.

Setores

Extensões

Integrações

Como corrigir o aviso de cache do navegador no WordPress

O que é o aviso de browser caching WordPress?

Como identificar

Como prevenir

Causa

Como resolver

Perguntas frequentes

Itens relacionados

Como corrigir o cache do WP Rocket que quebra listings do JetEngine no WordPress

Como corrigir o cache do WP-Optimize em páginas de curso do Tutor LMS

Como corrigir o erro de preload no WP Rocket no WordPress

Como corrigir o lazy load de vídeos do YouTube no WP Rocket

Como corrigir o editor lento pelo Heartbeat Control do Perfmatters no WordPress

Como corrigir o erro de permissão ao limpar o banco no WP-Optimize

Setores

Extensões

Integrações

Extensões

Hero Sections

Seções de CTA

Login

Blog

Cabeçalhos

Seções de FAQ

Cadastro

Blog individual

Rodapés

Seções de contato

Seções de preços

Faixas

Portfólio

Seções de equipe

Números

Logotipos