Se a pergunta é “por que meu WordPress está lento?”, a resposta está nos seus próprios dados, e dá para achar em mais ou menos uma hora. Primeiro confirme o problema com dados de campo de visitantes reais no Search Console ou no PageSpeed Insights. Depois separe tempo de servidor e tempo de navegador medindo o TTFB com e sem cache. Se o servidor está lento, use o Query Monitor e o banco para achar o plugin, a query ou a chamada remota que consome o tempo. Se o servidor está rápido, use o Chrome DevTools para achar a imagem, o script ou a tag de terceiro que atrasa a página. Corrija o maior primeiro.
Este post é a metade do diagnóstico. No meu outro artigo, sobre por que sites WordPress são lentos por motivos estruturais, explico as causas que encontro sempre: hospedagem, banco de dados, arquivos que bloqueiam a renderização e scripts de terceiros. Aqui a pergunta é mais estreita: no seu site, hoje, qual delas é? Quando você souber, o guia de como acelerar o WordPress cobre as correções camada por camada.
O site está lento para os visitantes ou só no teste?
Confira isso antes de tudo, porque muita “lentidão” de WordPress é uma nota de laboratório numa única rodada. O PageSpeed Insights mostra duas coisas na mesma página: dados de campo do Chrome UX Report no topo e um teste de laboratório do Lighthouse embaixo. Os dados de campo são o que o Google usa para as Core Web Vitals: o percentil 75 dos carregamentos reais nos últimos 28 dias.
- Se os dados de campo passam e só a nota de laboratório está baixa, não é uma emergência. É uma nota de laboratório.
- Se os dados de campo reprovam, anote qual métrica reprova (LCP, INP ou CLS) e em quais grupos de URL. O relatório de Core Web Vitals do Search Console agrupa URLs parecidas, o que normalmente corresponde aos templates.
- Se não há dados de campo, o site não tem tráfego suficiente do Chrome para entrar no CrUX. Use dados de laboratório e trate como aproximação.
Por que os dois tipos de dado discordam é assunto para um artigo inteiro: dados de campo vs dados de laboratório.
Por que meu WordPress está lento: servidor ou navegador?
Todo carregamento de página se divide em duas metades: o tempo até o HTML chegar (TTFB) e tudo o que o navegador faz depois. Essa divisão diz onde procurar.
| O que você vê | Camada provável | Onde olhar em seguida |
|---|---|---|
| — | — | — |
| TTFB alto em todas as páginas | Hospedagem, PHP, falta de cache de página | Testes de servidor abaixo, guia de TTFB |
| TTFB rápido às vezes e lento em outras | Cache miss ou bypass | Cabeçalhos da resposta, cookies, query strings |
| TTFB alto só em alguns templates | Um plugin, uma query ou uma chamada remota nesses templates | Query Monitor |
| TTFB bom, LCP ruim | Imagens, CSS, fontes, scripts que bloqueiam | Painel Performance do DevTools, guia de LCP |
| LCP bom, INP ruim | JavaScript e tags de terceiros | DevTools com throttling de CPU, guia de INP |
| Admin lento, front-end bom | Heartbeat, admin-ajax, cron, telas pesadas de plugins | Query Monitor no wp-admin |
O web.dev considera bom um TTFB de até 0,8 segundo. Se o seu está bem acima disso, comece pelo servidor mesmo que a reclamação tenha sido sobre imagens.
Como saber se o problema é o servidor?
Meça o TTFB direto, com e sem cache. No terminal:
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/mostra o tempo até o primeiro byte- rode duas vezes na mesma URL; a segunda deve pegar o cache de página
- rode de novo com uma query string como
?nocache=1ou com um cookie de usuário logado para ver o tempo sem cache
Depois leia os cabeçalhos da resposta com curl -I. A maioria dos caches de página adiciona um cabeçalho com HIT ou MISS, e a CDN adiciona o dela. Se as suas landing pages principais respondem MISS em requisições repetidas, o cache está sendo pulado. Os motivos comuns são cookies gravados para todo visitante, parâmetros de campanha e tempo de vida de cache curto. As três camadas de cache estão explicadas em page cache, object cache, edge cache.
Se o tempo sem cache é alto, o trabalho está no PHP e no banco. Aí você precisa de ferramentas que olham por dentro do WordPress.
Como descobrir quais plugins estão deixando o WordPress lento?
Com um profiler, e não desativando plugin por plugin em produção. A minha ordem:
- Instale o Query Monitor numa cópia de homologação, ou em produção visível só para administradores.
- Carregue o template lento logado e abra o painel Queries by Component. Ele agrupa as queries e o tempo delas por plugin e tema.
- Abra o painel HTTP API Calls. Um plugin que chama uma API remota durante a geração da página é uma das coisas mais caras que encontro, e se esconde bem porque depende do servidor de outra empresa.
- Confira o painel de Hooks e Actions atrás de callbacks que rodam em toda requisição mas só importam numa tela.
- Se você tem WP-CLI, o pacote do comando profile (
wp profile stageewp profile hook) quebra a requisição em bootstrap, query principal e template, e depois em hooks individuais. - Se ainda precisar confirmar, desative plugins em homologação pela metade. Desligue metade, meça e vá estreitando na metade que mudou o número.
Anote o tempo por plugin ou por hook. Isso transforma “o WordPress está lento” em “este plugin adiciona tanto tempo a este template”, um problema que dá para resolver ou levar ao fornecedor.
Como saber se o problema é o banco de dados?
Dois lugares cobrem a maioria dos casos. O primeiro são as opções com autoload: linhas da wp_options que o WordPress carrega em toda requisição. O Site Health avisa quando elas ficam grandes demais (desde o WordPress 6.6), e no WP-CLI o comando wp option list --autoload=on --format=total_bytes dá o tamanho total. Depois liste as maiores linhas e descubra qual plugin é dono de cada uma.
O segundo são as queries lentas. O Query Monitor marca queries lentas e duplicadas em cada requisição. No servidor, o slow query log do MySQL ou do MariaDB mostra o que está lento em todo o tráfego, incluindo cron e tarefas em segundo plano que o Query Monitor nunca vê. Procure queries em wp_postmeta e wp_options sem índice utilizável, e a mesma query repetida dezenas de vezes numa página.
A limpeza em si, e o que é seguro apagar, está em otimização do banco de dados do WordPress.
Como descobrir o que deixa o front-end lento?
Quando o TTFB está bom, o atraso está no navegador. O Chrome DevTools tem o que você precisa:
- O painel Performance grava um carregamento e marca o LCP. Clique no marcador para ver o elemento e confira se ele teve lazy load, foi descoberto tarde ou ficou esperando CSS.
- O painel Network, filtrado por domínio, mostra quantas requisições vêm de terceiros e quanto pesam. Ordene por tamanho e por horário de início.
- O painel Coverage mostra quanto de cada arquivo CSS e JavaScript a página realmente usou. Em sites com builder a parte não usada costuma ser grande.
- Para o INP, grave uma interação (abrir o menu, adicionar ao carrinho, fazer uma busca) com throttling de CPU ligado e procure tarefas longas. A aba Bottom-Up mostra qual script é dono do tempo.
Os diagnósticos do PageSpeed Insights apontam para as mesmas coisas, mas o DevTools deixa você clicar até a causa. O post de ferramentas de Core Web Vitals compara o que cada ferramenta mostra e quando usar.
Por que só o admin do WordPress está lento?
Um wp-admin lento com front-end rápido normalmente vem de coisas que o visitante nunca dispara:
- a Heartbeat API consultando o
admin-ajax.phpenquanto os editores deixam abas abertas - o WP-Cron rodando tarefas pesadas nos carregamentos de página em vez de um cron de verdade no sistema
- painéis e avisos de plugins que fazem chamadas remotas em toda tela do admin
- telas de listagem que consultam tabelas de postmeta grandes, comum em lojas
O Query Monitor também funciona no admin. No WooCommerce, as telas de pedidos e os relatórios merecem uma análise própria, que faço em como resolver um admin do WooCommerce lento.
O que fazer com o que você encontrou?
Ordene. Para cada achado, anote a camada, os templates afetados, quanto tempo custa e quão difícil é corrigir. Problemas de servidor e cache afetam todas as páginas, então costumam ir para o topo mesmo quando o relatório do PageSpeed lista uma imagem primeiro. Depois corrija uma coisa de cada vez e meça de novo, para saber qual mudança ajudou.
Para as correções mais comuns num formato de marcar, use o checklist de velocidade do WordPress. Para entender o porquê da ordem de correção, volte ao guia de engenharia para acelerar o WordPress.
Quando pedir ajuda?
Quando o diagnóstico aponta para algo que você não consegue mudar sozinho, ou quando as correções óbvias já foram feitas e os dados de campo continuam reprovando. É para isso que existe a minha auditoria de performance WordPress: passo por cada camada com os dados de campo como referência e entrego uma lista ordenada do que corrigir. Para trabalhos mais longos, veja como atuo como especialista em performance WordPress.