Lighthouse vs field data: verifique se o fix funcionou

O Lighthouse diz que está resolvido. Porque é que o Search Console continua vermelho?

O Lighthouse carrega a página uma vez, num telemóvel simulado, e indica o LCP e o CLS desse carregamento. Os seus Core Web Vitals são field data: o percentil 75 de 28 dias de visitas reais no Chrome, em telemóveis e redes rápidos e lentos, com a cache vazia e cheia, incluindo cada clique. Por isso, um fix pode passar hoje no Lighthouse e demorar quatro semanas a aparecer no Search Console. Compare três runs do Lighthouse e depois acompanhe a sua field data.

Como correr o Lighthouse para poder comparar o antes e o depois?

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

1. Limpe as caches. Esvazie a 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 mantenha-a. Sem código: PageSpeed Insights, no separador Mobile. Como developer: o painel Lighthouse no Chrome DevTools com o Device definido para Mobile, numa janela anónima, porque as extensões do browser adicionam scripts próprios à página.
3. Teste o URL que tinha o aviso. Se a alteração foi no template de produto, teste uma página de produto.
4. Corra três vezes e fique com o resultado do meio.
5. Olhe primeiro para o aviso e para a respetiva métrica. O aviso passa para Passed audits e a métrica em causa (LCP, CLS, Total Blocking Time) desce. O score fica para o fim.

Porque é que o score muda quando nada mudou?

Cada run é um carregamento e não há dois carregamentos iguais: o servidor responde mais rápido ou mais devagar, a rede varia e os anúncios, banners de consentimento e testes A/B podem diferir de run para run. Numa das minhas páginas de teste, o primeiro texto ou imagem (FCP) apareceu 1,5 s mais cedo numa run do que noutra; numa segunda página, o score foi de 96 ou 80 sem que nada tivesse mudado. Subir alguns pontos depois de um fix diz pouco até comparar o resultado do meio de três runs.

Seis runs seguidas no mesmo URL, www.bbc.com, obtiveram 38, 44, 41, 73, 60 e 53 em dois minutos. Lighthouse 13.5.0, mobile, throttling simulado como no PageSpeed Insights.

Gravar um trace no DevTools

Abra a página no Chrome, abra o DevTools e aceda ao painel Performance. Em Capture settings (o ícone da roda dentada), defina Network para Slow 4G e CPU para 4x slowdown, perto do que o Lighthouse simula em mobile; depois, clique em Record e recarregue a página. O separador Insights na barra lateral lista os mesmos insights do Lighthouse, cada um com os requests e elementos associados. Antes de gravar, o painel mostra o seu próprio LCP, CLS e INP em tempo real (o INP assim que clica na página). Clique em Set up sob Field metrics para ver ao lado os números do CrUX dos visitantes reais para o mesmo URL.

Porque é que o Lighthouse diz uma coisa e o Search Console outra?

O Lighthouse dá-lhe lab data: um único carregamento da página num telemóvel de gama média simulado, numa ligação 4G lenta e com a cache vazia. Para pouco depois do carregamento, pelo que nunca faz scroll, não toca no ecrã nem abre uma segunda página. Obtém o LCP e o CLS desse carregamento e nenhum INP, porque o INP precisa de um visitante que clique.

A field data é o que o Chrome mediu para os seus visitantes reais: telemóveis rápidos e lentos, redes boas e más, uma primeira visita com a cache vazia e a décima com tudo em cache, a fazer scroll, a tocar no ecrã e a navegar de página em página. A Google recolhe estes dados no Chrome UX Report (CrUX), a partir de utilizadores do Chrome em Android e desktop que partilham estatísticas de utilização. Os seus Core Web Vitals são essas visitas ao longo dos últimos 28 dias, no percentil 75 (p75) de cada métrica: três em cada quatro visitas foram pelo menos assim tão boas.

A Google usa a field data para o ranking. O Lighthouse serve para perceber porque é que uma página é lenta e se uma alteração ajuda. Quando os dois discordam, é porque mediram carregamentos diferentes. Um score verde no Lighthouse com má field data significa muitas vezes telemóveis mais lentos do que a simulação, respostas lentas aos cliques (INP) ou conteúdo que se desloca enquanto os visitantes fazem scroll. Um score vermelho com boa field data significa muitas vezes que os visitantes têm telemóveis e redes mais rápidos do que o 4G lento do Lighthouse e regressam com os ficheiros em cache.

Um relatório do PageSpeed Insights para www.bbc.com em mobile, a 26 de outubro de 2026. As visitas reais passam os três Core Web Vitals com um LCP de 1,2 s; a run do Lighthouse no mesmo relatório obtém 37 com um LCP de 9,5 s.

O PageSpeed Insights mostra a field data para o URL testado quando esse URL tem visitas suficientes, e para todo o site em Origin quando não tem. O Search Console agrupa URLs semelhantes e classifica cada grupo pela sua pior métrica.

Onde ver o que os visitantes obtiveram?

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

• PageSpeed Insights: a secção superior, "Descubra o que os seus utilizadores reais estão a experienciar", com LCP, INP e CLS no p75 dos últimos 28 dias, para o URL ou para a origem.
• Search Console: o relatório Core Web Vitals, para mobile e desktop, mostra que grupos de URLs semelhantes têm um desempenho fraco em todo o site.
• CrUX History report: uma barra por semana para o site ou para um URL, para poder ver a evolução.
• DevTools: o painel Performance coloca os mesmos números ao lado do seu próprio carregamento (configure uma só vez).

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

CoreDash: que página, que elemento

O CrUX, a field data da Google, dá-lhe um p75 por URL ou por site. O CoreDash, o real user monitoring que criei, é um script nas suas páginas que mede todas as visitas e identifica o elemento por trás de cada LCP, INP e CLS. Filtre por página, dispositivo e elemento, e qualquer alteração surge na série temporal logo a partir das visitas seguintes. Adicione o script antes de mudar o que quer que seja, para poder comparar o antes e o depois.

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

Quanto tempo demora até o Search Console mostrar o seu fix?

O PageSpeed Insights e o Search Console mostram os últimos 28 dias, e essa janela move-se todos os dias. No PageSpeed Insights os dados têm cerca de dois dias; no Search Console têm mais alguns dias. Duas semanas após o seu fix, metade das visitas nessa janela ainda são anteriores ao fix. Ao fim de quatro semanas, contém apenas visitas posteriores ao fix. A janela de 28 dias, dia a dia tem a cronologia completa.

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

O CrUX History report mostra a mesma janela por semana: cada barra cobre os 28 dias anteriores, pelo que um fix precisa de cerca de quatro barras para aparecer por completo.

CrUX History report para ado-goldkante.de, telemóveis, LCP: a proporção de carregamentos bons, a precisar de melhoria e fracos por semana. Após uma alteração em meados de agosto, a percentagem de bons sobe ao longo de quatro barras de 59% para 76%, 83%, 90% e 93%, e o p75 do LCP passa de 3,6 s para 1,5 s.

Quando o fix estiver em produção, abra o problema no relatório Core Web Vitals do Search Console e clique em Start Tracking (também chamado Validate fix). Isso inicia a verificação de 28 dias do próprio Search Console para cada URL com esse problema, com base na mesma field data. Durante o processo, o estado é Started e passa a Looking good assim que todos os URLs verificados até ao momento estejam corretos. Termina em Passed se nenhum URL tiver o problema durante 28 dias, ou em Failed se algum ainda o tiver; aí, corrija esse caso e clique em Start new validation.

Como saber se um fix funcionou para os visitantes reais?

Verifique por esta ordem, do mais rápido para o mais lento:

1. A alteração está em produção. Veja o código-fonte da página ou procure o ficheiro ou cabeçalho no painel Network do DevTools. Se ainda vir a versão antiga, um plugin de cache ou a CDN está a servir a página antiga.
2. O Lighthouse passa. Mobile, três runs, o resultado intermédio (como explicado acima): o aviso passa para Passed audits.
3. Chega aos visitantes. No CoreDash, logo a partir das visitas seguintes: filtre a página ou o template que alterou, selecione o dispositivo mobile e acompanhe a métrica dia a dia e o elemento associado.
4. O CrUX acompanha. A field data no PageSpeed Insights e as barras no CrUX History report mudam aos poucos. O impacto total surge ao fim de quatro semanas (porque demora tanto tempo).
5. O Search Console confirma. No relatório Core Web Vitals, clique em Start Tracking no problema e aguarde pelo estado Passed.

O Lighthouse passa, passaram quatro semanas e a sua field data continua sem mexer? Então essas visitas lentas são as que o Lighthouse nunca faz: um telemóvel mais barato, um clique lento, um salto no layout a meio da página. Numa Core Web Vitals power hour, analiso a field data consigo, grupo de páginas a grupo de páginas, até descobrirmos que página e que elemento estão a travar o seu p75.