--- title: "As melhores ferramentas de Core Web Vitals e para que serve cada uma" id: "576" type: "post" slug: "ferramentas-core-web-vitals" published_at: "2026-10-06T20:00:49+00:00" modified_at: "2026-10-06T20:00:49+00:00" url: "https://danielpazwp.com/pt/ferramentas-core-web-vitals/" markdown_url: "https://danielpazwp.com/pt/ferramentas-core-web-vitals.md" excerpt: "Quais ferramentas de Core Web Vitals mostram dados de campo, quais ajudam a depurar e a ordem em que uso cada uma nas auditorias de sites WordPress." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/pt/category/performance-pt/) 9 min de leitura # As melhores ferramentas de Core Web Vitals e para que serve cada uma Quais ferramentas de Core Web Vitals mostram dados de campo, quais ajudam a depurar e a ordem em que uso cada uma nas auditorias de sites WordPress. Publicado **06/10/2026**9 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) 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](https://danielpazwp.com/pt/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](https://danielpazwp.com/pt/pagespeed-insights-vs-lighthouse-pt/) . ### 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](https://danielpazwp.com/pt/avaliacao-core-web-vitals-reprovada/) . ### 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](https://danielpazwp.com/pt/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](https://danielpazwp.com/pt/plugins-core-web-vitals/) . ## Em que ordem usar as ferramentas? 1. Abra o relatório de Core Web Vitals do Search Console e anote quais grupos reprovam, em qual métrica e em qual aparelho. 2. Rode o PageSpeed Insights numa URL representativa de cada grupo reprovado. Leia primeiro o bloco de campo, depois os diagnósticos de laboratório. 3. 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. 4. Se a resposta do servidor é lenta sem cache, investigue com o Query Monitor. 5. 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](https://weboption.com.br/diagnostico/) 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](https://danielpazwp.com/pt/auditoria-performance-wordpress/) faz. [Trabalhe com o Daniel](https://danielpazwp.com/pt/#book) [Mais em Performance](https://danielpazwp.com/pt/category/performance-pt/) [Sobre o autorPágina do autor](https://danielpazwp.com/pt/author/daniel-paz/) ## Artigos relacionados [Todos os artigos](https://danielpazwp.com/pt/artigos/) [Performance out 2026Page cache vs object cache vs edge cache: qual você precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/) [Performance out 2026Core Web Vitals: dados de campo vs laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) [Performance out 2026WordPress lento: os motivos estruturais e a ordem para corrigir](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/)