Testar desempenho WordPress exige cruzar laboratório e campo, nunca confiar em uma nota só. Segundo o web.dev (2024), a meta de campo é LCP até 2,5 s, INP até 200 ms e CLS até 0,1 no percentil 75. A nota verde do Lighthouse engana quando o TTFB real passa de 600 ms. Comece pelo dado de campo, depois priorize o gargalo.

Testar desempenho WordPress significa medir com ferramentas diferentes para separar o que é problema de servidor do que é problema de página, e só então decidir o que corrigir. A maioria dos sites que chega ao suporte da FULL já tinha uma nota verde no PageSpeed, mas reprovava no campo do Search Console. O motivo é simples: laboratório simula um ambiente, campo mede usuários reais. Este tutorial mostra como usar PageSpeed Insights, GTmetrix, WebPageTest, Lighthouse, o CrUX e o Query Monitor em sequência, ler cada métrica sem se enganar e transformar o teste em uma lista de ações priorizada. Para o panorama da métrica, veja o guia de conteúdos de performance WordPress da FULL.

Diagnóstico rápido: Qual ferramenta usa qual sinal

As 5 ferramentas de testar desempenho WordPress respondem a perguntas diferentes, e usar a errada gera conclusão errada. O PageSpeed Insights mostra dado de campo (CrUX) ao lado do laboratório; GTmetrix e WebPageTest dão a cascata de carregamento; o Query Monitor mede o servidor por dentro.

O Lighthouse, por sua vez, roda local e isolado, ideal para repetir o mesmo teste sem ruído. A tabela abaixo cruza objetivo, sinal e custo para você escolher a ferramenta certa antes de abrir qualquer aba do navegador.

O erro comum é parar na primeira nota. Quem só abre o Lighthouse vê um número de laboratório mais otimista que a realidade, porque roda em rede e CPU simuladas. Cruzar com o campo do PageSpeed evita a aprovação falsa. Para entender cada métrica antes de medir, vale revisar os Core Web Vitals e o conceito de TTFB.

Por que a nota de laboratório engana e o campo não

Testar desempenho WordPress só no laboratório engana porque a nota verde mede um ambiente controlado, não o seu usuário real. O PageSpeed Insights separa isso em “Dados de campo” (CrUX, dos últimos 28 dias de visitantes reais) e “Dados de laboratório” (uma simulação instantânea).

Segundo o web.dev, só o campo no percentil 75 conta para a aprovação que o Google usa de fato. Na prática, é comum ver Lighthouse 95 com o campo reprovado, e quem para na nota de laboratório nunca entende por quê.

Esse descompasso aparece muito nos tickets da FULL. O laboratório testa uma única carga com cache quente; o campo agrega celulares antigos, 4G instável e a primeira visita sem cache. Quando o TTFB da hospedagem passa de 600 ms, o LCP de campo estoura, mesmo com a imagem otimizada. Por isso a ordem importa: leia o campo primeiro e só depois corrija. Inverter isso faz tanta gente mexer na imagem quando o gargalo era o servidor, como detalha o diagnóstico completo de performance.

As 3 métricas que você precisa ler em qualquer teste

Testar desempenho WordPress se resume a três métricas de campo, com metas claras. O LCP mede quando o maior elemento aparece, com meta de até 2,5 s; o INP mede a resposta ao clique, com meta de até 200 ms; o CLS mede o quanto a página “pula”, com meta de até 0,1. As três precisam passar no percentil 75 juntas.

Cada métrica aponta um culpado diferente, e isso é o que torna o teste útil. LCP alto quase sempre é hospedagem lenta ou imagem de destaque pesada; o INP ruim costuma ser excesso de JavaScript de terceiros; o CLS aparece quando fontes e banners carregam sem espaço reservado. O LCP é o gargalo que mais aparece no suporte da FULL, e na maioria dos casos a causa está no servidor, não no plugin de imagem. Quem quer aprofundar a leitura de campo encontra o passo a passo em Core Web Vitals no WordPress.

Passo a passo: Como testar desempenho WordPress em 5 etapas

Testar desempenho WordPress em 5 etapas leva cerca de 15 minutos e entrega uma lista priorizada de correções, não apenas uma nota. A sequência abaixo vai do dado de campo (o que o Google vê) até o lado do servidor (o que o usuário não vê, mas sente). Faça na ordem: pular a etapa de campo é o erro que mais gera retrabalho. Cada etapa indica a ferramenta certa e o número-alvo a observar.

Legenda: a aba de dados de campo é a única que conta para a aprovação oficial do Google.

Passo 1: Rode o PageSpeed insights e leia o campo primeiro

Abra o PageSpeed Insights, cole a URL e olhe primeiro o bloco “Dados de campo”. Se ele estiver vazio, o site tem pouco tráfego para o CrUX e você depende do laboratório por enquanto. Anote LCP, INP e CLS de campo: esse é o seu placar real. A nota de 0 a 100 do laboratório é secundária, serve de pista, não de veredicto.

Passo 2: Confirme o gargalo no GTmetrix com a cascata

Rode a mesma URL no GTmetrix e abra a aba “Waterfall”. A cascata mostra cada requisição em ordem: a linha mais longa antes do primeiro byte é TTFB de servidor; linhas longas de imagem ou script revelam recursos pesados. O GTmetrix também guarda histórico, o que ajuda a provar o antes e o depois de uma mudança.

Passo 3: Grave o filme da página no WebPageTest

No WebPageTest, escolha um local próximo do seu público e rode 3 vezes para pegar a mediana. O recurso de filme quadro a quadro mostra o instante exato em que o conteúdo principal pinta, o que torna o LCP visível, não abstrato. É a ferramenta que melhor explica “por que parece lento” mesmo com nota boa.

Passo 4: Meça o servidor com o query monitor

Instale o Query Monitor e abra qualquer página logado como admin. Ele lista as queries lentas, o tempo de PHP e os hooks mais pesados. Quando o TTFB está alto, a causa quase sempre aparece aqui: uma query sem índice ou um plugin que roda em toda requisição. Esse é o teste que nenhuma ferramenta externa faz por você.

Passo 5: Reteste depois de cada correção, uma de cada vez

Após cada ajuste, repita o teste com a mesma ferramenta e o mesmo aparelho de referência. Mudar uma variável por vez é o que prova causa e efeito; mexer em cinco coisas juntas esconde o que funcionou. Espere alguns dias para o campo do CrUX refletir a melhoria antes de declarar vitória no Search Console.

Os 4 erros que invalidam o seu teste de desempenho

Testar desempenho WordPress sem evitar 4 armadilhas comuns produz número bonito e site lento na vida real. O erro número um é medir só o laboratório e ignorar o campo, já que só o percentil 75 do CrUX aprova. O segundo é testar uma vez e tirar conclusão: as ferramentas variam entre execuções, por isso o WebPageTest recomenda rodar três vezes e usar a mediana.

O terceiro erro ao testar desempenho WordPress é medir só a home e achar que cobriu o site; a página de produto, o post longo e o checkout têm gargalos próprios e precisam de teste separado. O quarto é otimizar imagem quando o problema é servidor: se o TTFB passa de 600 ms, nenhum plugin de imagem salva o LCP, porque o atraso acontece antes do primeiro byte. A confiabilidade do teste depende de controlar essas variáveis, e quem já arrumou o básico encontra ganhos rápidos em otimizações rápidas de PageSpeed. Um teste honesto é mais valioso que um teste otimista.

Plano PRO da FULL: As ferramentas pagas inclusas

Quando o teste aponta cache, imagem e CSS como gargalos, a correção costuma exigir ferramentas pagas, e é aí que o bundle da FULL muda a conta. O plano PRO sai por R$849,90 e já inclui WP Rocket, Perfmatters e WP-Optimize, os mesmos plugins que a gente usa no suporte para corrigir o que o teste revela.

Comprados avulsos, só o WP Rocket custa cerca de US$59 por ano por site, e a soma de três licenças pesa no orçamento de quem cuida de mais de um projeto. No bundle PRO, distribuído entre vários sites, o custo cai para cerca de R$85 por site, com ativação em um clique no painel, sem comprar licença por licença. Para comparar planos e o que cada um inclui, veja a página de planos da FULL. Vale conferir antes se o WP Rocket vale a pena no seu caso específico.

Decisão rápida: Por onde começar o teste

A escolha da ferramenta depende do sintoma, e a árvore abaixo resolve isso em uma olhada. Cada nó é auto-contido: leia a condição à esquerda e siga a recomendação à direita, sem precisar do resto do texto.

• Se você quer o veredicto oficial de aprovação → use o PageSpeed Insights e leia primeiro os dados de campo.
• Se a nota é boa mas o site parece lento → grave o filme no WebPageTest e veja o que pinta por último.
• Se o TTFB está acima de 600 ms → abra o Query Monitor e cace a query ou o plugin pesado, não mexa em imagem ainda.
• Se você precisa provar o antes e o depois → fixe o GTmetrix com o mesmo local e aparelho a cada rodada.

Perguntas frequentes sobre testar desempenho WordPress

Próximos passos para acelerar o seu site

Testar desempenho WordPress é o diagnóstico, não o tratamento, e a sequência que funciona é medir o campo, achar o gargalo e corrigir uma variável por vez. Para testar desempenho WordPress de forma honesta, comece pelo PageSpeed Insights para o placar real, confirme a causa no GTmetrix ou no Query Monitor e só então decida entre cache, imagem ou hospedagem. Na maioria dos casos que chegam ao suporte da FULL, o vilão era o servidor, e nenhum plugin de imagem resolve isso sozinho. Para continuar aprendendo, o FULL Academy reúne os tutoriais de performance em um só lugar, e o guia Acelere o WordPress conecta cada etapa do teste à correção certa. Medir bem é o que separa o site que só parece rápido do site que é rápido para o usuário.