Resolve uma parte: o tempo que o servidor leva para montar a página. O plugin de cache não reduz imagem pesada nem JavaScript em excesso, e não acelera carrinho, checkout ou área logada, que ficam fora do cache. Se o site continua lento com o cache ativo, o gargalo está em outra camada.
Para quem vende pelo site, a diferença pesa. O teste de velocidade fica verde depois do plugin, e o cliente que chega ao pagamento pelo celular continua esperando. A página que fecha a venda é justamente a que o cache não alcança.
O que o cache de página faz
Toda vez que alguém abre uma página do WordPress, o servidor executa código PHP, consulta o banco de dados e monta o HTML, que é o texto que o navegador transforma em página. O cache de página guarda esse HTML pronto. O visitante seguinte recebe a cópia e o servidor não repete o trabalho.
O ganho aparece no TTFB (time to first byte), o tempo entre o pedido do navegador e a chegada do primeiro pedaço da resposta. A documentação da web.dev sobre TTFB trata como bom um valor de até 0,8 segundo e como ruim acima de 1,8 segundo, e avisa que essa faixa é só uma referência. O TTFB não é um dos Core Web Vitals, as três métricas de experiência que o Google acompanha. Ele importa porque tudo o que vem depois começa atrasado.
Quando faço o diagnóstico de um site WordPress lento, separo servidor, imagens, JavaScript, banco de dados e cache em camadas. O cache de página atua na primeira. Imagem, fonte, script e o trabalho do navegador continuam do mesmo tamanho.
O que fica fora do cache
- Conteúdo personalizado, como área de cliente e páginas de quem está logado. A web.dev lembra que esse tipo de conteúdo não é adequado para cache compartilhado.
- Carrinho, checkout e Minha Conta em lojas WooCommerce.
- Páginas pouco visitadas ou cuja cópia expirou. Quem chega primeiro espera o tempo cheio.
- Tudo o que acontece no navegador depois que o HTML chega.
Como saber se o seu site já tem cache
O próprio WordPress verifica. Desde a versão 6.1, a tela Ferramentas > Saúde do site tem um teste de cache de página que mede o tempo de resposta do servidor e compara com um limite de 600 milissegundos, segundo a nota da equipe de performance do WordPress. O teste só roda em produção.
O código do teste procura um plugin de cache ativo e faz três acessos à página inicial atrás de cabeçalhos de cache. O resultado cai em um de quatro cenários, e dois deles decidem a compra de um plugin:
- Cache não detectado e resposta lenta: falta cache, e ativar é o primeiro passo.
- Cache detectado e resposta ainda lenta: o servidor, o banco ou os plugins estão segurando a página. Outro plugin de cache não muda isso.
Os 600 ms do WordPress e os 0,8 s da web.dev medem coisas diferentes. O primeiro olha só a resposta do servidor. O TTFB que o visitante sente inclui também a busca do endereço (DNS) e os redirecionamentos, que o teste de laboratório deixa de fora.
O teste que mostra se o cache está escondendo o problema
A web.dev faz um alerta que vale para qualquer plataforma: o cache pode mascarar um servidor lento, porque testar uma página que já está em cache quase nunca mostra problema. A recomendação é ter uma forma de pular o cache, como um parâmetro na URL, e medir as duas versões.
Um exemplo hipotético deixa a leitura clara. A página inicial servida do cache responde em 0,2 s. A mesma página com “?nocache=1” no fim do endereço, montada do zero, responde em 2,4 s. O cache está funcionando, e o custo real de 2,4 s continua lá. Quem paga esse custo é o visitante logado, o cliente no checkout e todo mundo que cai numa página fora do cache.
O parâmetro exato depende de como o cache foi configurado. Em alguns ambientes qualquer parâmetro desconhecido já força uma nova montagem; em outros é preciso uma regra específica.
Cache ligado e site ainda lento: qual métrica está reprovando?
Antes de trocar de plugin, descubra qual métrica falha nos dados de usuários reais do PageSpeed Insights. Cada uma aponta para uma camada diferente.
| Métrica | O que mede | Ruim com cache ativo, olhe para |
|---|---|---|
| TTFB | Espera até o servidor começar a responder | Hospedagem, banco de dados, plugins pesados |
| LCP | Tempo até o maior elemento visível aparecer | Imagem principal grande ou sem prioridade, CSS e JavaScript bloqueando a pintura |
| INP | Tempo de resposta a um toque ou clique | JavaScript em excesso, scripts de terceiros, page builder |
| CLS | Quanto o layout pula durante a carga | Imagens sem dimensão declarada, banners que empurram o conteúdo |
O INP é o caso mais claro de que cache não ajuda. Segundo a lista de prioridades da web.dev, qualquer tarefa do navegador acima de 50 ms vira uma tarefa longa e pode travar a resposta ao toque. Esse trabalho acontece no aparelho do visitante, depois que o HTML já chegou.
No WordPress, a camada que mais reprova é a de carregamento. No capítulo de CMS do Web Almanac 2025, 45% dos sites WordPress no celular passaram nas três métricas, e só 53% tinham LCP bom, contra cerca de 84% com CLS bom. O estudo atribui a diferença entre um WordPress e outro mais à configuração do que ao núcleo da plataforma. São dados globais e mostram associação, não causa.
Um caso publicado pela DebugBear mostra a ordem dos ganhos. Num WordPress com o tema Divi, o Saúde do site acusava ausência de cache. Com cache de página, de objeto e de navegador ligados, o TTFB caiu para 415 ms e a nota de performance no desktop foi de 61 para 73. O salto maior veio depois: redimensionar as imagens e dar prioridade à imagem principal levou o LCP no celular de 12 s para 1,8 s. É um único site, medido em laboratório. Ainda assim, ilustra bem o efeito do cache: ele tirou a espera do servidor da frente e deixou à mostra o problema seguinte.
Em loja virtual, as páginas que vendem ficam fora do cache
A documentação do WooCommerce manda excluir do cache o Carrinho, o Checkout e a Minha Conta, porque essas páginas mostram dados de cada cliente. Ela também lista os cookies de sessão, como os que registram o conteúdo do carrinho, que precisam desviar do cache.
A consequência comercial é direta. Depois que o cliente coloca um produto no carrinho, ele sai da parte rápida do site. Frete, cupom e pagamento são calculados pelo servidor a cada passo. Se o servidor é lento, o plugin de cache não ajuda no momento em que o cliente decide se paga.
A mesma documentação traz dois alertas sobre configurações agressivas. Recomenda evitar a minificação de JavaScript no WP Rocket e explica que, se a página Minha Conta entrar no cache, a troca de senha pode virar um ciclo que devolve o cliente à tela de login. Por isso cada opção de otimização do plugin passa por teste em homologação, nas funções que geram receita, antes de ir para produção. É o mesmo processo que sigo para atualizar um WordPress com backup e caminho de volta.
Quando vale pagar por um plugin de cache premium
Minha posição: se o site não tem cache de página, ativar é o primeiro passo, porque custa pouco e ataca o TTFB direto. Antes de comprar qualquer plugin, verifico duas coisas. Se a hospedagem já faz cache no servidor, e qual métrica está reprovando com usuários reais. Sem essas duas respostas, a compra é um palpite.
O plugin certo depende do servidor. O LiteSpeed Cache, por exemplo, só faz cache de página quando o site roda num servidor LiteSpeed ou passa pela CDN QUIC.cloud. Em Apache ou Nginx sobram as funções de otimização, como minificação e compressão de imagens. O plugin dá as ordens ao cache do servidor; sem esse servidor, a função principal dele não existe.
O que eu uso
Quando o site está na Hostinger, prefiro um plano que inclua cache de objetos, uma memória que guarda o resultado de consultas ao banco de dados, e uso o LiteSpeed Cache como plugin. O cache de objetos ajuda onde o cache de página não chega: área logada, carrinho, painel.
Em todos os projetos coloco o Cloudflare na frente do site. Uso pelo cache na borda (servidores espalhados que entregam arquivos perto do visitante), pela segurança de esconder o IP do servidor e por ferramentas como o AI Crawl Control, que mostra quais robôs de IA acessam o site e permite liberar ou bloquear cada um.
Um detalhe que costuma passar despercebido: pela configuração padrão do Cloudflare, o HTML das páginas não é guardado, só arquivos como imagens, CSS e JavaScript. Para o HTML ir para a borda é preciso criar uma regra de cache. Mesmo assim, o Cloudflare não armazena respostas que gravam cookie, o que mantém carrinho e área logada indo até o servidor.
Quando o cache sozinho basta
Num site institucional pequeno, em hospedagem com recursos suficientes, sem login e sem loja, o cache de página pode resolver quase tudo o que o servidor atrasava. Se depois dele os dados de campo mostram LCP, INP e CLS na faixa boa, um diagnóstico profundo custa mais do que entrega.
O plugin premium também perde sentido quando a hospedagem já faz o cache no servidor. Nesse cenário, o que sobra para ele são as funções de otimização de arquivos e imagens, que plugins gratuitos como o próprio LiteSpeed Cache também oferecem.
Depois de qualquer ajuste, o teste de laboratório responde no mesmo dia. Os dados de usuários reais do Google usam uma janela de 28 dias, então a confirmação de que o site melhorou para quem compra leva cerca de um mês.
Perguntas frequentes sobre cache do WordPress
Não na configuração padrão. O Cloudflare guarda imagens, CSS e JavaScript, mas não guarda o HTML das páginas sem uma regra de cache criada no painel. Mesmo com a regra, respostas que gravam cookie, como carrinho e área logada, continuam indo até o servidor. Por isso o cache no servidor ou no plugin segue necessário para acelerar a montagem da página.
No Chrome, abra as ferramentas de desenvolvedor (F12), vá na aba Rede, recarregue a página e clique no primeiro item da lista. Nos cabeçalhos da resposta, procure indicações de cache. Com Cloudflare, o cabeçalho cf-cache-status com o valor HIT indica que a página saiu do cache da borda. A tela Saúde do site do WordPress também faz essa verificação.
Pode ajudar de forma indireta. O cache reduz o TTFB, que atrasa o LCP, uma das métricas de experiência que o Google usa. Mas essas métricas pesam menos que relevância e autoridade do conteúdo. O ganho comercial mais direto costuma vir da experiência: página que abre rápido perde menos visitante antes do contato ou da compra.
Na maioria das configurações, não. Plugins como o LiteSpeed Cache limpam automaticamente as páginas relacionadas quando um conteúdo é publicado ou alterado. Limpar à mão faz sentido depois de mudanças no tema, no menu ou em configurações que afetam muitas páginas. Se usar cache de HTML no Cloudflare, confirme que a limpeza lá também acontece, senão o visitante pode ver a versão antiga.