O que são os Core Web Vitals? LCP, INP e CLS explicados (2026)

O que são os Core Web Vitals?

Cada Core Web Vital cobre um momento da visita. Os dados vêm de usuários reais do Chrome:

• Carregamento (LCP): quanto tempo leva até o conteúdo principal aparecer na tela
• Interatividade (INP): quanto tempo a página leva para reagir a um clique, toque ou tecla pressionada
• Estabilidade (CLS): o quanto o conteúdo se mexe durante o carregamento

O conjunto de métricas muda. Em março de 2024, o INP substituiu o First Input Delay (FID). O FID media apenas a espera antes de a primeira interação começar a ser processada. O INP mede todas as interações do início ao fim, e muito mais sites são reprovados nele.

Quando você passa nos Core Web Vitals?

O Google classifica cada métrica como Bom, Precisa de melhorias ou Ruim. Você passa quando pelo menos 75% das visitas à página no CrUX têm LCP bom, INP bom e CLS bom. O Google analisa a URL primeiro. Se a URL tiver pouco tráfego, ele faz fallback para um grupo de URLs parecidas ou para a origem inteira. O PageSpeed Insights mostra o resultado logo no topo da página: "Core Web Vitals Assessment: Passed" ou "Failed".

Por que o percentil 75?

A mediana só mostra a metade mais rápida dos visitantes. Um percentil mais rigoroso faria algumas visitas em um trem com uma barra de sinal reprovarem a página inteira. O p75 fica no meio do caminho: três em cada quatro visitas precisam ser boas.

Seu notebook no Wi-Fi do escritório diz muito pouco. As visitas que decidem o p75 vêm dos celulares mais lentos em redes móveis.

As três métricas dos Core Web Vitals

Largest Contentful Paint (LCP): carregamento

O Largest Contentful Paint mede o carregamento: o tempo desde o início da navegação até o maior elemento no viewport ser renderizado.

Esse elemento precisa ter conteúdo: uma imagem (imagens de fundo e posters de vídeo também contam) ou um bloco de texto. Na maioria das páginas, o elemento LCP é a imagem hero ou o título principal.

O valor bom é abaixo de 2,5 segundos. No relatório do CrUX de agosto de 2026, 68,1% das origens atingiram essa marca, a menor taxa entre as três.

O LCP acompanha o que o visitante vê. Quando o maior elemento surge na tela, a maioria das pessoas acha que a página terminou de carregar, mesmo que ainda haja scripts carregando. A métrica foi criada para responder a uma pergunta: 'Quando o conteúdo de uma página fica visível?'.

Quando o elemento LCP demora a aparecer, o motivo costuma ser banal. loading="lazy" na imagem hero. Uma imagem hero configurada como background no CSS, fazendo o navegador descobri-la só depois que a folha de estilo chega. Um script de slider que precisa rodar antes de o primeiro slide aparecer. Corrija a descoberta primeiro. Depois, faça o preload da imagem se o HTML ainda a esconder, adicione fetchpriority="high" e reduza o tamanho do arquivo. O guia do Largest Contentful Paint detalha todas as quatro fases do LCP.

Interaction to Next Paint (INP): interatividade

O Interaction to Next Paint mede a interatividade: quanto tempo leva para a tela atualizar depois que o visitante clica, toca na tela ou pressiona uma tecla. Rolar a página e passar o mouse não contam.

Cada interação é cronometrada desde a entrada, passando pelo JavaScript disparado por ela, até o próximo frame na tela. A página fica com o tempo da interação mais lenta. Em páginas com muitas interações, o Google descarta um ponto fora da curva a cada 50 interações, o que equivale aproximadamente ao percentil 98.

Uma execução padrão do Lighthouse não consegue medir o INP. Ele carrega a página e nunca clica em nada. A métrica de lab data mais próxima é o Total Blocking Time. O INP costuma ser bem menor que o TBT, mas quando o TBT cai, o INP tende a acompanhar.

Muitas vezes, o manipulador de clique em si é rápido. A main thread é que está ocupada com outra coisa na hora do clique: um gerenciador de tags, um widget de chat ou um framework ainda em processo de hidratação. A maior parte desse JavaScript pode ser adiada ou agendada. 85,3% das origens tinham um INP bom em agosto de 2026, contra 87,2% em março (notas de versão do CrUX). Foi o único Core Web Vital que piorou no último ano. O guia do Interaction to Next Paint mostra como encontrar essas interações lentas.

Cumulative Layout Shift (CLS): estabilidade visual

O Cumulative Layout Shift mede a estabilidade visual: o quanto o conteúdo visível se move sem o visitante esperar por isso. Você vai tocar em um link e a página pula.

Cada deslocamento recebe uma pontuação: a fração de impacto (quanto do viewport é afetado) multiplicada pela fração de distância (a distância que o conteúdo se moveu em relação ao viewport). Deslocamentos que acontecem em sequência são somados em uma janela de sessão. O CLS da página é a sua pior janela de sessão.

As causas de sempre: imagens sem largura e altura; anúncios, banners de cookies e embeds que empurram o conteúdo para baixo quando chegam; e fontes da web mais largas ou mais altas que o fallback delas. Para fontes, hospede as fontes você mesmo e escolha a configuração correta de font-display. O CLS é a métrica em que a maioria dos sites se sai bem: 81,5% das origens tinham um CLS bom em agosto de 2026. Veja mais no guia do Cumulative Layout Shift.

Por que os Core Web Vitals importam?

• Os visitantes vão embora. Um botão que não faz nada por meio segundo recebe dois cliques e depois é abandonado. O Google reuniu estudos de caso de sites que corrigiram seus Core Web Vitals e conseguiram taxas de rejeição menores e mais conversões.
• Ranqueamento. Os Core Web Vitals são um fator de ranqueamento do Google. Um fator pequeno. Quando duas páginas são quase iguais, a mais rápida leva vantagem.
• Mobile. A maior parte do tráfego provavelmente vem do celular, e é onde as páginas falham. O Web Almanac 2025 (a edição mais recente) mostrou que 48% das páginas para celular passam, contra 56% no desktop.
• Google Ads. A experiência na página de destino faz parte do Índice de qualidade. Uma página de destino lenta puxa essa nota para baixo e cada clique fica mais caro.

O Google também documenta com precisão como cada métrica é calculada, chegando ao nível do código do navegador. Para um fator de ranqueamento, isso quase nunca acontece.

Estudo de caso da Vodafone

A Vodafone Itália melhorou o Largest Contentful Paint em 31% e obteve 8% mais vendas, 15% mais leads e uma taxa de carrinho por visita 11% melhor (fonte: estudo de caso no web.dev).

Field data vs. lab data

O field data (também chamado de Real User Monitoring ou dados de RUM) vem de visitantes reais, nos próprios dispositivos e redes deles. O conjunto de dados do CrUX do Google é composto por field data de usuários do Chrome que aceitaram compartilhar esses dados. Os Core Web Vitals são exclusivamente field data.

O lab data vem de um teste em um dispositivo simulado, em um ambiente fixo. O Lighthouse e o WebPageTest geram lab data. Um teste de laboratório dá quase o mesmo resultado a cada execução, o que é ótimo para depuração. Mas ele não diz o que os visitantes recebem de fato.

O Lighthouse marca 100, então por que não passo?

Porque o Google ranqueia com base no CrUX, e o Lighthouse testa uma única visita simulada. Os visitantes usam celulares Android baratos e Wi-Fi ruim de hotel, e clicam em elementos em que o Lighthouse nem toca. O INP sequer existe em uma execução do Lighthouse.

O CrUX indica aprovação ou reprovação por grupo de URLs. Para descobrir qual página, dispositivo e elemento causou a reprovação, eu uso Real User Monitoring: o CoreDash, que criei exatamente para isso. Ele divide os dados por dispositivo, país e modelo de página, apontando com precisão o elemento LCP ou a interação que está lenta.

Como medir os Core Web Vitals

Comparativo das ferramentas de medição

Dados do CrUX

O conjunto de dados do CrUX armazena os Core Web Vitals de todo site que tenha tráfego suficiente no Chrome. É a base de dados oficial do programa Web Vitals. Você pode acessá-la de algumas formas:

1. O CrUX Vis mostra a evolução das pontuações de uma origem ou URL nos últimos meses. Ele substituiu o antigo CrUX Dashboard no Looker Studio, descontinuado pelo Google no final de 2025.
2. O CrUX no BigQuery contém os dados no nível de origem de todos os sites do CrUX, com histogramas completos por métrica e atualizações mensais. Ótimo para comparar um site com os concorrentes.
3. A CrUX API fornece os dados por página ou origem, filtrados por tipo de dispositivo e métrica, para você integrar os números às suas próprias ferramentas.
4. O PageSpeed Insights mostra os dados do CrUX de uma URL logo acima de um relatório do Lighthouse. Ele abre direto na aba de celular. Fique nela: a aba de desktop costuma ficar verde e ilude as pessoas, fazendo parecer que o site passa.

Monitoramento com RUM

Os dados de RUM vêm de um script leve no seu próprio site que mede cada visita. Ele afere os mesmos Core Web Vitals que o CrUX, mas com os detalhes que o CrUX omite. O CrUX é anonimizado, para no nível da URL e analisa sempre os últimos 28 dias. O RUM mostra o dia de ontem, por página, dispositivo, país e navegador, além de apontar qual elemento causou o LCP lento ou o deslocamento de layout. Por isso a maioria dos profissionais que trabalham corrigindo Core Web Vitals usa RUM em conjunto com o CrUX.

Lighthouse

O Lighthouse não mede os Core Web Vitals. Ele carrega uma página, uma única vez, em um celular simulado com conexão limitada. Ele começa com o cache vazio, nunca navega para uma segunda página e nunca clica em nada.

Ainda assim, é a forma mais rápida de ver o que bloqueia a renderização, qual imagem é o elemento LCP e quais scripts ocupam a main thread. Mas pode ignorar metade da lista. Minificar CSS economiza alguns kilobytes e nenhum visitante vai notar.

Execute o teste no PageSpeed Insights, no Chrome DevTools ou com a ferramenta de linha de comando do Lighthouse.

Quantos sites passam?

A equipe do Chrome publica os números do CrUX todo mês, na segunda terça-feira, nas notas de versão do CrUX. Esta é a proporção de origens com pontuação boa, somando todos os dispositivos:

Compare o mesmo mês de ano para ano. Dezembro oscila todo ano (a equipe do Chrome observa isso desde o lançamento do CrUX), então um mês ruim quer dizer pouco. Para TTFB e FCP, que não constam nas notas de versão, veja o guia do Time to First Byte e o guia do First Contentful Paint.

Como melhorar os Core Web Vitals

Por onde eu começo: p75 de cada métrica no celular, depois o grupo de URLs apontado pelo Search Console e, por fim, a tendência. Uma queda brusca geralmente aponta para um deploy. Uma perda gradual costuma ser acúmulo de scripts de terceiros, uma tag por vez.

Qualquer release pode quebrar algo novamente, então continue de olho no field data depois que a correção entrar em produção. Além disso, as métricas afetam umas às outras. O font-display: swap coloca o texto na tela mais rápido, o que pode ajudar o LCP, mas se a fonte da web tiver um tamanho diferente do fallback, a troca causa um deslocamento de layout. Veja um guia para cada métrica:

• Como melhorar o Largest Contentful Paint
• Como melhorar o Interaction to Next Paint
• Como melhorar o Cumulative Layout Shift

Duas métricas de diagnóstico seguram o LCP:

• Time to First Byte (TTFB): o navegador não consegue começar a montar a página antes de o HTML chegar. Com um TTFB lento, conseguir um bom LCP é quase impossível. Fazer cache do HTML na sua CDN costuma ser o ganho mais rápido.
• First Contentful Paint (FCP): a primeira renderização de qualquer conteúdo. Até lá, o visitante fica olhando para uma tela em branco.

Para ver o passo a passo completo, use o Checklist dos Core Web Vitals.

Core Web Vitals no Search Console

O Google costumava agrupar os Core Web Vitals com HTTPS, compatibilidade com dispositivos móveis e intersticiais intrusivos sob o nome de "experiência na página". O Google removeu o relatório de Experiência na página do Search Console em novembro de 2024. O relatório dos Core Web Vitals continua lá, em "Experiência".

Esse relatório agrupa as URLs por modelo de página e mostra quais grupos passam. Ele cobre os últimos 28 dias; por isso, duas semanas após a publicação de uma correção, metade do que ele exibe ainda reflete o site antigo.