Core Web Vitals: o que são e como corrigir

Core Web Vitals são três números: 2,5 segundos, 200 milissegundos e 0,1. O primeiro é o LCP, o tempo até a primeira tela ficar visível. O segundo é o INP, a demora entre o toque e a resposta. O terceiro é o CLS, o quanto o conteúdo pula de lugar. Passar significa ficar abaixo dos três em pelo menos 75% das visitas reais dos últimos 28 dias — no celular e no computador, medidos separadamente.

A parte que quase todo artigo sobre o assunto erra vem agora. O número que o Google usa não é o do teste que você acabou de rodar. É o dado de campo, coletado do navegador de gente de verdade. Um site pode marcar 100 no Lighthouse pela manhã e continuar reprovado no Search Console à tarde. Vemos isso com mais frequência do que o contrário.

E tem a parte impopular, que fica para o fim com a conta feita: isto é critério de desempate, não alavanca de ranking. Corrigir os três num site sem conteúdo relevante não move nada. O motivo real de corrigir é outro, e ele é medível em reais.

As três métricas, traduzidas

LCP é o cronômetro que para quando o maior elemento visível da primeira tela termina de aparecer — quase sempre a imagem grande do topo ou o bloco de título. Não é “o site carregou”. É “a pessoa já consegue ver do que se trata”. Bom até 2,5s, ruim acima de 4s.

INP é a demora entre o toque e a primeira mudança visível na tela. Vale para o clique no menu, no filtro do catálogo, no botão do formulário. Substituiu o FID em março de 2024 porque o FID media só o primeiro clique, e só até o navegador começar a reagir. O INP olha a visita inteira e conta até a tela realmente mudar. Bom até 200ms, ruim acima de 500ms.

CLS é o quanto o conteúdo se move sozinho enquanto a página monta. É o botão que troca de lugar meio segundo antes do dedo chegar. Não tem unidade: é uma proporção entre a área que se deslocou e o tamanho da tela. Bom até 0,1.

Dado de laboratório não é dado de campo

Esta é a distinção que faz a diferença entre corrigir o problema e correr atrás de uma nota.

Cinco motivos explicam quase toda divergência entre os dois. O teste roda em condição controlada, enquanto o campo é a soma de aparelhos Android de quatro anos em 4G irregular. O teste quase sempre é feito na home, e o campo mede a página que recebe o tráfego, que costuma ser mais pesada. Em produção entram banner de consentimento, gerenciador de tags, chat e pixel, que o ambiente de teste às vezes não carrega. O laboratório não mede INP de jeito nenhum, porque sem usuário não há interação. E a janela de campo é móvel: a correção de ontem só aparece inteira daqui a quatro semanas.

Existe ainda o caso de quem não tem dado nenhum: site com pouco tráfego não recebe medição por página e passa a ser julgado pela média do domínio inteiro. Na prática, um template pesado — a ficha de produto, o post do blog — arrasta todas as outras páginas junto. Se for o seu caso, instale a coleta própria com a biblioteca web-vitals enviando os três números para o Analytics. Em três ou quatro semanas você para de discutir com o laboratório.

LCP: as três causas que respondem pela maioria dos casos

Servidor lento. Se o primeiro byte demora mais de 800ms para sair, nada no front-end salva a métrica. A combinação clássica é hospedagem compartilhada com um CMS que remonta a página a cada visita e um punhado de plugins consultando o banco no caminho. A saída é cache de página, HTML estático ou CDN na frente — não é comprimir imagem.

A imagem do topo começa a baixar tarde. É a causa mais comum e a mais fácil de resolver. Herói com lazy load, imagem dentro de carrossel montado em JavaScript, ou imagem declarada como background no CSS: em todos esses casos o navegador só descobre o arquivo depois de processar outra coisa. Corrija colocando a imagem como tag no HTML, com fetchpriority="high", sem loading="lazy" acima da dobra, em formato moderno e no tamanho em que ela é exibida. Trocar um JPEG de 1,5 MB por um WebP de 120 KB no lugar certo costuma cortar mais de um segundo sozinho.

Bloqueio de renderização. CSS de framework inteiro baixado antes de qualquer pixel, fonte que segura o texto até chegar, script de terceiro no topo do documento. O conjunto de correções é conhecido: CSS crítico embutido, font-display: swap, preconnect para os domínios de terceiro que sobrarem e defer no resto.

INP: o travamento que só aparece depois do carregamento

Terceiros ocupando a fila. Gerenciador de tags com uma dúzia de disparos, widget de chat, gravador de sessão, ferramenta de teste A/B. Cada toque do usuário espera essa fila esvaziar. Na nossa operação, o campeão de custo raramente é o código do site: é o chat que ninguém usa e ninguém tem coragem de tirar.

Trabalho pesado dentro do próprio clique. Filtro de catálogo que recalcula a lista inteira a cada tecla, página inteira sendo hidratada por um framework, código que lê medidas do layout dentro do evento e força o navegador a recalcular tudo. Debounce no campo de busca e quebra da tarefa longa em pedaços resolvem a maior parte.

Renderização cara depois da interação. O modal que monta centenas de elementos ao abrir, o menu que anima altura em vez de transformação. Anime transform e opacity, e dê o retorno visual antes de executar o trabalho pesado.

Repare no que isso implica: como o INP olha a visita inteira, o culpado quase nunca está no carregamento da home. Está no menu do celular, no filtro e no formulário. Testar só a abertura da página nunca vai encontrar.

CLS: o conteúdo que pula na hora do clique

Mídia sem dimensão declarada. Imagem, iframe e embed sem width e height — ou sem aspect-ratio no CSS — só ganham espaço depois de baixar, e empurram o que estava embaixo.

Fonte que troca de métrica. O texto aparece na fonte de sistema e reflui quando a webfont chega. Resolve-se com size-adjust na declaração da fonte ou escolhendo um fallback com métricas parecidas, mais preload da fonte usada acima da dobra.

Conteúdo injetado por cima do que já estava. Barra de consentimento, faixa de promoção, aviso de frete, bloco carregado depois. Reserve o espaço antes ou renderize sobreposto, em posição fixa. Nunca empurrando.

Vale lembrar que o CLS considera a pior janela de cinco segundos da visita, não só o carregamento. Deslocamento que acontece quando a pessoa rola até o meio da página conta igual.

Os erros que mais custam caro

• Testar só a home. O relatório agrupa URLs parecidas, e a reprovação quase sempre nasce de um template — o post do blog, a ficha de produto —, não de uma página avulsa.
• Trocar de hospedagem antes de medir o tempo de resposta do servidor. Já acompanhamos migração inteira que não moveu o LCP em nada, porque o gargalo era uma imagem de 3 MB no topo.
• Ligar lazy load em tudo. O plugin melhora o CLS e piora o LCP no mesmo movimento, porque adia justamente a imagem do herói.
• Corrigir e não travar. Um mês depois entra pixel novo, faixa de campanha e vídeo no topo, e tudo volta. Sem um limite acordado no processo de publicação, a correção dura um trimestre.
• Concluir antes das quatro semanas. Como o dado é uma janela móvel de 28 dias, medir no terceiro dia produz conclusão errada tanto para comemorar quanto para desistir.
• Contratar performance quando o problema é conteúdo. Já recusamos um escopo de otimização de velocidade para um site que não aparecia em busca nenhuma, recomendamos conteúdo primeiro e perdemos o projeto para quem aceitou. O site ficou rápido e continuou invisível.

Desempate no ranking, dinheiro na conversão

O Google diz na própria documentação que nenhum sinal de experiência supera conteúdo relevante. Entre duas páginas que respondem igualmente bem à busca, a mais rápida leva vantagem. Entre uma lenta e útil e uma rápida e vazia, a útil continua na frente. Ou seja: se você não está entre os vinte primeiros para o termo que quer, velocidade não é o seu problema. O caminho para descobrir qual é passa por um diagnóstico que separa falha técnica de falha de conteúdo, e o restante do que publicamos sobre SEO técnico e de conteúdo segue a mesma ordem de prioridade.

O motivo real de corrigir é a conversão, e ele aparece na planilha. Faça a conta com os seus números. Uma empresa que investe R$ 3.000 por mês em cliques pagos, com CPC entre R$ 4 e R$ 8 numa praça disputada — faixa que observamos na nossa operação, não tabela oficial —, compra por volta de 500 visitas. A 4% de conversão, são 20 contatos, a R$ 150 cada. Agora suponha que 12% dessas pessoas desistem antes da primeira tela pintar: sobram 440 visitas úteis, 17,6 contatos, e o custo por contato sobe para R$ 170. Ao longo de um ano, com exatamente a mesma verba, são cerca de 29 contatos a menos.

Campinas entra aqui por um motivo objetivo, não geográfico: a densidade de agências e anunciantes empurra o custo do clique para cima em relação a praças menores do interior. Quanto mais caro o visitante, mais cara fica cada tela branca. É a mesma lógica que faz o trabalho de subir a taxa de conversão da página render mais do que aumentar verba, e o que liga performance ao resto do planejamento de marketing digital em vez de deixá-la como assunto de programador.

Se a conversa chegar em “então eu troco de plataforma?”, o critério não é velocidade isolada: é quanto de controle sobre o HTML você tem e quanto custa manter isso. Um site em CMS passa nos três, sim — mas cobra disciplina em tema, plugin e cache, o que discutimos no comparativo entre construir em WordPress ou em código próprio. O ponto de partida é sempre o mesmo: um site construído desde o começo com essas metas não precisa de mutirão de otimização depois.

Os próximos trinta minutos valem mais que o resto deste texto. Abra o Search Console, vá em Core Web Vitals e olhe a aba de celular: anote quantos grupos de URL estão em “ruim” e em “precisa melhorar”. Pegue uma URL de cada grupo e rode no PageSpeed Insights, lendo só a parte de cima, que é o campo — a de baixo serve para achar a causa. Confira o tempo de resposta inicial do servidor: acima de 800ms, o trabalho começa na hospedagem, não no CSS. Descubra qual elemento foi apontado como LCP e verifique se ele é uma imagem com lazy load. Só depois disso decida se o caso é contratar alguém. E se ninguém consegue mexer no HTML do seu site sem quebrar o layout, o problema a resolver não é o Core Web Vitals.