--- title: "Core Web Vitals: dados de campo vs laboratório" id: "656" type: "post" slug: "core-web-vitals-dados-de-campo-vs-laboratorio" published_at: "2026-10-06T20:22:46+00:00" modified_at: "2026-10-06T20:22:46+00:00" url: "https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/" markdown_url: "https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio.md" excerpt: "Por que a nota do PageSpeed e o relatório do CrUX discordam, qual dos dois o Google usa no Core Web Vitals e como usar campo e laboratório juntos." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/pt/category/performance-pt/) 6 min de leitura # Core Web Vitals: dados de campo vs laboratório Por que a nota do PageSpeed e o relatório do CrUX discordam, qual dos dois o Google usa no Core Web Vitals e como usar campo e laboratório juntos. Publicado **06/10/2026**6 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) Dados de campo são o que os usuários reais viveram no seu site. Dados de laboratório são o que um único teste simulado mediu em condições controladas. O Google avalia o Core Web Vitals com dados de campo do Chrome UX Report (CrUX): o percentil 75 das visitas reais no Chrome nos últimos 28 dias, em que bom significa LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1. Ferramentas de laboratório como o Lighthouse servem para diagnosticar problemas e testar mudanças antes de elas chegarem aos usuários. Na prática, dados de campo vs laboratório se dividem assim: o campo decide o que corrigir e o laboratório mostra como. ## O que são dados de campo? Dados de campo, também chamados de real user monitoring (RUM), vêm de visitas de verdade. A fonte mais conhecida é o CrUX, que reúne dados de performance de usuários do Chrome que aceitaram compartilhar estatísticas de uso. São esses dados que aparecem no relatório de Core Web Vitals do Search Console e na seção de experiência dos usuários reais, no topo do PageSpeed Insights. Se as métricas ainda são novidade, comece por [o que são Core Web Vitals](https://danielpazwp.com/pt/o-que-sao-core-web-vitals/) . Quatro coisas para ter em mente ao ler esses dados: - Ele informa o percentil 75. A página passa se pelo menos 75% das visitas atingem o limite, então uma mediana rápida não esconde uma cauda lenta. - É uma janela móvel de 28 dias. Uma correção publicada hoje leva semanas para aparecer por inteiro. - Existe no nível da origem e, quando há tráfego suficiente, no nível da URL. Páginas com pouco tráfego podem ficar sem dados ou cair nos dados da origem. - Reflete o seu público real: os aparelhos, as redes, os lugares e o jeito como as pessoas interagem com a página. Você também pode coletar os seus próprios dados de campo com a biblioteca JavaScript `web-vitals`, do Google, ou com um serviço de RUM. Assim você tem dados de todas as páginas e de todos os navegadores que suportam as APIs, além de detalhes que o CrUX não mostra, como qual elemento foi o LCP ou qual interação ficou lenta. ## O que são dados de laboratório e para que servem? Dados de laboratório vêm de um teste controlado: um carregamento de página, num perfil de dispositivo e de rede definido, a partir de um lugar. O Lighthouse, que alimenta a parte de baixo do PageSpeed Insights, é o exemplo mais comum. No mobile ele emula um celular intermediário numa conexão limitada. WebPageTest e o painel Performance do Chrome DevTools também são ferramentas de laboratório. Comparo as duas principais em [PageSpeed Insights vs Lighthouse](https://danielpazwp.com/pt/pagespeed-insights-vs-lighthouse-pt/) . A grande vantagem é que o laboratório é reproduzível. Dá para rodar o mesmo teste antes e depois de uma mudança e ver a diferença em minutos. Ele também entrega diagnósticos que o campo não tem: waterfall, trace da thread principal, lista de recursos que bloqueiam a renderização, o elemento de LCP e quanto tempo cada fase levou. O que ele não diz é o que os seus usuários vivem. É um aparelho, uma rede e um carregamento a frio, sem interação real. ## Dados de campo vs laboratório, lado a lado | Aspecto | Dados de campo (CrUX, RUM) | Dados de laboratório (Lighthouse, WebPageTest) | | --- | --- | --- | | Origem | Visitas reais de usuários reais | Um carregamento simulado ou controlado | | Usados pelo Google no Core Web Vitals | Sim | Não | | Tempo para refletir uma mudança | Até 28 dias no CrUX | Imediato | | INP | Medido a partir de interações reais | Não mensurável; o TBT serve de indicador aproximado | | CLS | Deslocamentos durante a visita inteira | Só os deslocamentos do carregamento de teste | | Diagnóstico | Limitado no CrUX; mais rico com RUM próprio | Waterfall, traces e auditorias detalhadas | | Melhor para | Decidir o que corrigir e confirmar resultados | Achar causas e testar correções | ## Por que os dois discordam tanto? Ouço a mesma pergunta em auditoria o tempo todo: “O PageSpeed dá 45, mas o Search Console diz que as minhas páginas estão boas. Qual está certo?” Os dois. Eles medem coisas diferentes. Estes são os motivos mais comuns da diferença: - Aparelhos e redes. Se o seu público usa principalmente celulares recentes em conexões rápidas, o LCP real pode ser bem melhor que o do perfil limitado do laboratório. Se usa Androids mais antigos, acontece o contrário. - Cache. O Lighthouse simula uma primeira visita. Usuários reais muitas vezes voltam com o cache do navegador já preenchido, e muitos caem num page cache ou numa CDN que um teste de laboratório numa URL sem cache nunca tocou. - Interações. O [INP](https://danielpazwp.com/pt/inp-no-wordpress/) depende do que o usuário clica e quando. Um teste que nunca clica não consegue medir, e o Total Blocking Time só sugere onde está o risco. - Deslocamentos depois do carregamento. Anúncios com lazy load, banners de cookies e rolagem infinita causam CLS mais tarde na visita, e o laboratório nunca vê isso. - Nota e métricas são coisas diferentes. A nota de performance do Lighthouse é um resumo ponderado do laboratório. Ela não é uma avaliação de Core Web Vitals, e o Google não a usa para ranqueamento. > A nota do Lighthouse é resultado de teste. O percentil 75 do CrUX é a experiência. Otimize para a experiência e use o teste para chegar lá. ## Como usar os dois na prática? Este é o fluxo que eu uso e ensino: - Comece pelos dados de campo. Veja o CrUX no PageSpeed Insights ou no Search Console para a origem e os templates principais. Descubra qual métrica reprova e em quais páginas. - Reproduza no laboratório. Rode Lighthouse ou WebPageTest numa URL representativa com um perfil de dispositivo realista e use o diagnóstico para achar a causa: TTFB lento, CSS que bloqueia a renderização, imagem principal sem otimização, um script de terceiro pesado. - Corrija uma coisa de cada vez em staging e compare os testes de laboratório antes e depois. Rode vários testes, não um, porque o resultado do laboratório varia. - Publique e espere. Acompanhe o seu RUM para ver os primeiros sinais e dê ao CrUX a janela completa de 28 dias antes de julgar o resultado. - Continue monitorando. Plugins, temas e tags de marketing mudam o tempo todo, e é nos dados de campo que as regressões aparecem primeiro. No INP, apoie-se nos dados de campo e em testes de interação reais. Grave um trace no DevTools enquanto clica no menu, nos filtros, no adicionar ao carrinho e nos campos de formulário que os usuários realmente usam, e procure tarefas longas na thread principal. Então não corra atrás da nota de laboratório por ela mesma. O campo diz onde você está, o laboratório diz por quê, e juntos eles provam que uma mudança deixou o site melhor para quem visita. Se o seu relatório de campo está reprovando e você não sabe por onde começar, veja como trabalho como [especialista em Core Web Vitals](https://danielpazwp.com/pt/especialista-core-web-vitals/) . [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 2026WordPress lento: os motivos estruturais e a ordem para corrigir](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/) [Performance out 2026Como acelerar o WordPress: guia de engenharia](https://danielpazwp.com/pt/como-acelerar-wordpress/)