Core Web Vitals: como deixar seu site realmente rápido
Core Web Vitals decidem ranking e conversão. Entenda LCP, INP e CLS, onde seu site falha e o plano, por ordem de impacto, para deixá-lo realmente rápido.
Velocidade percebida não é opinião — é medida. Os Core Web Vitals são as três métricas com que o Google quantifica a experiência real de quem usa o seu site, e elas pesam no ranqueamento. Site lento perde posição e perde venda, nessa ordem.
Este guia é prático: o que cada métrica mede em 2026, quais são as metas, onde o seu site provavelmente falha e o que fazer — em ordem de impacto — para deixá-lo realmente rápido.
As três métricas que importam
Os Core Web Vitals medem experiência real de usuários (dados de campo do relatório CrUX) e são avaliados no percentil 75: 75% dos acessos precisam bater a meta. São três, e cada uma cobre uma dimensão diferente da experiência:
- LCP (Largest Contentful Paint) — velocidade de carregamento do conteúdo principal.
- INP (Interaction to Next Paint) — responsividade às interações do usuário.
- CLS (Cumulative Layout Shift) — estabilidade visual do layout.
Passar nas três, no mundo real e no celular, é o objetivo. Vamos a cada uma.
LCP: o conteúdo principal precisa aparecer rápido
O LCP marca o instante em que o maior elemento visível — normalmente a imagem de destaque ou o bloco de texto do topo — termina de renderizar. Meta: até 2,5 segundos no percentil 75.
As causas mais comuns de um LCP ruim:
- Servidor lento (
TTFBalto): o HTML demora a chegar. - Recursos que bloqueiam a renderização: CSS e JavaScript síncronos no
<head>. - Imagem de destaque pesada: o vilão número um.
- Renderização 100% no cliente: a tela fica em branco até o JavaScript baixar e executar.
O que fazer, em ordem: sirva a imagem principal em AVIF ou WebP, dimensionada e com fetchpriority="high"; nunca use lazy loading no elemento LCP; use CDN e cache para derrubar o TTFB; e priorize renderização no servidor ou estática em vez de montar tudo no navegador.
INP: cada interação precisa responder na hora
O INP substituiu o FID em março de 2024 e é bem mais rigoroso. Enquanto o FID media apenas a primeira interação, o INP observa todas as interações da sessão — cliques, toques, teclas — e reporta a latência mais alta entre o toque do usuário e o próximo quadro pintado na tela. Meta: até 200 milissegundos.
O inimigo do INP é o JavaScript. Quando a thread principal está ocupada executando scripts, o navegador não consegue responder ao usuário. Tarefas longas (long tasks, acima de 50ms) travam a interface.
Como melhorar:
- Divida o código (
code splitting): carregue só o JavaScript necessário para cada rota. - Quebre tarefas longas com
yieldou agendamento, liberando a thread entre pedaços. - Corte scripts de terceiros: chats, pixels e heatmaps são os maiores culpados.
- Adie o que não é crítico com
defere carregamento sob demanda.
No mobile, onde o processador é mais fraco, o INP costuma ser a métrica que mais reprova. Se o seu site passa no desktop e falha no celular, o gargalo quase sempre está aqui.
CLS: nada de layout pulando
O CLS mede quanto os elementos se deslocam de forma inesperada durante o carregamento — aquele botão que pula no instante do toque e faz você clicar no lugar errado. Meta: até 0,1.
Principais causas e correções:
- Imagens e vídeos sem dimensão: sempre declare
widtheheight(ouaspect-ratio) para o navegador reservar o espaço. - Anúncios e embeds: reserve um contêiner de tamanho fixo antes do conteúdo chegar.
- Conteúdo injetado por JavaScript: banners e avisos que empurram o layout para baixo.
- Fontes web: use
font-display: swape pré-carregue as fontes críticas para evitar o salto quando a fonte troca.
CLS é, das três, a métrica mais barata de resolver — e a mais fácil de ignorar até um usuário reclamar.
Campo x laboratório: meça do jeito certo
Existem dois tipos de dado, e confundi-los leva a decisões erradas:
- Dados de campo (field): experiência de usuários reais, coletada pelo CrUX. É o que o Google usa para ranquear. Reflete aparelhos, redes e comportamentos de verdade.
- Dados de laboratório (lab): medição controlada, como a do Lighthouse. Excelente para depurar, mas não é o que conta para posição.
As ferramentas que você deve usar em 2026:
- PageSpeed Insights — campo e laboratório na mesma tela; olhe sempre a aba mobile.
- Google Search Console — o relatório de Core Web Vitals agrupa as URLs que falham e mostra o motivo.
- DevTools (Lighthouse e painel Performance) — diagnóstico com emulação de CPU e rede.
- Biblioteca
web-vitals— meça INP, LCP e CLS dos seus usuários reais e envie para a sua analytics.
Plano de otimização por impacto
Não otimize no escuro. A sequência com melhor retorno:
- Imagens: comprima, converta para AVIF/WebP e dimensione — resolve a maior parte dos problemas de LCP.
- JavaScript: reduza, divida e adie — ataca INP e LCP ao mesmo tempo.
- Dimensões e fontes: declare tamanhos e trate as fontes — zera o CLS.
- Infraestrutura: CDN, cache e um servidor com TTFB baixo sustentam tudo.
Meça antes e depois de cada mudança. Sem medição, otimização vira palpite.
Velocidade é engenharia contínua
Core Web Vitals não é um projeto que se conclui — é uma métrica que se mantém. Cada novo script, banner ou feature pode derrubar um número que estava verde. Por isso velocidade exige monitoramento e disciplina, não uma otimização única.
A We Solution trata performance como parte da engenharia do site, do primeiro commit ao monitoramento contínuo: LCP, INP e CLS dentro das metas, no laboratório e no campo, para transformar velocidade em ranking e conversão.
Fale com a We Solution e receba um diagnóstico dos Core Web Vitals do seu site.