Core Web Vitals: os limites do Google e como melhorar cada um

Core Web Vitals é o nome que o Google deu para transformar "site rápido" em algo mensurável e comparável. Em vez de opinião, três números com limites publicados, medidos em visitas de gente de verdade, e não em teste de laboratório.

Este guia mostra o que cada métrica mede, os limites oficiais, como medir de graça e o que fazer para melhorar cada uma. E começa por uma armadilha de interpretação que atrapalha até quem já trabalha com SEO.

O que são Core Web Vitals?

Core Web Vitals são três métricas que o Google usa para descrever a experiência de carregar e usar uma página. Cada uma cobre uma dimensão diferente do incômodo que um site pode causar:

• LCP, ou Largest Contentful Paint: quanto tempo leva até o maior elemento visível aparecer. Mede a sensação de "já carregou".
• INP, ou Interaction to Next Paint: quanto tempo a página leva para responder depois de um clique ou toque. Mede a sensação de "está travado".
• CLS, ou Cumulative Layout Shift: o quanto os elementos pulam de lugar enquanto a página carrega. Mede a sensação de "clicou no botão errado porque tudo se mexeu".

A diferença para as métricas de velocidade antigas é o método: o Google usa dados de visitas reais, coletados de usuários do Chrome, e não um teste simulado. É por isso que o número que você vê numa ferramenta de laboratório pode não bater com o do relatório, ponto que este guia detalha mais adiante.

Como parte da camada de SEO técnico, eles não substituem conteúdo. Servem de desempate e, principalmente, evitam que gente desista de esperar.

Quais são os limites do Google?

O Google publica os limites e o critério de aprovação. A página passa quando fica na faixa boa das três métricas no 75º percentil das visitas, medido separadamente para celular e computador.

Fonte: Google, documentação oficial dos Web Vitals.

Duas coisas que quase ninguém repara nessa tabela.

O percentil 75 é generoso e cruel ao mesmo tempo. Significa que a página pode falhar em um quarto das visitas e ainda passar. Mas também significa que a média não vale nada: se metade dos acessos é rápida e a outra metade é péssima, você reprova mesmo com uma média boa.

A separação por dispositivo derruba muita gente. É comum um site passar no computador e reprovar no celular, que é justamente a versão que o Google usa para indexar. Se você olhar só o número do desktop, vai concluir que está tudo bem.

O que é LCP e como melhorar?

O LCP marca o instante em que o maior elemento da área visível termina de aparecer. Quase sempre é a imagem de capa, um banner ou o bloco de texto principal.

O que costuma atrasar, em ordem de frequência:

• Imagem grande demais. Uma capa de 2 MB entregue em tamanho original é o motivo mais comum de LCP ruim. Formato moderno, dimensão certa e compressão resolvem quase sozinhos.
• Servidor lento para responder. Se o primeiro byte demora, tudo depois demora. Cache e uma boa hospedagem resolvem mais que qualquer ajuste de código.
• Fontes e scripts bloqueando a renderização. Arquivos carregados antes do conteúdo fazem o navegador esperar. Carregamento adiado e fontes com exibição imediata corrigem.
• Conteúdo dependente de JavaScript. Quando o texto principal só aparece depois que um script roda, o LCP acumula todo esse tempo.

Sabe qual é o ajuste de maior retorno? Tratar a imagem de capa: comprimir, servir no tamanho exato e não deixá-la em carregamento preguiçoso. É meia hora de trabalho e costuma tirar mais de um segundo.

O que é INP e como melhorar?

O INP mede quanto tempo a página leva para dar um retorno visual depois de uma interação. Ele substituiu o antigo FID e é mais rigoroso, porque considera todas as interações da visita, não apenas a primeira.

As causas são quase sempre a mesma coisa: JavaScript ocupando a linha principal do navegador. Enquanto um script roda, nada mais acontece, e o clique fica esperando.

O que fazer:

• Reduzir e adiar script de terceiros. Chats, mapas, pixels de rastreamento e testes A/B são os campeões. Cada um cobra um pedaço da resposta.
• Quebrar tarefas longas. Um script que roda por 500 milissegundos seguidos trava tudo nesse período. Dividir em pedaços devolve o controle ao navegador entre eles.
• Dar retorno imediato à interação. Mostrar o estado de "carregando" no clique é melhor que esperar o processo terminar em silêncio.

Traduzindo para o dia a dia: o INP é a métrica que piora sozinha à medida que o time de marketing instala ferramentas. Cada tag nova é meio passo para trás, e a auditoria de tags costuma render mais que qualquer otimização de código.

O que é CLS e como melhorar?

O CLS mede o quanto o conteúdo pula de lugar sem que o usuário tenha pedido. É a métrica mais fácil de corrigir e a mais irritante quando falha, porque produz o clique errado.

As causas são poucas e bem conhecidas:

• Imagem sem dimensão declarada. O navegador não sabe quanto espaço reservar e empurra tudo quando a imagem chega. Declarar largura e altura resolve.
• Anúncio ou banner sem espaço reservado. Mesmo problema, efeito maior, porque costuma estar no topo.
• Fonte que troca depois de carregar. O texto muda de tamanho e reorganiza o bloco.
• Conteúdo inserido acima do que já está visível. Avisos de cookie, faixas de promoção e mensagens que aparecem depois.

A regra geral cabe numa frase: reserve o espaço antes de o elemento chegar. É a correção mais barata das três métricas e a que mais melhora a sensação de qualidade do site.

Como medir os Core Web Vitals de graça?

Quatro ferramentas, todas do Google e todas gratuitas:

1. Relatório de Core Web Vitals no Search Console. É o oficial, com dados de visitas reais e agrupamento por tipo de página. É por aqui que se começa, porque mostra quais grupos de URLs reprovam.
2. PageSpeed Insights. Analisa uma URL e mostra os dois lados: os dados reais dos últimos 28 dias, quando existem, e um teste de laboratório com sugestões.
3. Lighthouse, no próprio navegador. Teste de laboratório para diagnosticar enquanto se corrige, sem esperar o dado real acumular.
4. A extensão Web Vitals. Mostra as três métricas enquanto você navega no site, útil para achar a página problemática.

Ordem recomendada: Search Console para saber onde dói, PageSpeed Insights para entender por quê, Lighthouse para testar a correção, e de volta ao Search Console semanas depois para confirmar. Esse ciclo faz parte de qualquer auditoria de SEO.

Por que o laboratório mostra um número e o Google mostra outro?

Porque são coisas diferentes, e confundir as duas leva a corrigir o que não precisa.

Dado de laboratório é um teste simulado, num aparelho e numa conexão definidos pela ferramenta. É reproduzível e serve para diagnosticar.

Dado de campo é a medição de visitas reais, com todos os aparelhos, conexões e localizações do seu público. É o que o Google usa para avaliar a página, e ele demora, porque acumula 28 dias.

Sabe o que isso significa na prática? Que uma nota 100 no laboratório não garante aprovação, principalmente se o seu público acessa de celular mais simples ou de conexão pior que a do teste. E significa também que qualquer correção leva semanas para aparecer no relatório oficial, porque a janela precisa renovar.

O que mudou do FID para o INP?

Se você leu material sobre Core Web Vitals há alguns anos, encontrou uma métrica chamada FID, ou First Input Delay. Ela foi substituída pelo INP, e a troca não foi cosmética.

O FID media só o atraso da primeira interação, e apenas até o navegador começar a processá-la. Isso o tornava fácil de passar: a maioria dos sites era aprovada mesmo travando bastante depois do primeiro clique.

O INP mede todas as interações da visita e vai até o momento em que a tela efetivamente muda. É a diferença entre medir quanto tempo o garçom leva para ouvir o pedido e quanto tempo leva até o prato chegar.

O que isso muda na prática:

• Sites que passavam agora reprovam. Não porque pioraram, mas porque a régua passou a medir o que o usuário sente.
• Página com muito script sofre mais. Chats, mapas e ferramentas de rastreamento, que quase não afetavam o FID, aparecem no INP.
• A correção mudou de lugar. Antes bastava adiar o que carregava no início; agora é preciso olhar o que roda durante o uso.

Se o seu material de referência ainda fala em FID, ele é anterior a essa troca, e provavelmente também está desatualizado no resto. É um bom teste de frescor para qualquer guia de performance.

Core Web Vitals são fator de ranqueamento?

São, como parte do sinal de experiência da página, e com um peso menor do que o mercado costuma vender.

O que se sabe com segurança:

• Entre páginas equivalentes em conteúdo, a experiência desempata. Não é uma bonificação que faz uma página fraca subir.
• Conteúdo continua acima. Uma página lenta com a melhor resposta segue ganhando de uma rápida e rasa. Isso não é opinião: é a ordem que o próprio Google descreve ao falar de conteúdo útil.
• O efeito colateral é maior que o direto. Página lenta perde visitante antes de carregar, o que derruba a taxa de conversão independentemente de qualquer algoritmo.

A conclusão prática vale como regra de prioridade: se o site tem problema de indexação, resolva primeiro. Se o conteúdo não responde à busca, resolva em seguida. Core Web Vitals entram depois disso, e antes de qualquer tática de link.

Por onde começar quando tudo está vermelho?

Um roteiro de meio dia, na ordem de retorno:

1. Descubra qual grupo de páginas reprova. No Search Console, o relatório agrupa URLs parecidas. Normalmente é um modelo de página inteiro, não uma URL isolada.
2. Comece pelo celular. É a versão que o Google indexa e quase sempre a pior.
3. Ataque as imagens primeiro. Tamanho, formato e dimensão declarada resolvem LCP e CLS ao mesmo tempo. É o item de melhor relação entre esforço e resultado.
4. Faça a auditoria de tags de terceiros. Liste tudo o que está instalado, remova o que ninguém usa e adie o que não precisa carregar de imediato. É o principal remédio para INP.
5. Confira o tempo de resposta do servidor. Se o primeiro byte passa de meio segundo, cache e hospedagem entram na conversa antes de qualquer ajuste fino.
6. Espere e confirme. As correções aparecem no relatório oficial depois de semanas, porque a janela de dados reais precisa renovar.

Sabe qual é o erro mais comum nessa etapa? Perseguir a nota 100 do laboratório. A meta é ficar na faixa verde das três métricas com dados reais, e a diferença entre "verde" e "perfeito" quase nunca paga o esforço.

Conclusão

Core Web Vitals transformam velocidade em três números com limites claros, medidos em gente de verdade. O caminho prático é sempre o mesmo: descobrir o grupo de páginas que reprova no celular, corrigir imagens e tags de terceiros, e esperar a janela de dados renovar. O próximo passo é abrir o relatório de Core Web Vitals no Search Console e ver qual modelo de página está no vermelho. Antes disso, vale conferir se a base está de pé com o checklist de SEO técnico.