Pular para o conteúdo
Desenvolvimento Web7 min de leitura

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 (TTFB alto): 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:

  1. Divida o código (code splitting): carregue só o JavaScript necessário para cada rota.
  2. Quebre tarefas longas com yield ou agendamento, liberando a thread entre pedaços.
  3. Corte scripts de terceiros: chats, pixels e heatmaps são os maiores culpados.
  4. Adie o que não é crítico com defer e 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 width e height (ou aspect-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: swap e 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:

  1. Imagens: comprima, converta para AVIF/WebP e dimensione — resolve a maior parte dos problemas de LCP.
  2. JavaScript: reduza, divida e adie — ataca INP e LCP ao mesmo tempo.
  3. Dimensões e fontes: declare tamanhos e trate as fontes — zera o CLS.
  4. 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.

Core Web VitalsPerformance webLCPINPOtimização
Voltar ao blog