Lighthouse vs field data: confira se a correção funcionou

O Lighthouse diz que está corrigido. Por que o Search Console continua vermelho?

O Lighthouse carrega a página uma vez, em um celular simulado, e mostra o LCP e o CLS desse carregamento. Os Core Web Vitals são field data: o percentil 75 de 28 dias de visitas reais no Chrome, em celulares e redes rápidos e lentos, com cache vazio e cheio, incluindo cada clique. Por isso, uma correção pode passar no Lighthouse hoje e levar quatro semanas para aparecer no Search Console. Compare três execuções do Lighthouse e depois acompanhe a field data.

Como rodar o Lighthouse para comparar o antes e o depois?

Rode o Lighthouse da mesma forma antes e depois da alteração:

1. Limpe os caches. Esvazie o cache do plugin de cache e da CDN após a alteração, senão o Lighthouse testa a página antiga.
2. Escolha uma ferramenta e fique com ela. Sem código: PageSpeed Insights, na aba Mobile. Como desenvolvedor: o painel do Lighthouse no Chrome DevTools com Device definido como Mobile, em uma janela anônima, porque extensões do navegador adicionam scripts próprios à página.
3. Teste a URL que recebeu o aviso. Se a alteração foi no template de produto, teste uma página de produto.
4. Rode três vezes e pegue o resultado do meio.
5. Olhe primeiro para o aviso e para a métrica. O aviso passa para Passed audits, e a métrica correspondente (LCP, CLS, Total Blocking Time) cai. A pontuação fica por último.

Por que a pontuação muda se nada mudou?

Cada execução é um carregamento, e nenhum carregamento é igual a outro: o servidor responde mais rápido ou mais devagar, a rede oscila, e anúncios, banners de consentimento e testes A/B podem variar de uma execução para outra. Em uma das minhas páginas de teste, o primeiro texto ou imagem (FCP) apareceu 1,5 s mais cedo em uma execução do que em outra; em uma segunda página, a pontuação deu 96 ou 80 sem que nada tivesse mudado. Subir alguns pontos depois de uma correção não diz quase nada até você comparar o resultado do meio de três execuções.

Seis execuções seguidas na mesma URL, www.bbc.com, deram 38, 44, 41, 73, 60 e 53 em dois minutos. Lighthouse 13.5.0, celular, throttling simulado como no PageSpeed Insights.

Gravando um trace no DevTools

Abra a página no Chrome, abra o DevTools e vá para o painel Performance. Em Capture settings (o ícone de engrenagem), defina Network como Slow 4G e CPU como 4x slowdown — perto do que o Lighthouse simula no celular —, depois clique em Record e recarregue. A aba Insights na barra lateral lista os mesmos insights do Lighthouse, cada um com as requisições e elementos por trás dele. Antes de gravar, o painel mostra o seu próprio LCP, CLS e INP em tempo real (o INP assim que você clica na página). Clique em Set up abaixo de Field metrics para ver ao lado os números do CrUX dos visitantes reais para a mesma URL.

Por que o Lighthouse diz uma coisa e o Search Console outra?

O Lighthouse fornece lab data: um único carregamento da página em um celular intermediário simulado, em uma conexão 4G lenta e com cache vazio. Ele para logo após o carregamento, então nunca rola a tela, não toca em nada nem abre uma segunda página. Você recebe o LCP e o CLS desse único carregamento, e nada de INP, porque o INP precisa de um visitante que clique.

A field data é o que o Chrome mediu para os visitantes reais: celulares rápidos e lentos, redes boas e ruins, a primeira visita com cache vazio e a décima com tudo em cache, rolando a tela, tocando, indo de página em página. O Google coleta esses dados no Chrome UX Report (CrUX), a partir de usuários do Chrome no Android e no desktop que compartilham estatísticas de uso. Os Core Web Vitals são essas visitas nos últimos 28 dias, no percentil 75 (p75) de cada métrica: três em cada quatro visitas foram no mínimo tão boas quanto esse número.

O Google usa a field data para ranquear. O Lighthouse serve para descobrir por que uma página está lenta e se uma alteração ajuda. Quando os dois discordam, é porque mediram carregamentos diferentes. Uma pontuação verde no Lighthouse com field data ruim costuma indicar celulares mais lentos que a simulação, respostas lentas a cliques (INP) ou conteúdo que se desloca enquanto os visitantes rolam a tela. Uma pontuação vermelha com field data boa costuma indicar que os visitantes têm celulares e redes mais rápidos que o 4G lento do Lighthouse, e voltam com os arquivos no cache.

Um relatório do PageSpeed Insights para www.bbc.com no celular, em 26 de outubro de 2026. As visitas reais passam em todos os três Core Web Vitals, com LCP de 1,2 s; a execução do Lighthouse no mesmo relatório marca 37, com LCP de 9,5 s.

O PageSpeed Insights mostra a field data da URL testada quando há visitas suficientes, e do site inteiro em Origem quando não há. O Search Console agrupa URLs semelhantes e avalia cada grupo pela sua pior métrica.

Onde ver a experiência real dos visitantes?

Quatro ferramentas gratuitas mostram o CrUX, a field data que o Google usa:

• PageSpeed Insights: a seção superior, "Descubra a experiência dos seus usuários reais", com LCP, INP e CLS no p75 nos últimos 28 dias, para a URL ou para a origem.
• Search Console: o relatório de Core Web Vitals, para celular e desktop, mostra quais grupos de URLs semelhantes estão ruins no site todo.
• Relatório CrUX History: uma barra por semana para o site ou para uma URL, para você acompanhar a tendência.
• DevTools: o painel Performance coloca os mesmos números ao lado do seu próprio carregamento (configure uma vez).

Um site com poucas visitas no Chrome não tem dados no CrUX: o PageSpeed Insights mostra "No Data" na seção superior. O CoreDash mede essas visitas mesmo assim.

CoreDash: qual página, qual elemento

O CrUX, a field data do Google, fornece um único p75 por URL ou por site. O CoreDash, o monitoramento de usuários reais que eu criei, é um script nas páginas que mede cada visita e identifica o elemento por trás de cada LCP, INP e CLS. Você filtra por página, dispositivo e elemento, e a alteração aparece na série temporal logo nas visitas seguintes. Adicione o script antes de alterar qualquer coisa, para poder comparar o antes e o depois.

CoreDash, acme-pagespeed.com, celular, p75 por página: uma página tem CLS de 0,92, enquanto as outras têm 0.

Quanto tempo até o Search Console mostrar a correção?

O PageSpeed Insights e o Search Console mostram os últimos 28 dias, e essa janela avança todo dia. No PageSpeed Insights, os dados têm cerca de dois dias de atraso; no Search Console, alguns dias a mais. Duas semanas após a correção, metade das visitas nessa janela ainda é de antes do ajuste. Depois de quatro semanas, ela contém apenas visitas posteriores à correção. O artigo A janela de 28 dias, dia a dia traz a linha do tempo completa.

Search Console, relatório de Core Web Vitals, celular, em 26 de outubro de 2026: última atualização em 21 de outubro.

O relatório CrUX History mostra a mesma janela por semana: cada barra cobre os 28 dias anteriores, então uma correção leva cerca de quatro barras para aparecer por completo.

Relatório CrUX History para ado-goldkante.de, celulares, LCP: a proporção de carregamentos bons, que precisam de melhoria e ruins por semana. Após uma alteração em meados de agosto, a parcela boa sobe de 59% ao longo de quatro barras para 76%, 83%, 90% e 93%, e o p75 do LCP vai de 3,6 s para 1,5 s.

Com a correção no ar, abra o problema no relatório de Core Web Vitals do Search Console e clique em Start Tracking (também chamado de Validate fix). Isso inicia a verificação de 28 dias do próprio Search Console para cada URL com essa falha, usando a mesma field data. Durante o processo, o status fica como Started e depois muda para Looking good se todas as URLs verificadas até ali estiverem em ordem. O status final é Passed se nenhuma URL apresentar o problema por 28 dias, ou Failed se alguma ainda tiver; aí você corrige a falha e clica em Start new validation.

Como saber se uma correção funcionou para os visitantes reais?

Verifique nesta ordem, começando pelo mais rápido:

1. A mudança está no ar. Veja o código-fonte da página ou encontre o arquivo ou cabeçalho no painel Network do DevTools. Se você ainda vir a versão antiga, um plugin de cache ou a CDN está entregando a página antiga.
2. O Lighthouse passa. Celular, três execuções, o resultado do meio (como vimos acima): o aviso passa para Passed audits.
3. Os visitantes recebem a mudança. No CoreDash, logo nas visitas seguintes: filtre a página ou o template alterado, defina o dispositivo como celular e acompanhe a métrica dia a dia e o elemento por trás dela.
4. O CrUX acompanha. A field data no PageSpeed Insights e as barras no relatório CrUX History se movem aos poucos. O impacto total só aparece depois de quatro semanas (por que demora tanto).
5. O Search Console confirma. No relatório de Core Web Vitals, clique em Start Tracking no problema e aguarde o status Passed.

O Lighthouse passa, quatro semanas se passaram e a sua field data ainda não saiu do lugar? Então as visitas lentas são aquelas que o Lighthouse nunca faz: um celular mais barato, um clique demorado, um deslocamento no meio da página. Em uma Core Web Vitals power hour, analiso a sua field data com você, grupo de páginas por grupo de páginas, até descobrirmos qual página e qual elemento estão segurando o seu p75.