Core Web Vitals explicadas: LCP, INP e CLS (e como melhorá-las)

As Core Web Vitals são três métricas que o Google usa para medir a experiência real em uma página: a rapidez com que ela carrega, a rapidez com que responde e a estabilidade dela durante o carregamento. Elas fazem parte dos sinais de experiência na página que o Google considera no ranqueamento e – o mais importante – refletem como os visitantes realmente percebem o seu site.

As três Core Web Vitals

Uma página é aprovada quando pelo menos 75% das visitas reais (o percentil 75) atingem o limite “bom” nas três métricas.

O INP substituiu o First Input Delay (FID) como Core Web Vital em março de 2024. O INP é mais rigoroso: considera a capacidade de resposta das interações durante toda a visita, e não apenas da primeira.

Dados de campo vs. dados de laboratório

Os dados de campo vêm de usuários reais do Chrome e são coletados no Chrome UX Report (CrUX) em uma janela móvel de 28 dias. É isso que o Google usa para a experiência na página. Você pode vê-los no relatório de Core Web Vitals do Search Console e no PageSpeed Insights.

Os dados de laboratório vêm de um teste simulado, como o Lighthouse, em um dispositivo e uma rede fixos. São ótimos para depurar e testar mudanças, mas não são o que o Google usa para ranquear – e não conseguem medir o INP diretamente (o Total Blocking Time é o indicador de laboratório mais próximo).

Páginas com pouco tráfego podem não ter dados de campo suficientes; nesse caso, o Google pode usar dados de páginas semelhantes ou do site inteiro (a “origem”).

Largest Contentful Paint (LCP)

O LCP marca o momento em que a maior imagem ou o maior bloco de texto da área visível termina de ser renderizado – normalmente a imagem de destaque, um título grande ou a imagem de capa de um vídeo em destaque.

O LCP pode ser dividido em quatro partes, que indicam a correção:

1. Time to First Byte – quanto tempo o servidor leva para responder
2. Atraso no carregamento do recurso – quanto tempo passa até o navegador começar a baixar o recurso do LCP
3. Tempo de carregamento do recurso – quanto tempo o download leva
4. Atraso na renderização do elemento – o tempo entre o download e a renderização

Como melhorar o LCP

• Acelere o servidor: cache de páginas, uma CDN, hospedagem mais rápida e menos consultas ao banco de dados
• Faça a imagem do LCP ser descoberta cedo: use um <img> normal no HTML (e não um fundo em CSS ou uma imagem inserida por JavaScript) e adicione fetchpriority="high"
• Nunca aplique lazy loading à imagem do LCP
• Otimize a imagem: dimensões certas, WebP ou AVIF, boa compressão
• Reduza os recursos que bloqueiam a renderização: coloque o CSS crítico inline e adie o JavaScript não crítico
• Use preconnect para as origens de terceiros necessárias, como uma CDN de imagens

Interaction to Next Paint (INP)

O INP mede o atraso entre uma interação do usuário – um clique, um toque ou uma tecla pressionada – e a próxima atualização visual na tela. Ele informa uma das interações mais lentas da visita.

Um INP ruim normalmente vem de JavaScript demais rodando na thread principal, o que impede o navegador de responder rápido.

Como melhorar o INP

• Reduza e divida o JavaScript: remova bibliotecas não usadas, divida o código e carregue recursos só quando necessário
• Quebre tarefas longas: tarefas com mais de 50 ms bloqueiam a thread principal; devolva o controle ao navegador entre os blocos de trabalho
• Audite scripts de terceiros: gerenciadores de tags, widgets de chat, ferramentas de teste A/B e scripts de anúncios são culpados frequentes
• Mantenha o DOM enxuto: páginas muito grandes deixam cada atualização mais lenta
• Dê retorno visual imediato na interação e faça o trabalho pesado depois

Cumulative Layout Shift (CLS)

O CLS mede o movimento inesperado do layout – a experiência frustrante de um botão fugir bem na hora em que você vai tocá-lo. Ele pontua o quanto o conteúdo se move e a que distância.

Como melhorar o CLS

• Defina largura e altura em imagens e vídeos, ou use a propriedade CSS aspect-ratio, para que o espaço seja reservado
• Reserve espaço para anúncios, embeds e iframes com contêineres de tamanho fixo
• Evite inserir conteúdo acima do conteúdo existente, como banners que empurram a página para baixo depois do carregamento
• Use font-display: swap com cuidado e pré-carregue as principais fontes web, ou use métricas de fonte alternativa para o texto não se reorganizar
• Anime com transform, e não com propriedades como top ou height, que disparam um novo cálculo de layout

Um fluxo de trabalho prático

1. Confira o relatório de Core Web Vitals do Search Console para ver quais grupos de URLs reprovam e em qual métrica
2. Escolha uma URL representativa de cada grupo reprovado
3. Faça um teste de laboratório para diagnosticar o que está lento
4. Corrija no nível do template – a maioria dos problemas afeta todas as páginas que usam o mesmo layout
5. Valide: no Search Console, inicie a validação depois de publicar; os dados de campo levam até 28 dias para refletir as melhorias

Quanto as Core Web Vitals afetam o ranqueamento?

O Google deixou claro que a experiência na página é um sinal entre muitos e que a relevância e o conteúdo útil importam mais. Uma página rápida com conteúdo fraco não vai superar uma página excelente. Mas, quando as páginas são igualmente relevantes, uma experiência melhor pode ajudar – e páginas mais rápidas convertem consistentemente melhor, o que importa independentemente do ranqueamento.

Dicas por plataforma

WordPress

• Use um plugin de cache ou cache no nível da hospedagem para reduzir o tempo de resposta do servidor
• Escolha um tema leve; construtores de páginas pesados costumam adicionar muito CSS e JavaScript
• Audite os plugins: cada um pode adicionar scripts a todas as páginas, prejudicando o INP
• Use um plugin de otimização de imagens que sirva WebP ou AVIF e adicione os atributos de largura e altura
• Adie ou remova scripts de terceiros de que você não precisa em todas as páginas

Shopify

• Revise os aplicativos instalados – muitos inserem scripts em todas as páginas, mesmo quando não são usados
• Use os recursos de imagens responsivas nativos do tema
• Limite o número de seções e sliders na página inicial
• Comprima e redimensione as imagens antes de enviá-las

Sites sob medida e com muito JavaScript

• Use renderização no servidor ou geração estática para que o conteúdo apareça sem esperar o JavaScript
• Divida o código por rota e carregue os componentes sob demanda
• Meça o INP de usuários reais com a biblioteca JavaScript web-vitals e envie os dados ao analytics, para ver quais interações são lentas

Medindo os dados de usuários reais você mesmo

O Search Console e o PageSpeed Insights mostram dados agregados do Chrome, mas só para páginas com tráfego suficiente e com atraso. Para ver as Core Web Vitals de cada página e de cada visitante, adicione monitoramento de usuários reais (RUM). A biblioteca de código aberto web-vitals informa o LCP, o INP e o CLS a partir dos navegadores dos visitantes; você pode enviar os valores ao Google Analytics 4 ou a outra ferramenta de analytics. O RUM também registra qual elemento foi o LCP e qual interação foi a mais lenta – exatamente o que você precisa para corrigir o problema.

Uma observação sobre Total Blocking Time e Speed Index

O Lighthouse informa outras métricas além das Core Web Vitals. O Total Blocking Time (TBT) mede por quanto tempo a thread principal ficou bloqueada durante o carregamento e tem correlação com o INP. O First Contentful Paint (FCP) marca quando algo aparece pela primeira vez. O Speed Index mede a rapidez com que a área visível é preenchida. São diagnósticos úteis, mas não são Core Web Vitals.

Mitos comuns

• “É preciso ter nota 100 no PageSpeed para se posicionar.” Não. O que conta para a experiência na página é passar nos limites das Core Web Vitals nos dados de campo, e a relevância importa muito mais.
• “As Core Web Vitals só importam para o Google.” Páginas mais rápidas e estáveis melhoram as conversões e a satisfação de todos os visitantes, venham de onde vierem.
• “Adicionar mais plugins de cache ajuda.” Empilhar vários plugins de cache ou otimização costuma causar conflitos. Use uma única solução bem configurada.

Principais conclusões

• As Core Web Vitals medem o carregamento (LCP), a capacidade de resposta (INP) e a estabilidade visual (CLS).
• Os limites ideais são LCP ≤ 2,5 s, INP ≤ 200 ms e CLS ≤ 0,1 no percentil 75 das visitas reais.
• O que conta são os dados de campo de usuários reais do Chrome; os testes de laboratório servem para diagnosticar problemas.
• O LCP normalmente melhora com servidores mais rápidos e imagens de destaque mais bem otimizadas.
• O INP melhora quando você reduz e divide o JavaScript, principalmente os scripts de terceiros.
• O CLS melhora quando você reserva espaço para imagens, anúncios e embeds.

Perguntas frequentes

Por que as minhas notas de laboratório e de campo são diferentes?

Os testes de laboratório simulam um único dispositivo e uma única rede. Os dados de campo refletem os dispositivos, as redes e o comportamento dos seus visitantes reais, incluindo interações que os testes de laboratório não fazem.

Quanto tempo as melhorias levam para aparecer no Search Console?

Os dados de campo cobrem os 28 dias anteriores, então uma correção leva até quatro semanas para ser totalmente refletida.

As Core Web Vitals importam no desktop?

Sim. O Google avalia celular e desktop separadamente. No celular costuma ser mais difícil passar, porque os dispositivos e as redes são mais lentos.

Qual é uma boa nota no PageSpeed?

90 ou mais é bom. Mas a nota é um resumo de laboratório; o que conta para a experiência na página é passar nas Core Web Vitals nos dados de campo.