Você abre o site e ele demora. O painel demora. O cliente reclama. A primeira reação é instalar um plugin de cache. Só que, muitas vezes, o site WordPress lento continua lento depois do cache, porque o gargalo não estava no processamento da página, e sim em outro lugar. Este artigo mostra como achar o gargalo antes de instalar cache, com um teste de isolamento por etapas.
Um site WordPress lento: os sintomas que indicam onde está o problema
Nem toda lentidão é igual. O jeito como o site demora já dá pistas do que está travando. Antes de mexer em qualquer coisa, observe o comportamento em três situações: navegação anônima, painel administrativo e resposta do servidor.
- Site lento para todo mundo, inclusive para quem nunca acessou: provavelmente é hospedagem ou processamento no servidor.
- Site rápido para visitante, lento só no painel: plugin pesado, consulta ao banco ou cron do WordPress travando.
- Primeira visita lenta, segunda rápida: aí sim o cache pode ajudar, porque o conteúdo já está pronto.
- Site rápido em uma página e lento em outra: o problema está naquela página específica, não no site inteiro.
Essa primeira leitura evita a armadilha mais comum: instalar cache para um problema que cache não resolve. Além disso, ela já reduz o campo de investigação.
Meça o TTFB antes de qualquer coisa
O número mais útil para separar problema de servidor de problema de front-end é o TTFB (Time To First Byte), que mede quanto tempo o servidor leva para começar a responder. Se o TTFB está alto, o gargalo é no back-end. Se está baixo e o site ainda demora, o problema está no que o navegador precisa baixar e executar.
Você pode medir de três formas:
- Ferramentas de teste online: PageSpeed Insights, WebPageTest ou GTmetrix mostram o TTFB separado do tempo total. Use sempre uma URL real do site, não a home.
- Linha de comando: se você tem acesso a terminal,
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://seusite.comdevolve o tempo em segundos. Rode três vezes e olhe a média. - Painel da hospedagem: muitos painéis mostram tempo de resposta do PHP e do banco. Se o seu não mostra, use as opções acima.
Anote o TTFB antes de mexer em qualquer coisa. Sem essa linha de base, você não consegue dizer se a mudança melhorou ou piorou. Esse cuidado vale para qualquer otimização, e é o mesmo princípio usado em medir e comparar a velocidade de carregamento em vários sites.
Teste de isolamento: tema padrão e plugins em lote
Com o TTFB medido, o próximo passo é isolar. A ideia é simples: trocar uma variável por vez e medir de novo. O procedimento abaixo funciona em qualquer site WordPress, mas exige cuidado em site no ar.
Passo 1: tema padrão
Ative temporariamente um tema padrão (Twenty Twenty-Four, por exemplo) em um ambiente de teste ou em uma janela de manutenção. Meça o TTFB de novo. Se o tempo despencar, o problema está no tema ou nos recursos que ele carrega. Se continuar igual, o tema não é o culpado.
Passo 2: plugins desativados em lote
Desative todos os plugins de uma vez e meça. Se o site ficar rápido, o problema está em um ou mais plugins. Aí você reativa em grupos de cinco, medindo entre cada grupo, até a lentidão voltar. O grupo que trouxe o problema de volta contém o culpado.
Esse método é mais rápido do que testar plugin por plugin, e é o mesmo raciocínio de profiler de plugins para achar o que pesa no site. Só não faça isso em produção sem aviso: desativar todos os plugins derruba checkout, formulários e áreas de membros.
Passo 3: banco de dados
Se o tema e os plugins não explicam a lentidão, olhe para o banco. Tabelas infladas de postmeta, revisions antigas, transients expirados e consultas lentas pesam. No painel, use um plugin de inspeção de banco ou rode SHOW FULL PROCESSLIST; no MySQL para ver o que está travando. O artigo sobre como limpar o banco de dados de um site WordPress lento detalha o que remover sem quebrar o site.
Quando o cache resolve e quando ele só esconde
Cache de página guarda o HTML pronto e evita que o WordPress processe tudo de novo a cada visita. Ele resolve quando o gargalo é o tempo de processamento no servidor, especialmente em páginas que muitos visitantes acessam ao mesmo tempo.
Ele não resolve quando:
- O TTFB é alto mesmo em páginas em cache, porque o servidor demora para entregar qualquer coisa.
- A página tem conteúdo personalizado por usuário (carrinho, área logada), que o cache precisa ignorar.
- O problema está em imagens grandes ou scripts de terceiros, que o cache de página não otimiza.
- O banco está travando em consultas pesadas, porque o cache só mascara a primeira visita.
Na prática, instalar cache sem diagnosticar costuma dar a sensação de melhora por alguns dias e depois o problema volta, agora mais difícil de enxergar. Por isso a ordem importa: primeiro isolar, depois otimizar.
Erros comuns nessa triagem
- Medir só a home. A home pode estar em cache e o resto do site não. Meça páginas internas, produto, blog e checkout.
- Testar logado. Usuário logado vê versão sem cache. Use navegação anônima para medir o que o visitante vê.
- Desativar plugins em produção sem backup. Se algo quebrar, você precisa restaurar rápido.
- Confundir cache de página com cache de objeto. São camadas diferentes, com efeitos diferentes. Ativar um não substitui o outro.
- Ignorar o cron do WordPress. Tarefas agendadas rodando em horário de pico derrubam o TTFB sem aparecer em nenhum plugin.
Se o site está fora do ar ou intermitente, o diagnóstico muda: pode ser servidor, não site. O artigo sobre site WordPress caiu: servidor ou o próprio site? ajuda a separar os dois casos antes de continuar.
Prevenção: medir sempre, não só quando dói
A melhor forma de não passar por isso de novo é ter uma linha de base. Meça o TTFB das páginas principais uma vez por mês, guarde os números e compare. Assim, quando o site ficar lento, você sabe exatamente quando começou e o que mudou naquele período.
Se você administra vários sites, esse hábito precisa ser automatizado. Fazer a triagem site por site, abrindo painel, desativando plugin, medindo TTFB, consome horas. Um painel como o 100% WP centraliza monitoramento e manutenção de vários sites em um lugar só, o que permite ver qual site saiu da linha de base antes que o cliente reclame. Para quem cuida de uma carteira grande, essa visão comparativa é o que evita o efeito dominó.
Quando chamar alguém
Se depois de isolar tema, plugins e banco o TTFB continua alto, o gargalo provavelmente está na hospedagem: CPU limitada, disco lento ou plano compartilhado sobrecarregado. Nesse caso, a conversa é com o suporte, com os números na mão. Se o site é de cliente e você não pode mexer em produção, ou se a lentidão afeta checkout e receita, chamar um especialista em performance evita que a tentativa de otimização vire um incidente. O serviço de site lento existe para esse tipo de caso.
