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.
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.
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 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.