Core Web Vitals in 2026: what actually moves rankings

O que as Core Web Vitals medem hoje

As Core Web Vitals são três métricas que descrevem a experiência de uma página para visitantes reais. O Largest Contentful Paint (LCP) mede o carregamento: quanto tempo leva até a imagem principal ou o bloco de texto principal ficar visível. O Interaction to Next Paint (INP) mede a responsividade: quanto tempo a página leva para reagir visivelmente depois de um toque, clique ou tecla pressionada. O Cumulative Layout Shift (CLS) mede a estabilidade visual: quanto o conteúdo pula enquanto a página carrega.

Uma página é aprovada quando pelo menos 75% das visitas estão na faixa “boa”: LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1. Mobile e desktop são avaliados separadamente, e o mobile é quase sempre o mais difícil.

O INP substituiu o First Input Delay (FID) como Core Web Vital em março de 2024. O FID media apenas o atraso antes da primeira interação; o INP considera as interações mais lentas ao longo de toda a visita. Muitos sites que estavam confortavelmente no verde com o FID passaram para amarelo ou vermelho com o INP.

Quanto elas afetam o ranqueamento?

As Core Web Vitals fazem parte dos sinais de experiência na página do Google. Elas não superam a relevância: uma página lenta com a melhor resposta ainda vence uma página rápida com uma resposta fraca. Onde elas pesam é entre páginas de qualidade parecida, e na conversão — os visitantes abandonam páginas lentas e instáveis, seja qual for a posição delas.

Por isso tratamos as métricas primeiro como indicador de negócio e só depois como indicador de SEO. Páginas mais rápidas vendem mais, geram mais contatos e custam menos em tráfego pago.

Dados de campo versus dados de laboratório

As notas de laboratório do Lighthouse e do PageSpeed Insights simulam uma única visita em um dispositivo com desempenho limitado. Elas são úteis para depuração, mas o Google ranqueia com dados de campo do Chrome User Experience Report (CrUX), coletados de usuários reais do Chrome ao longo de 28 dias.

Comece pelo relatório de Core Web Vitals do Search Console para ver quais grupos de URLs falham e em qual métrica. Depois, use o PageSpeed Insights para ver os números de campo de uma URL específica e o painel Performance do Chrome DevTools para encontrar a causa.

Como corrigir o LCP

A maioria dos problemas de LCP vem de quatro lugares: resposta lenta do servidor, imagem principal descoberta tarde, CSS e fontes que bloqueiam a renderização, ou uma imagem simplesmente grande demais.

• Deixe o Time to First Byte abaixo de cerca de 800 ms: cache de página inteira para visitantes anônimos, uma CDN e consultas rápidas ao banco de dados.
• Nunca use lazy load na imagem do LCP. Dê a ela fetchpriority="high" e faça preload se ela estiver definida no CSS.
• Sirva AVIF ou WebP no tamanho certo com srcset e sizes, em vez de um único JPEG grande.
• Coloque o CSS crítico inline e carregue o restante sem bloquear; hospede as fontes você mesmo e use font-display: swap.

Como corrigir o INP

O INP é quase sempre um problema de JavaScript. Quando a thread principal está ocupada com uma tarefa longa — qualquer coisa acima de 50 ms —, o navegador não consegue responder ao toque do usuário até ela terminar.

Audite primeiro os scripts de terceiros: widgets de chat, mapas de calor, ferramentas de teste A/B e vários contêineres de tags costumam somar centenas de milissegundos. Carregue-os depois da interação ou apenas em páginas específicas. No seu próprio código, mantenha os event handlers pequenos, aplique debounce nos handlers de input e divida trabalhos longos em partes menores para que o navegador possa renderizar entre elas. Um DOM muito grande (vários milhares de elementos) também deixa cada interação mais lenta, o que é comum com page builders.

// Let the browser paint between chunks of heavy work
async function processInChunks(items, handle) {
  for (const item of items) {
    handle(item);
    await new Promise((resolve) => setTimeout(resolve, 0));
  }
}

Como corrigir o CLS

• Sempre defina width e height (ou aspect-ratio) em imagens, vídeos e iframes.
• Reserve espaço para anúncios, embeds e banners de cookies, em vez de empurrar o conteúdo para baixo quando eles carregam.
• Evite inserir banners ou avisos acima do conteúdo existente depois que a página foi renderizada.
• Use fontes de fallback com métricas compatíveis (size-adjust) para que o texto não se reorganize quando a web font chegar.

Particularidades de Laravel e WordPress

No Laravel, os ganhos rápidos são os caches de produção (php artisan config:cache, route:cache, view:cache), o OPcache, o Redis para cache e sessões e o eager loading para eliminar consultas N+1 que atrasam o primeiro byte. Gere os assets com o Vite para que CSS e JavaScript sejam minificados e versionados, e mova tarefas lentas, como e-mails e chamadas de API, para filas.

No WordPress, a maioria dos problemas vem dos plugins. Remova os que você não precisa, use um cache de página adequado (o LiteSpeed Cache em servidores LiteSpeed funciona muito bem), otimize as imagens no upload, mantenha o PHP em uma versão 8.x com suporte e tenha cuidado com page builders pesados.

Meça e depois aguarde

Adicione a biblioteca open source web-vitals para enviar os valores reais de LCP, INP e CLS ao GA4 ou a um endpoint próprio, e assim ver as mudanças em poucos dias, sem esperar pelo CrUX. O relatório do Search Console usa uma janela móvel de 28 dias, então, depois de uma correção, leva cerca de quatro semanas para o status ficar verde. Valide a correção lá quando os novos dados chegarem.

Se quiser uma primeira visão rápida do seu próprio site, nosso verificador de sites gratuito aponta respostas lentas, falta de compressão e outras causas comuns.