Core Web Vitals: como combinar dados de campo e laboratório

Leitura executiva

Principais conclusões

• Core Web Vitals são métricas de campo avaliadas no percentil 75.
• Lighthouse não mede INP real sem interações de usuários.
• Campo confirma o problema; laboratório ajuda a explicar a causa.
• Priorize por página, jornada, alcance e confiança da evidência.

Core Web Vitals medem carregamento, responsividade e estabilidade visual. Segundo a documentação do web.dev, uma boa experiência exige LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1, avaliados no percentil 75 e separados entre mobile e desktop.

Essas métricas são de campo. O desafio é que dados reais mostram o sintoma agregado, mas raramente apontam sozinhos a linha de código, imagem ou terceiro responsável. Testes de laboratório fazem o caminho inverso: ajudam a depurar uma execução, mas não representam toda a população.

Combinar as duas fontes é o que transforma uma nota em diagnóstico.

O que são dados de campo

Dados de campo vêm de visitas reais. O Chrome User Experience Report (CrUX), por exemplo, agrega experiências de usuários elegíveis do Chrome ao longo de uma janela de tempo. Search Console e PageSpeed Insights usam esses dados em diferentes visualizações.

O campo captura diversidade que um teste isolado não reproduz:

• modelos de celular;
• redes móveis e Wi-Fi;
• localização;
• cache vazio ou aquecido;
• páginas de entrada diferentes;
• interações reais;
• scripts condicionais;
• estados de login e personalização, quando incluídos na medição.

Essa diversidade torna o dado mais próximo da experiência, mas reduz a capacidade de atribuir causa.

O que são dados de laboratório

Laboratório executa a página sob condições controladas. Lighthouse, DevTools e WebPageTest podem simular rede, CPU, viewport e cache, além de expor waterfall, tarefas longas, dependências e elementos responsáveis.

O laboratório é adequado para:

• reproduzir um problema;
• comparar antes e depois;
• encontrar recursos bloqueantes;
• inspecionar a descoberta da imagem de LCP;
• localizar tarefas longas;
• observar mudanças de layout;
• criar testes de regressão no desenvolvimento.

Como a condição é artificial, o resultado muda entre execuções e não deve ser apresentado como “o tempo do site” para todos os usuários.

Como cada métrica aparece nas ferramentas

LCP

Pode ser medido no campo e no laboratório. O elemento responsável pode variar conforme viewport, conteúdo, cookie, experimento e dispositivo. Compare o elemento de laboratório com dados coletados na própria aplicação quando possível.

INP

Depende de interações reais ao longo da visita. Um carregamento automatizado sem cliques e teclas não consegue produzir INP representativo. Lighthouse usa Total Blocking Time (TBT) como sinal de laboratório relacionado à disponibilidade da thread principal, mas TBT não é INP.

CLS

Pode ser observado nos dois ambientes. No campo, mudanças podem acontecer depois de interações ou durante visitas longas. No laboratório, o teste pode terminar antes de um banner, anúncio ou conteúdo tardio provocar deslocamento.

Leia o PageSpeed Insights em duas partes

O PageSpeed Insights costuma apresentar primeiro a experiência real disponível no CrUX e depois o diagnóstico de laboratório do Lighthouse.

Pergunte, nessa ordem:

1. existem dados para a URL ou apenas para a origem;
2. qual dispositivo está selecionado;
3. a avaliação cobre uma janela agregada ou uma execução;
4. qual métrica falha no campo;
5. qual elemento ou cadeia de recursos aparece no laboratório;
6. a oportunidade sugerida se conecta ao elemento que falhou;
7. a página testada representa o template afetado.

Esse roteiro evita corrigir qualquer item vermelho sem provar relação com o problema principal.

Por que URL e origem podem discordar

Uma URL pode ter dados próprios quando há volume suficiente. Caso contrário, a ferramenta pode mostrar dados agregados da origem. A origem mistura templates, jornadas e níveis de performance.

Se a home é rápida e páginas de produto são lentas, a média pode esconder o problema. Se uma campanha pesada recebe muito tráfego, pode piorar o agregado mesmo quando o template principal está saudável.

Agrupe páginas por tipo: home, categoria, produto, artigo, busca, checkout e landing page. O diagnóstico e a ação normalmente pertencem ao template, não a uma URL aleatória.

Um fluxo de diagnóstico em seis etapas

1. Confirme o sinal de campo

Identifique métrica, dispositivo, grupo de páginas e período. Se não houver dados públicos, marque como desconhecido e considere instrumentação própria com a biblioteca web-vitals.

2. Selecione URLs representativas

Escolha exemplos do mesmo template, incluindo uma página boa e uma ruim quando possível. Isso ajuda a encontrar diferenças de conteúdo, terceiros ou configuração.

3. Reproduza em laboratório

Mantenha condições comparáveis. Execute mais de uma vez e observe mediana ou distribuição, não apenas o melhor resultado.

4. Encontre a causa concreta

Para LCP, localize o elemento e sua cadeia de descoberta. Para INP, capture interações e tarefas. Para CLS, registre o elemento que se moveu e o elemento que causou o movimento.

5. Implemente uma mudança delimitada

Evite combinar troca de CDN, refatoração de JavaScript e redesign no mesmo experimento quando o objetivo é aprender qual ação funcionou.

6. Verifique nos tempos corretos

Laboratório pode reagir logo após o deploy. Campo agregado precisa acumular novas visitas e atualizar a janela. Registre a data da mudança para evitar interpretar atraso como ausência de efeito.

Como priorizar páginas e correções

Combine quatro dimensões:

• alcance: quantas visitas e URLs compartilham o problema;
• jornada: quão importante é o template para descoberta ou conversão;
• gravidade: distância do limite e consistência do sinal;
• confiança: qualidade da evidência que liga causa e métrica.

Uma correção simples de imagem que afeta todas as páginas de produto pode vencer uma refatoração complexa numa seção pouco visitada. A nota mais baixa nem sempre é a maior oportunidade.

Erros comuns de interpretação

“A nota caiu, então o site piorou”

Uma execução pode variar por servidor, rede, conteúdo e ruído de ambiente. Confirme tendência e examine métricas individuais.

“Passamos no laboratório, então passamos no campo”

O laboratório representa uma condição. Usuários reais ainda podem enfrentar aparelhos mais lentos, cache diferente e interações não testadas.

“Falhamos no campo, então a causa é a oportunidade com maior economia”

As oportunidades do Lighthouse estimam melhorias sob aquele teste. Conecte a recomendação ao elemento e à cadeia crítica antes de priorizar.

“Performance prova conversão”

Melhor performance reduz um tipo de atrito, mas o impacto comercial depende da página, intenção, oferta e medição. Use analytics ou experimento para estimar efeito no negócio.

Transforme métricas em backlog

Uma tarefa bem escrita inclui fonte e aceite:

Observação: páginas de produto falham LCP no campo móvel; no laboratório, a imagem principal é descoberta após o JavaScript do carrossel. Ação: renderizar a primeira imagem no HTML, aplicar srcset e prioridade apenas ao candidato de LCP. Aceite: imagem correta permanece responsiva, o LCP de laboratório melhora em testes repetidos e os dados de campo são acompanhados após o deploy.

O guia geral de Core Web Vitals explica as métricas. Os próximos diagnósticos aprofundam LCP, INP e CLS.

Campo e laboratório não competem. Um mostra o que a população viveu; o outro ajuda a investigar por que uma execução se comportou assim. A decisão confiável nasce da combinação.

Respostas diretas

Perguntas frequentes

Por que PageSpeed Insights mostra dados diferentes do Lighthouse?

A parte superior pode mostrar dados reais agregados do CrUX, enquanto o Lighthouse executa um teste de laboratório com dispositivo e rede simulados. As fontes, períodos e condições são diferentes.

Uma página sem dados de campo falhou?

Não. Pode não haver volume suficiente para publicar dados no conjunto consultado. O estado correto é desconhecido; use medição própria e laboratório como evidência complementar.

Preciso atingir 100 no Lighthouse?

Não. A pontuação ajuda na depuração, mas deve ser subordinada à experiência real, à estabilidade entre testes e aos objetivos da página.