As ferramentas de Core Web Vitals se dividem em dois grupos. As de campo mostram o que usuários reais do Chrome viveram: o Chrome UX Report (CrUX), o relatório de Core Web Vitals do Google Search Console, a parte de cima do PageSpeed Insights e o seu próprio monitoramento de usuários reais com a biblioteca web-vitals. As de laboratório carregam a página em condições controladas, para depurar: Lighthouse, o painel Performance do Chrome DevTools e o WebPageTest. O Google avalia suas páginas pelos dados de campo no percentil 75. Use as de campo para descobrir o que reprova e as de laboratório para entender por quê. No WordPress, some o Query Monitor para o lado do servidor.
Uso o mesmo conjunto pequeno de ferramentas em toda auditoria. Quase nunca o problema é a ferramenta. O problema é ler a nota de laboratório como se fosse o veredito. Se quiser antes a visão geral de como LCP, INP e CLS se comportam no WordPress, comece pelo guia completo de Core Web Vitals no WordPress.
Quais ferramentas de Core Web Vitals mostram dados de campo?
Os dados de campo vêm do CrUX. O Chrome coleta essas medições de usuários que autorizaram o envio, e o CrUX publica tudo numa janela móvel de 28 dias. Uma página passa quando as três métricas estão boas no percentil 75: LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1. Todas as ferramentas de campo abaixo leem do CrUX, menos o seu RUM, que lê direto dos seus visitantes.
PageSpeed Insights
O PageSpeed Insights mistura os dois tipos de dado na mesma tela. O bloco de cima traz os dados de campo do CrUX para a URL e para a origem inteira, quando o Chrome tem tráfego suficiente para reportar. Tudo que vem abaixo é uma única execução do Lighthouse em laboratório. Nas auditorias, vivo encontrando equipes que passaram meses otimizando a nota de laboratório enquanto o bloco de campo, que é o que o Google usa, não saía do lugar. A confusão é tão comum que escrevi um texto só sobre PageSpeed Insights vs Lighthouse e dados de campo vs laboratório.
Relatório de Core Web Vitals do Search Console
É o primeiro relatório que abro num site WordPress. Ele agrupa URLs com experiência parecida, separa celular de desktop e mostra qual métrica reprova em cada grupo. No WordPress, os grupos costumam bater com os templates: posts, páginas de produto, arquivos de categoria. Isso aponta o template a corrigir, em vez de uma URL solta. Quando você publica a correção, o botão “Validar correção” abre um período de acompanhamento de 28 dias, a mesma janela do CrUX. Se o seu relatório está vermelho agora, leia o que fazer quando a avaliação de Core Web Vitals reprova.
CrUX API, CrUX History API e BigQuery
A CrUX API devolve os valores de p75 e a distribuição entre bom, precisa melhorar e ruim para uma URL ou uma origem. A History API devolve os mesmos dados em série semanal, cobrindo vários meses, e é o que uso para mostrar se um deploy mexeu nos números de campo. O conjunto público no BigQuery é mensal e trabalha por origem. Serve para comparar seu site com concorrentes, não tanto para depurar uma página específica.
Monitoramento de usuários reais com a biblioteca web-vitals
A biblioteca JavaScript web-vitals, do Google, mede LCP, INP e CLS no navegador do visitante do mesmo jeito que o Chrome reporta. A versão de atribuição traz o que você precisa para corrigir: qual elemento foi o LCP, qual interação foi lenta e o que rodou durante ela, qual elemento se deslocou. Você manda isso para o Google Analytics 4 ou para um endpoint seu. O RUM é a única forma de ter números de páginas sem tráfego suficiente para o CrUX e de separar resultados por template, usuário logado ou tipo de aparelho.
Quais ferramentas ajudam a depurar uma métrica reprovada?
O dado de campo diz que as páginas de produto reprovam em INP no celular. Ele não diz qual script é o culpado. Para isso você precisa de uma ferramenta de laboratório e de um trace.
Lighthouse
O Lighthouse faz um carregamento com limitação simulada de rede e CPU e dá uma nota. No modo padrão, de navegação, ninguém clica em nada, então ele não mede INP. No lugar, mostra o Total Blocking Time como aproximação de laboratório. A nota de performance é uma média ponderada de métricas de laboratório e não é um Core Web Vital. Uso o Lighthouse para pegar regressões e confirmar que uma correção funciona antes de o dado de campo atualizar. Nunca como meta.
Painel Performance do Chrome DevTools
É onde passo a maior parte do tempo depurando. A visão de métricas ao vivo mostra LCP, CLS e INP enquanto você usa a página e pode exibir os dados de campo do CrUX ao lado dos seus números locais. Grave um trace e você vê o elemento LCP e a linha do tempo dele, as tarefas longas por trás de uma interação lenta e os grupos de deslocamento de layout. Ligue a limitação de CPU. Notebook de desenvolvedor esconde problemas que um Android intermediário mostra na hora.
WebPageTest
O WebPageTest carrega a página em navegadores reais, de vários locais e perfis de conexão, e entrega waterfall e filmstrip. Uso muito para responder uma pergunta: quando o navegador pede a imagem do LCP e o que está na frente dela? Também é bom para comparar duas versões da mesma página lado a lado.
Query Monitor
O Query Monitor é um plugin gratuito de WordPress. Não é ferramenta de Core Web Vitals, mas merece estar na lista. Ele mostra consultas ao banco, consultas lentas, hooks e chamadas da HTTP API, agrupadas pelo plugin ou tema que as disparou. Quando a resposta do servidor é lenta em requisições sem cache, é assim que você descobre quem está gastando o tempo. A resposta do servidor faz parte do LCP, como explico no texto sobre TTFB no WordPress.
Como as ferramentas se comparam?
| Ferramenta | Dados | Mede INP | Melhor para |
|---|---|---|---|
| PageSpeed Insights | Campo (CrUX) e laboratório (Lighthouse) | Só na parte de campo | Checagem rápida de uma URL e da origem |
| Relatório do Search Console | Campo (CrUX) | Sim | Quais grupos de páginas reprovam no site todo |
| CrUX API e History API | Campo (CrUX) | Sim | Tendências e monitoramento por script |
| Biblioteca web-vitals | Campo, seus próprios visitantes | Sim, com atribuição | O elemento ou a interação exata a corrigir |
| Lighthouse | Laboratório | Não, usa Total Blocking Time | Pegar regressões e conferir correções |
| Painel Performance do DevTools | Laboratório, sua máquina | Sim, nas interações que você faz | Tarefas longas e linha do tempo do LCP |
| WebPageTest | Laboratório, navegadores reais | Não por padrão | Waterfalls, filmstrips, comparações |
| Query Monitor | Servidor do WordPress | Não | Consultas lentas e PHP por trás do TTFB |
Quais ferramentas do próprio WordPress ajudam?
O WordPress tem duas checagens que vale conhecer. Desde a 6.1, a Saúde do Site testa se existe cache de página funcionando, e desde a 6.6 avisa quando as opções com autoload ficam grandes demais. As duas pegam problemas estruturais de graça, antes de você abrir um profiler.
O plugin Performance Lab, do Time de Performance do WordPress, permite testar recursos de performance antes de eles entrarem no core. O carregamento especulativo começou ali e entrou no core na 6.8. Alguns módulos atuais, como o Image Prioritizer, usam dados coletados de visitas reais para decidir quais imagens ganham prioridade e quais ficam com lazy load. A comparação com plugins de cache e otimização está em os melhores plugins para Core Web Vitals.
Em que ordem usar as ferramentas?
- Abra o relatório de Core Web Vitals do Search Console e anote quais grupos reprovam, em qual métrica e em qual aparelho.
- Rode o PageSpeed Insights numa URL representativa de cada grupo reprovado. Leia primeiro o bloco de campo, depois os diagnósticos de laboratório.
- Reproduza o problema no painel Performance do DevTools com limitação de CPU. Ache o elemento LCP, as tarefas longas e os elementos que se deslocam.
- Se a resposta do servidor é lenta sem cache, investigue com o Query Monitor.
- Publique a correção, confira no Lighthouse ou no WebPageTest e acompanhe o dado de campo pela CrUX API ou pelo seu RUM até a janela de 28 dias virar.
Que hábitos com ferramentas levam a respostas erradas?
- Correr atrás de nota 100 no Lighthouse. A nota é só de laboratório e não decide se você passa.
- Testar logado no WordPress. A barra de administração carrega arquivos extras e a maioria dos caches de página ignora usuário logado.
- Confiar numa execução só. Resultado de laboratório varia entre execuções, então rode várias e compare a mediana.
- Testar só no desktop com fibra quando a maior parte do seu tráfego vem do celular.
- Usar ferramentas como o GTmetrix como segunda opinião. O GTmetrix roda o Lighthouse no laboratório dele, então tem os mesmos pontos cegos.
Perguntas frequentes
O PageSpeed Insights basta para checar Core Web Vitals?
Para uma URL, quase sempre sim, desde que você leia a parte de campo e não a nota. Para o site inteiro, não, porque ele só verifica a URL que você digita. Use o relatório do Search Console para ver todos os grupos de páginas.
Por que o PageSpeed Insights não mostra dados de campo da minha página?
O CrUX só publica URLs e origens com tráfego suficiente no Chrome. Página com pouco acesso cai para o dado da origem ou fica sem nada. O monitoramento de usuários reais com a biblioteca web-vitals cobre essa lacuna.
Preciso de uma ferramenta paga de monitoramento?
Para começar, não. Search Console, PageSpeed Insights, CrUX API e a biblioteca web-vitals, que é gratuita, dão conta da maioria dos sites WordPress. Os produtos pagos de RUM economizam tempo de configuração e trazem painéis e alertas, o que pesa mais conforme crescem o número de templates e de equipes.
Se quiser uma primeira olhada automática, o diagnóstico gratuito da WebOption roda as checagens básicas. Se quiser que eu leia os dados de campo, faça o trace dos templates que reprovam e entregue uma lista de correções em ordem de prioridade, é isso que a minha auditoria de performance WordPress faz.