Lighthouse, CrUX e RUM: qual dado de Core Web Vitals usar

Use o CrUX para saber se o site passa nas Core Web Vitals e para decidir o que atacar primeiro: é o dado de usuários reais do Chrome que o Google usa na Busca. Use o Lighthouse (ou a parte de laboratório do PageSpeed Insights) para reproduzir um problema e testar a correção antes de publicar. Use um RUM próprio quando precisar ver cada visita, cada página e a causa do número ruim, com recortes que o CrUX não oferece. A nota de 0 a 100 do Lighthouse não é uma Core Web Vital e não decide posição no Google.

Este artigo compara as três fontes. Para o básico sobre as métricas e como melhorar cada uma, veja o guia de Core Web Vitals.

Quais são as Core Web Vitals hoje

São três métricas, todas com status estável segundo o web.dev:

• LCP (Largest Contentful Paint, ou maior renderização de conteúdo) mede o carregamento. É o tempo até aparecer na tela a maior imagem, bloco de texto ou vídeo visível na janela (web.dev).

• INP (Interaction to Next Paint, ou interação até a próxima pintura) mede a resposta às ações do usuário. Ele observa a latência de cliques, toques e teclas durante toda a visita e, em geral, reporta a pior; em páginas com muitas interações, descarta a maior a cada 50 para não ser distorcido por casos isolados. Rolagem, hover e zoom não contam, e quem não interage com a página não gera INP (web.dev).

• CLS (Cumulative Layout Shift, ou deslocamento cumulativo de layout) mede a estabilidade visual. Os deslocamentos inesperados são agrupados em janelas (intervalos de menos de 1 segundo entre eles, até 5 segundos por janela), e o CLS é a maior dessas janelas ao longo de toda a vida da página (web.dev).

O INP substituiu o FID em março de 2024

O INP passou a ser Core Web Vital estável em março de 2024, no lugar do FID (First Input Delay). No mesmo anúncio, o Chrome passou a descontinuar o FID e deu até 9 de setembro de 2024 para quem lia FID das APIs do CrUX e do PageSpeed Insights migrar para o INP (web.dev). A biblioteca web-vitals removeu a função onFID() na versão 5.0.0, de maio de 2025 (changelog da web-vitals). Relatório que ainda trata o FID como Core Web Vital está desatualizado.

Os limites de "bom" e a regra do percentil 75

Uma página passa quando o percentil 75 dos carregamentos, separado entre celular e desktop, fica dentro do limite "bom" nas três métricas (web.dev). Em outras palavras: pelo menos três de cada quatro visitas precisam ter uma experiência boa. O PageSpeed Insights segue a mesma regra e só aprova a avaliação quando os três percentis 75 estão bons (documentação do PageSpeed Insights).

Fontes dos limites: PageSpeed Insights, LCP, INP, CLS, FCP e TTFB.

FCP e TTFB ajudam no diagnóstico, mas não são Core Web Vitals

O FCP (First Contentful Paint, ou primeira renderização de conteúdo) marca o momento em que aparece na tela a primeira parte do conteúdo: texto, imagem, SVG ou canvas não branco (web.dev). O TTFB (Time to First Byte, ou tempo até o primeiro byte) soma redirecionamentos, início do service worker, consulta de DNS, conexão e negociação TLS até a chegada do primeiro byte da resposta (web.dev).

O web.dev trata as duas como métricas de apoio, úteis para entender um LCP alto (web.dev). O próprio artigo sobre TTFB diz que, como ele não é Core Web Vital, não é obrigatório ficar dentro do limite "bom", desde que o TTFB não impeça boas notas nas métricas que contam (web.dev). No CrUX, o TTFB ainda aparece como experimental: na API, o nome é experimental_time_to_first_byte (CrUX API).

Três fontes de dados que respondem a perguntas diferentes

Laboratório: Lighthouse e a parte de diagnóstico do PageSpeed Insights

Dado de laboratório (também chamado de sintético) vem de um carregamento simulado em ambiente controlado. No PageSpeed Insights, essa parte é feita pelo Lighthouse: no celular, ele simula um aparelho de gama média numa rede móvel; no desktop, um computador com conexão cabeada (PageSpeed Insights). É uma única carga, com um aparelho e uma rede fixos.

O Lighthouse não mede INP, porque não há ninguém clicando na página. O substituto no laboratório é o TBT (Total Blocking Time, ou tempo total de bloqueio), que mede quanto a thread principal fica travada durante o carregamento (web.dev). TBT bom não garante INP bom: ele deixa de fora, por exemplo, o atraso do toque (web.dev).

A nota de desempenho, de 0 a 100, é uma média ponderada de cinco métricas. Pelos pesos que a documentação publica para o Lighthouse 10, o TBT vale 30%, LCP e CLS valem 25% cada, e FCP e Speed Index valem 10% cada. Cada métrica vira pontos a partir de uma curva log-normal tirada de dados reais do HTTP Archive. A nota varia entre execuções, e a documentação atribui boa parte dessa variação a mudanças nas condições do teste, e não ao Lighthouse em si (documentação do Lighthouse).

Campo: Chrome UX Report (CrUX)

O CrUX é o conjunto público de dados de usuários reais do Chrome mantido pelo programa Web Vitals. Segundo o Chrome, ele é usado pela Busca do Google no fator de classificação de experiência da página (CrUX). É o mesmo dado que aparece na parte de campo do PageSpeed Insights e no relatório Core Web Vitals do Search Console (ajuda do Search Console).

Só entram usuários do Chrome que ativaram o envio de estatísticas de uso, sincronizam o histórico e não usam senha própria para criptografar a sincronização. Vale para o Chrome no desktop (Windows, macOS, ChromeOS e Linux) e no Android, incluindo Custom Tabs e WebAPKs. Ficam de fora o Chrome no iOS, apps Android que abrem páginas em WebView e outros navegadores baseados em Chromium, como o Edge. O Google não publica que fração dos usuários atende a esses critérios (metodologia do CrUX).

A origem e cada página precisam ser publicamente detectáveis, pelos mesmos critérios de indexação de buscadores (status 200 depois dos redirecionamentos, sem noindex), e "suficientemente populares". O número mínimo de visitantes não é divulgado (metodologia do CrUX). Por isso, páginas com pouco tráfego, área logada e ambientes de homologação ficam sem dado de campo.

O dado de origem junta todas as páginas da origem; o de URL mostra só aquela página (CrUX API). Quando a URL não tem dados suficientes, o PageSpeed Insights mostra os da origem, e se nem a origem tiver, não mostra dado de campo (PageSpeed Insights).

Os valores são uma média móvel dos últimos 28 dias, e cada forma de acesso atualiza num ritmo diferente:

• A CrUX API atualiza todo dia, por volta das 04:00 UTC, sem garantia de horário, e fica cerca de dois dias atrás da data atual (CrUX API).

• A CrUX History API atualiza às segundas e guarda até 40 períodos semanais, cada um com 28 dias de dados (CrUX History API).

• O BigQuery recebe uma tabela por mês, publicada na segunda terça-feira do mês seguinte, só com dados de origem e histórico desde 2017. É a única forma de acesso com a dimensão de país (CrUX no BigQuery, comparação de ferramentas).

RUM próprio: medir cada visita no seu site

RUM (real-user monitoring, ou monitoramento de usuários reais) é um script instalado no site que mede as métricas no navegador de cada visitante e envia os valores para um servidor seu ou de um fornecedor. Uma forma de medir com as mesmas regras do Chrome é a biblioteca web-vitals, do time do Chrome, que segundo o README mede as métricas do mesmo jeito que o Chrome e as ferramentas do Google. Ela tem as funções onLCP, onINP, onCLS, onFCP e onTTFB e ocupa cerca de 3 KB com compressão brotli. A versão mais recente no momento em que este texto foi escrito é a 6.2.3, de 5 de outubro de 2026 (changelog).

O que um RUM entrega e o CrUX não:

• Dados de qualquer página que tenha o script, inclusive as que não chegam ao mínimo de tráfego do CrUX e as que não são públicas, sem esperar uma janela de 28 dias.

• A causa do número. A versão de atribuição (web-vitals/attribution, cerca de 1,5 KB a mais) acrescenta a cada métrica o elemento e as fases do tempo. No LCP, vêm o seletor do elemento e as quatro partes do tempo; no INP, o elemento da interação, as três fases e as entradas de Long Animation Frames (quadros de animação longos, que apontam os scripts envolvidos); no CLS, o elemento que mais se deslocou e em que fase do carregamento isso aconteceu (README da web-vitals).

• Recortes por tipo de página, dispositivo, conexão, país ou qualquer outro dado que você enviar junto (web.dev).

• Outros navegadores: onLCP, onINP, onFCP e onTTFB funcionam em Chromium, Firefox e Safari; onCLS, só em Chromium (README da web-vitals).

A documentação aponta alguns cuidados. Os dados devem ser enviados no evento visibilitychange, quando a página fica oculta, com navigator.sendBeacon(), porque unload e beforeunload não são confiáveis. CLS e INP só fecham o valor quando a página é escondida, e a mesma métrica pode ser reportada mais de uma vez (README, web.dev). Para resumir, use percentis em vez de médias (web.dev). Banners de consentimento e bloqueadores tiram visitas da amostra, às vezes justamente o primeiro carregamento, que costuma ser o mais lento, e uma taxa de amostragem baixa demais distorce os números (web.dev).

SPAs e navegações suaves: o que mudou em 2026

Em sites de página única (SPA), trocar de rota sem recarregar a página é uma navegação suave (soft navigation). As APIs do navegador não tratavam essa troca como navegação, e o CrUX não a contava (web.dev). A partir do Chrome 151, dá para medir: uma navegação suave é registrada quando há uma interação do usuário, a URL muda e algo é pintado na tela. A web-vitals passou a suportar isso na versão 6.0.0, de julho de 2026, com a opção reportSoftNavs: true (README, changelog).

A própria biblioteca lista as ressalvas. A definição pode gerar falsos positivos. O TTFB de uma navegação suave sai como 0. Elementos que continuam na tela entre rotas não contam para o LCP, porque não são pintados de novo. INP e CLS recomeçam a cada navegação suave. Ligar a opção muda também a medição do primeiro carregamento, e navegadores fora do Chromium continuam reportando só carregamentos completos (README da web-vitals).

No CrUX, versões experimentais de LCP, INP e CLS com navegações suaves (por exemplo, experimental_interaction_to_next_paint_with_softnavs) começaram a sair em outubro de 2026 na API, na History API e no BigQuery. As Core Web Vitals estáveis não mudaram. O Chrome pretende tirar as novas métricas do status experimental em maio de 2027, dependendo do retorno que receber, e só depois disso o Search Console passa a usá-las. Segundo o anúncio, a diferença se concentra em SPAs com muitas navegações depois da primeira; na maioria dos sites, os números devem mudar pouco ou nada (web.dev, web.dev).

Comparação entre laboratório, CrUX e RUM

Por que a nota do Lighthouse não bate com os dados de campo

O web.dev lista os motivos (web.dev):

• O laboratório usa um aparelho, uma rede e um local. Seus usuários usam muitos, e o percentil 75 do campo reflete essa mistura.

• O teste de laboratório costuma carregar a página com cache vazio. Quem volta ao site já tem arquivos em cache e vê a página mais rápido.

• O elemento de LCP do teste pode não ser o mesmo que o usuário vê. Tamanho de tela, personalização e testes A/B mudam qual é o maior elemento.

• No campo, o navegador para de procurar elementos maiores assim que o usuário rola ou interage, o que pode dar um LCP menor.

• No campo, o CLS conta os deslocamentos durante toda a visita. O laboratório pega quase só o que acontece no topo da página durante o carregamento, e perde, por exemplo, imagens e iframes sem dimensões que só carregam quando o usuário rola.

• Anúncios segmentados e testes A/B mudam o que é carregado para cada pessoa.

A recomendação do próprio web.dev é usar o dado de campo para definir prioridades e o de laboratório para depurar e testar antes de publicar (web.dev).

Nota boa no Lighthouse não garante posição no Google

O que a Central da Pesquisa diz (experiência na página, Core Web Vitals na Busca):

• As Core Web Vitals são usadas pelos sistemas de classificação, mas não existe um único sinal de experiência na página.

• Bons resultados no relatório do Search Console ou em ferramentas de terceiros não garantem que as páginas fiquem no topo da Busca.

• A Busca procura mostrar o conteúdo mais relevante, mesmo quando a experiência na página está abaixo do ideal.

• Buscar nota perfeita só por causa de SEO pode não ser o melhor uso do seu tempo.

O relatório Core Web Vitals do Search Console vem do CrUX (ajuda do Search Console), não da nota do Lighthouse. O que aparece ali é a experiência dos usuários reais, e não o resultado de um teste de laboratório.

Qual dado usar para cada decisão

A tabela abaixo é uma recomendação nossa, montada a partir das características de cada fonte descritas acima.

Quando a tabela não se aplica: se o site não tem dado no CrUX e você ainda não instalou um RUM, o laboratório é o único sinal disponível. Nesse caso, use-o para achar problemas óbvios, sabendo que ele não diz se os usuários passam nos limites.

Como achar a causa de LCP, INP e CLS ruins

O caminho recomendado pelo Google começa no campo e depois vai para o laboratório: se há dado do CrUX, olhe primeiro para os usuários reais (web.dev); para o INP, colete dados de campo, reproduza a interação lenta no laboratório e só então otimize (web.dev). Abaixo, o resumo de como cada métrica se divide. Cada uma tem um artigo próprio com as correções.

LCP: as quatro partes do tempo

1. TTFB: do início do carregamento até a chegada do primeiro byte. Referência do Google: cerca de 40% do LCP.

2. Atraso de carregamento do recurso: do TTFB até o navegador começar a baixar o recurso do LCP (a imagem, por exemplo). Menos de 10%.

3. Duração do carregamento do recurso: o tempo para baixar esse recurso. Cerca de 40%.

4. Atraso de renderização do elemento: do fim do download até o elemento aparecer por completo. Menos de 10%.

O web.dev chama essas proporções de referência, não de regra (web.dev). A CrUX API já traz, para LCPs de imagem, essas quatro partes e o tipo de recurso do LCP; o BigQuery não tem esses dados (CrUX API, comparação de ferramentas). As correções de cada parte estão em como melhorar o LCP.

INP: as três fases da interação

1. Atraso de entrada: do momento da interação até os callbacks do evento começarem a rodar. Cresce quando a thread principal está ocupada com outros scripts.

2. Tempo de processamento: quanto os callbacks do evento levam para terminar.

3. Atraso de apresentação: do fim dos callbacks até o navegador pintar o próximo quadro com o resultado.

O web.dev sugere reproduzir a interação lenta no laboratório interagindo com a página durante o carregamento, quando a thread principal costuma estar mais ocupada (web.dev). No RUM, a atribuição da web-vitals informa a duração de cada fase e as entradas de Long Animation Frames ligadas à interação (README). O passo a passo está em como melhorar o INP.

CLS: o elemento que se mexe

As fontes mais comuns, segundo o web.dev, são imagens, anúncios, embeds e iframes sem dimensões, conteúdo injetado depois do carregamento, fontes web e animações de propriedades como top e left em vez de transform. Deslocamentos que acontecem até 500 ms depois de um clique, toque ou tecla são tratados como esperados e não contam. Deixar a página apta ao cache de voltar e avançar (bfcache) evita que deslocamentos se repitam quando o usuário volta (web.dev, web.dev).

Para achar o elemento: no campo, a atribuição da web-vitals informa o elemento que mais se deslocou; no laboratório, o painel Performance do DevTools mostra os registros de deslocamento, e o Lighthouse lista os elementos que se moveram e as imagens sem largura e altura (web.dev). Mais detalhes em como corrigir o CLS.

Por que CrUX e RUM nunca batem exatamente

Mesmo medindo usuários reais, as duas fontes cobrem populações e janelas diferentes: o CrUX é só Chrome e só usuários elegíveis; o RUM depende de consentimento, de amostragem e do momento em que o script envia os valores. O web.dev considera normais diferenças pequenas e sugere, para comparar, filtrar o RUM para Chrome, o mesmo tipo de dispositivo, o percentil 75 e uma janela de 28 dias. Para o uso do dia a dia, a orientação é olhar a tendência depois de cada mudança, sem esperar que os números coincidam (web.dev).

Recomendações práticas

O que segue é opinião nossa, apoiada nos fatos acima.

1. Comece pelo relatório Core Web Vitals do Search Console ou pela parte de campo do PageSpeed Insights. É o dado que mostra se o site passa nos limites.

2. Se o site ou as páginas que importam não têm dado no CrUX, instale um RUM antes de gastar tempo tentando subir a nota do Lighthouse.

3. No RUM, use a versão de atribuição da web-vitals e envie junto o tipo de página (produto, categoria, artigo). Assim dá para ver se o problema é de um modelo de página inteiro ou de uma URL isolada. Para fazer isso em muitos sites ao mesmo tempo, veja como monitorar a performance de vários sites.

4. Use o Lighthouse para testar correções, rodando mais de uma vez antes e depois. Uma execução isolada não basta para concluir nada.

5. Se o site é uma SPA, o próprio Google sugere começar a medir as Core Web Vitals por rota desde já (web.dev). Isso mostra antes o que pode mudar quando as métricas com navegações suaves deixarem de ser experimentais.

Essas recomendações não se aplicam a quem precisa da nota do Lighthouse por contrato ou por exigência de um cliente. Nesse caso, a nota é o requisito, mesmo sem efeito direto na Busca.

Como medir no WebVyze

O teste de Core Web Vitals é grátis e mostra os dados do CrUX dos últimos 28 dias, no celular e no desktop, para até 10 URLs. Os diagnósticos grátis de LCP, CLS e INP usam o Google PageSpeed. Os planos pagos, a partir do Starter, incluem um script de visitantes reais que mede LCP, INP e CLS de cada visita com a biblioteca web-vitals do Google e aponta o elemento ou a causa.