Core Web Vitals Explicado sem Enrolação: O Que Muda no Ranking

Se você já abriu o Google Search Console e viu um aviso de "problema de Core Web Vitals" sem entender direito o que aquilo significa na prática, você não está sozinho. São três siglas técnicas — LCP, INP e CLS — que resumem uma pergunta simples: a experiência de quem visita sua página é rápida e estável, ou é frustrante?

Vamos direto ao ponto, sem embromation.

O que são, na prática

LCP (Largest Contentful Paint) — velocidade de carregamento

Mede quanto tempo leva até o maior elemento visível da tela (geralmente uma imagem grande, um vídeo ou um bloco de texto grande) terminar de aparecer. É a métrica mais próxima de "a página carregou, dá pra usar".

Meta: até 2,5 segundos é bom. De 2,5 a 4 segundos precisa melhorar. Acima de 4 segundos é ruim.

INP (Interaction to Next Paint) — responsividade

Mede o tempo entre você clicar, tocar ou digitar algo na página e a tela responder visualmente a essa ação. Substituiu o antigo FID (First Input Delay) em março de 2024 — se você ainda vê algum guia por aí falando de FID, está desatualizado.

Meta: até 200 milissegundos é bom. De 200 a 500ms precisa melhorar. Acima de 500ms é ruim. É considerada a métrica mais difícil de resolver, porque o problema geralmente é JavaScript pesado travando a resposta da página, não um ajuste simples de configuração.

CLS (Cumulative Layout Shift) — estabilidade visual

Mede o quanto os elementos da página "pulam de lugar" enquanto ela carrega — aquele clássico de tentar clicar em um botão e, no último milissegundo, um banner carregar e empurrar tudo pra baixo, fazendo você clicar em outra coisa por acidente.

Meta: até 0,1 é bom. De 0,1 a 0,25 precisa melhorar. Acima de 0,25 é ruim.

O detalhe que a maioria dos guias ignora: são dados reais, não teste de laboratório

Aqui está o ponto mais importante e menos falado: o Google não avalia essas métricas rodando um teste no seu computador. Ele usa o CrUX (Chrome User Experience Report) — dados coletados de visitantes reais, no dispositivo real deles, na conexão real deles, ao longo de uma janela móvel de 28 dias.

Isso significa que rodar o Lighthouse no seu notebook rápido, com internet boa, e ver nota máxima não garante nada sobre como o site se comporta pra alguém acessando de um celular intermediário numa conexão 4G mais lenta. A página só "passa" quando pelo menos 75% das visitas reais registram experiência boa em cada uma das três métricas — não é média, é o percentil 75.

Isso afeta ranking mesmo, ou é só teoria?

Sim, é um sinal de ranking confirmado oficialmente pelo Google — mas funciona mais como critério de desempate entre páginas de relevância parecida do que como fator que sozinho decide quem fica em primeiro lugar. Se duas páginas respondem igualmente bem à mesma busca, a mais rápida e estável tende a levar vantagem.

O impacto que realmente move o ponteiro, na prática, costuma ser outro: conversão. Página lenta ou instável aumenta taxa de rejeição e derruba conclusão de formulário, checkout, cadastro — isso afeta o negócio direto, com ou sem Google no meio.

Como corrigir cada uma, na ordem certa

Não tente resolver as três ao mesmo tempo. A prioridade recomendada é: primeiro conserte a que estiver na faixa "ruim", depois ataque INP (a mais difícil), depois LCP (maior impacto comercial direto), depois CLS (geralmente a mais fácil de resolver).

Pra melhorar LCP

• Comprima e sirva imagens em formato moderno (WebP ou AVIF) em vez de JPEG/PNG sem otimização
• Priorize o carregamento da imagem principal da página (a que provavelmente é o elemento LCP) em vez de deixá-la competir com outros recursos
• Reduza tempo de resposta do servidor — hospedagem lenta prejudica todas as outras otimizações
• Elimine recursos que bloqueiam a renderização antes do conteúdo principal aparecer

Pra melhorar INP

• Reduza JavaScript que roda no carregamento inicial — cada tarefa que trava a thread principal por mais de 50 milissegundos atrapalha a resposta a cliques
• Divida scripts grandes em pedaços menores carregados sob demanda
• Use defer ou async em scripts que não são críticos pro primeiro momento da página
• Revise scripts de terceiros (chat, analytics, anúncios) — são causa frequente de INP ruim

Pra melhorar CLS

• Sempre defina largura e altura em imagens e vídeos, pra o navegador já reservar o espaço antes de carregar
• Reserve espaço fixo pra anúncios, embeds e iframes — nunca deixe eles "empurrarem" conteúdo depois de carregados
• Cuidado com troca de fonte: se a fonte web carrega depois do texto de fallback já estar na tela, e as duas têm proporção muito diferente, o texto se reorganiza visivelmente

Um detalhe que conecta com IA de busca

Vale lembrar: páginas rápidas, estáveis e bem estruturadas não facilitam só a vida de quem visita — também facilitam a vida de crawlers e motores de resposta que precisam renderizar e interpretar a página rapidamente. Core Web Vitals bons são parte da mesma base técnica que ajuda um site a ser bem processado tanto pelo Google tradicional quanto por sistemas de busca com IA.

Por onde começar

Abra o relatório de Core Web Vitals no Search Console, veja quais páginas (ou grupos de página) estão na faixa "ruim" ou "precisa melhorar", e ataque primeiro as páginas de maior tráfego ou maior valor de conversão. Depois de qualquer correção, tenha paciência: o CrUX atualiza numa janela de 28 dias, então o resultado real só aparece algumas semanas depois do ajuste — não julgue uma correção como "não funcionou" só porque o número não mudou no dia seguinte.