Core Web Vitals: o que são e como melhorar LCP, INP e CLS

Ricardo Nakamura

Escrito por

Tempo de leitura 8 min de leitura

Resumo rápido

  • Core Web Vitals são três métricas do Google que medem a experiência real de quem visita uma página: carregamento (LCP), resposta a interações (INP) e estabilidade visual (CLS).
  • Os limites atuais para uma página ser considerada “boa” são: LCP até 2,5 s, INP até 200 ms e CLS até 0,1, medidos no percentil 75 das visitas.
  • Desde 12 de março de 2024, o INP substituiu o antigo FID como métrica oficial de interatividade.
  • O Google usa sinais de experiência da página no ranqueamento, mas relevância vem antes: ter nota boa não garante a primeira posição.
  • O que vale é o dado de campo (usuários reais, relatório CrUX), não a nota de laboratório do Lighthouse.

O que são Core Web Vitals

Core Web Vitals são um conjunto de três métricas definidas pelo Google para medir, com dados de usuários reais, a qualidade da experiência de uma página em carregamento, interatividade e estabilidade visual. Em português, o termo às vezes aparece traduzido como “Métricas Essenciais da Web”, mas o próprio Search Console em português mantém o nome em inglês.

A ideia surgiu em 2020, dentro da iniciativa Web Vitals do Chrome. Antes dela, cada ferramenta de performance tinha seus próprios números, e era difícil saber o que realmente importava. O Google então escolheu um pequeno grupo de métricas que representam o que o usuário sente: a página aparece rápido? Responde quando eu clico? O conteúdo fica parado no lugar ou “pula” enquanto eu leio?

Três pontos ajudam a entender o conceito:

  • São métricas centradas no usuário. Não medem quanto pesa o site ou quantos arquivos ele carrega, e sim o efeito disso na experiência de quem está navegando.
  • São medidas no mundo real. A avaliação oficial usa dados de navegação de usuários do Chrome, e não um teste isolado no seu computador.
  • Fazem parte de algo maior. Elas são um dos componentes da chamada experiência da página, que também inclui HTTPS, boa exibição em celulares e ausência de intersticiais intrusivos.

As três métricas: LCP, INP e CLS

Cada métrica cobre um aspecto da experiência. Os limites abaixo são os da documentação oficial do web.dev e do relatório de Core Web Vitals do Search Console:

Métrica O que mede Bom Precisa melhorar Ruim
LCP (Largest Contentful Paint) Carregamento: tempo até o maior elemento visível (imagem de destaque, bloco de texto) aparecer na tela até 2,5 s de 2,5 s a 4 s acima de 4 s
INP (Interaction to Next Paint) Responsividade: tempo entre uma interação (clique, toque, tecla) e a próxima atualização visual da tela até 200 ms de 200 ms a 500 ms acima de 500 ms
CLS (Cumulative Layout Shift) Estabilidade visual: quanto o layout se desloca de forma inesperada até 0,1 de 0,1 a 0,25 acima de 0,25

LCP: a página parece carregada?

O LCP marca o momento em que o maior elemento da área visível termina de ser exibido. Em um blog, costuma ser a imagem de destaque ou o primeiro parágrafo. Em uma loja virtual, a foto do produto. É a métrica que mais se aproxima da sensação de “a página abriu”.

INP: a página responde quando eu interajo?

O INP observa todas as interações feitas durante a visita e reporta uma das mais lentas. Se o usuário clica em “adicionar ao carrinho” e nada acontece por meio segundo, o INP piora. Ele é mais exigente que o antigo FID, que media apenas o atraso da primeira interação.

CLS: o conteúdo fica parado no lugar?

O CLS soma os deslocamentos inesperados de layout. Sabe quando você vai clicar em um link e um banner carrega por cima, empurrando tudo para baixo? É isso que o CLS mede. O valor não é em segundos: é uma pontuação baseada em quanto da tela se moveu e a que distância.

A regra do percentil 75: para passar na avaliação, uma página precisa atingir o nível “bom” nas três métricas em pelo menos 75% das visitas, separando celular e desktop. Ou seja, não basta carregar rápido no seu computador com internet de fibra; precisa funcionar bem para a maioria dos visitantes reais.

Do FID ao INP: como as métricas evoluíram

As Core Web Vitals não são fixas. O Google tem um ciclo de vida para as métricas: elas começam como experimentais, passam por uma fase pendente de pelo menos seis meses e só então se tornam estáveis. Mesmo métricas estáveis podem ser substituídas se surgir algo melhor, e foi exatamente o que aconteceu com o FID.

2020

Em maio, o time do Chrome anuncia as Core Web Vitals (LCP, FID e CLS). No fim do mês, o Google informa que elas farão parte de um novo sinal de experiência da página na busca.

2021

A atualização de experiência da página começa a ser aplicada em meados de junho, com implementação gradual até o fim de agosto.

2022

O Chrome apresenta o INP como métrica experimental, para medir a responsividade ao longo de toda a visita.

2023

Em maio, o Google anuncia que o INP vai substituir o FID e o promove a métrica pendente.

2024

Em 12 de março, o INP se torna oficialmente uma Core Web Vital e o FID é removido do Search Console.

Core Web Vitals são fator de ranqueamento?

Sim, mas com nuances importantes. A documentação do Google afirma que seus sistemas centrais de ranqueamento buscam recompensar conteúdos que oferecem boa experiência da página, e recomenda fortemente que os sites tenham boas Core Web Vitals. Ao mesmo tempo, a mesma documentação deixa claro que:

  • Não existe um sinal único de “experiência da página”. Os sistemas avaliam um conjunto de sinais.
  • Nota boa não garante posição. Ter Core Web Vitals no verde no Search Console ou em ferramentas de terceiros não significa que a página vai ficar no topo.
  • Relevância vem primeiro. O Google sempre tenta mostrar o conteúdo mais relevante, mesmo que a experiência da página seja abaixo da média. A experiência pesa mais quando há várias páginas igualmente úteis disputando a mesma busca.

Na prática, Core Web Vitals funcionam como um critério de desempate e, principalmente, como fator de negócio. Uma página lenta perde visitantes antes mesmo de eles lerem o primeiro parágrafo, e isso afeta conversão, taxa de rejeição e até o CTR de quem volta para a página de resultados. Para entender como esses sinais se combinam com centenas de outros, veja o guia sobre o algoritmo do Google.

Atenção: o próprio Google desaconselha perseguir nota perfeita apenas por SEO. Sair de “ruim” para “bom” costuma trazer ganho real. Sair de 95 para 100 no PageSpeed Insights, quase nunca.

Como medir: dados de campo x dados de laboratório

Este é o ponto que mais confunde. Existem dois tipos de dado, e eles podem mostrar números bem diferentes:

Dados de campo Dados de laboratório
Origem Visitas reais de usuários do Chrome (Chrome User Experience Report, o CrUX) Teste simulado em um dispositivo e conexão definidos
Ferramentas Relatório de Core Web Vitals do Search Console, PageSpeed Insights (parte superior), CrUX, biblioteca web-vitals Lighthouse, Chrome DevTools, PageSpeed Insights (parte inferior)
Mede INP? Sim O Lighthouse não, porque não há interação real. Ele usa o Total Blocking Time (TBT) como aproximação
Para que serve Saber como a página está de verdade e o que o Google enxerga Diagnosticar causas e testar correções antes de publicar

O relatório do Search Console

O relatório de Core Web Vitals do Search Console usa dados do CrUX e agrupa URLs com experiência parecida (por exemplo, todas as páginas de produto). O status do grupo segue a pior métrica: se o CLS está ruim e o LCP precisa melhorar, o grupo aparece como “ruim”. Sites com pouco tráfego podem não ter dados suficientes; nesse caso, o relatório tenta usar os dados da origem inteira (o domínio) e, se nem isso existir, mostra que não há dados disponíveis.

Dica: use o PageSpeed Insights para uma URL específica e o Search Console para ver o site inteiro. Se a página não tem dados de campo, os testes de laboratório ainda ajudam a encontrar problemas, mas trate a nota como diagnóstico, não como veredito.

Como melhorar cada métrica

Comece pelos grupos de URLs marcados como “ruim” no Search Console, priorizando os modelos de página que recebem mais tráfego orgânico. Corrigir o template de produto, por exemplo, melhora centenas de páginas de uma vez.

Para melhorar o LCP

  1. Reduza o tempo de resposta do servidor
    Hospedagem lenta, ausência de cache e excesso de plugins aumentam o tempo até o primeiro byte (TTFB). Um CDN e cache de página costumam trazer o maior ganho inicial.
  2. Nunca use lazy loading na imagem principal
    A documentação do web.dev é direta: a imagem que forma o LCP não deve ter carregamento tardio. Reserve o loading="lazy" para imagens abaixo da dobra.
  3. Dê prioridade ao elemento de LCP
    Adicione fetchpriority="high" na imagem de destaque. Se ela é chamada via CSS ou JavaScript, use um <link rel="preload"> para que o navegador a descubra cedo.
  4. Otimize o peso das imagens
    Formatos modernos (WebP, AVIF), dimensões corretas e compressão adequada reduzem o tempo de download.

Para melhorar o INP

  1. Reduza o JavaScript na thread principal
    Scripts pesados de terceiros (chat, pixels, testes A/B, widgets) disputam o processador com as interações do usuário. Revise o que realmente precisa estar na página.
  2. Quebre tarefas longas
    Funções que rodam por centenas de milissegundos travam a resposta. Divida o processamento em partes menores para o navegador conseguir atualizar a tela entre elas.
  3. Dê retorno visual imediato
    Ao clicar, mostre algo na hora (um estado de carregamento, por exemplo) e deixe o processamento pesado para depois.

Para melhorar o CLS

  1. Defina largura e altura em imagens e vídeos
    Com as dimensões declaradas, o navegador reserva o espaço antes de o arquivo chegar.
  2. Reserve espaço para anúncios e banners
    Blocos que aparecem depois do carregamento são a causa mais comum de CLS alto. Use contêineres com altura mínima.
  3. Cuidado com fontes web
    A troca da fonte padrão pela fonte personalizada pode deslocar o texto. Pré-carregue as fontes principais e ajuste a estratégia de exibição.

Erros comuns ao otimizar

  • Olhar só a nota do PageSpeed: a pontuação de 0 a 100 é do Lighthouse, um teste de laboratório. O que o Google avalia são as métricas de campo.
  • Testar apenas no desktop: o Google usa a versão mobile do site como base para a indexação, e é no celular que as métricas costumam ser piores.
  • Acumular plugins de “otimização”: no WordPress, empilhar plugins de cache, minificação e imagens pode gerar conflitos e piorar o resultado.
  • Esquecer os scripts de terceiros: ferramentas de marketing adicionadas pelo gerenciador de tags costumam ser as maiores vilãs do INP, e ninguém revisa.
  • Bloquear recursos importantes: CSS e JavaScript bloqueados no robots.txt impedem o Google de renderizar a página corretamente.
  • Esperar resultado imediato: o relatório do Search Console usa uma janela móvel de 28 dias. Depois de uma correção, os números mudam aos poucos.

Core Web Vitals na era da busca com IA

Os AI Overviews e o Modo IA do Google se apoiam nos mesmos sistemas de ranqueamento e no mesmo índice da busca tradicional. Na lista de boas práticas que o Google publicou para os recursos de IA, oferecer uma boa experiência da página aparece ao lado de permitir o rastreamento e manter o conteúdo importante em texto. Não existe uma métrica de performance “especial” para aparecer nas respostas de IA. Veja como esses recursos funcionam em SEO para AI Overviews e Modo IA.

Há ainda um argumento de negócio: quando a resposta da IA já resolve parte da dúvida (o fenômeno da busca zero clique), o clique que chega ao site tende a ser de alguém mais decidido. Perder esse visitante por causa de uma página lenta custa mais caro do que antes. Se você trabalha a visibilidade em ChatGPT, Perplexity e outros buscadores generativos, a performance continua sendo a base técnica de qualquer estratégia de GEO (Generative Engine Optimization).

Perguntas Frequentes

Quais são as Core Web Vitals atuais?

São três: LCP (Largest Contentful Paint), que mede o carregamento; INP (Interaction to Next Paint), que mede a responsividade; e CLS (Cumulative Layout Shift), que mede a estabilidade visual. O INP substituiu o FID em 12 de março de 2024.

Qual é a nota ideal no PageSpeed Insights?

Não existe nota exigida pelo Google. A pontuação de 0 a 100 vem do Lighthouse, um teste de laboratório. O que importa é passar nas três métricas de campo: LCP até 2,5 s, INP até 200 ms e CLS até 0,1 no percentil 75.

Meu site tem pouco tráfego e não aparece no relatório. E agora?

Sem visitas suficientes, o CrUX não gera dados de campo para as URLs. Nesse caso, use testes de laboratório (Lighthouse, PageSpeed Insights) para diagnosticar problemas e, se quiser dados reais, instale a biblioteca web-vitals para coletar as métricas dos seus próprios visitantes.

Melhorar as Core Web Vitals aumenta o tráfego?

Pode ajudar, principalmente quando a página está em “ruim” e disputa com concorrentes de conteúdo parecido. Mas o efeito no ranqueamento costuma ser menor do que o de relevância e qualidade do conteúdo. O ganho mais certo aparece em conversão e engajamento.

Quanto tempo leva para o Search Console mostrar a melhora?

Os dados do relatório consideram os últimos 28 dias de visitas. Depois de publicar uma correção, espere algumas semanas para ver o efeito completo. Na página do problema, clique em “Iniciar rastreamento” para validar a correção: o Search Console acompanha os dados do CrUX por quatro semanas antes de considerar o problema resolvido.

Sobre o autor

Ricardo Nakamura

Ricardo Nakamura lidera o SEO Next+ da Oxigenweb, departamento dedicado a SEO e GEO (Generative Engine Optimization). Há mais de 5 anos conduz projetos digitais de ponta a ponta para marcas como JBS, Grupo Petrópolis, Caloi e Lufthansa City Center. Escreve sobre processos escaláveis de SEO, busca orientada por IA e como transformar otimização em resultado de negócio.

Ver perfil e todos os artigos de Ricardo →

Deixe seu comentário

três + doze =