Os Core Web Vitals são um conjunto de três métricas que o Google usa para descrever a experiência real de quem acessa uma página. Elas fazem parte dos critérios de ranqueamento desde 2021 e, mais importante do que o efeito em SEO, têm relação direta com a taxa de conversão: páginas lentas perdem visitantes antes mesmo de carregar por completo.

Este artigo explica cada métrica em linguagem de negócio, mostra o que costuma derrubar a nota, descreve como priorizar as correções e discute como manter o desempenho ao longo do tempo — porque performance não é um item de checklist único, e sim algo que degrada a cada publicação se não houver disciplina.

As três métricas

LCP — Largest Contentful Paint

Mede quanto tempo leva até o maior elemento visível da página aparecer — normalmente a imagem principal, um bloco de texto grande ou o vídeo do topo. É a métrica que mais se aproxima da percepção de “o site abriu”. O alvo é até 2,5 segundos para a maioria dos acessos. Acima de 4 segundos, a experiência é considerada ruim.

INP — Interaction to Next Paint

Substituiu o antigo FID em 2024. Mede quão rápido a página responde visualmente às interações do usuário ao longo de toda a visita — cliques, toques, digitação. Se você clica em um menu e ele demora a abrir, ou se o campo de busca “engasga” enquanto você digita, o INP está alto. O alvo é até 200 milissegundos.

CLS — Cumulative Layout Shift

Mede o quanto o layout “pula” durante o carregamento. Acontece quando uma imagem sem dimensões declaradas empurra o texto para baixo, quando um banner aparece de repente ou quando uma fonte troca e muda a altura das linhas. O usuário tenta clicar em um botão e ele se move. O alvo é um índice de até 0,1.

Onde os dados vêm

É importante distinguir dois tipos de medição. Os dados de laboratório vêm de ferramentas que simulam um acesso em condições controladas — úteis para diagnosticar e testar hipóteses. Os dados de campo vêm de usuários reais, com aparelhos e conexões variados, e são o que o Google efetivamente usa para ranqueamento.

Um site pode ter nota boa em laboratório e ruim em campo, geralmente porque a maioria dos usuários acessa por celular em rede móvel, um cenário bem mais duro do que o computador do escritório. Sempre priorize os dados de campo, disponíveis no relatório de experiência do Chrome e no Search Console.

O que costuma derrubar a nota

  • Imagens pesadas e mal servidas — sem compressão, sem formatos modernos, sem dimensões declaradas, carregadas mesmo quando estão fora da tela.
  • JavaScript demais — bibliotecas grandes, scripts de terceiros, código que bloqueia a renderização enquanto executa.
  • Fontes personalizadas — sem estratégia de carregamento, causam texto invisível ou troca visível que gera CLS.
  • Servidor lento para responder — sem cache, com consultas de banco pesadas a cada requisição.
  • Tags de marketing e analytics — cada ferramenta adicionada via gerenciador de tags custa desempenho; poucas são realmente necessárias.
  • Banners e pop-ups — de consentimento, de newsletter, de promoção, que aparecem depois e deslocam o conteúdo.

Como priorizar as correções

Nem toda otimização vale o esforço. O caminho mais eficiente:

  1. Comece pelos dados de campo: qual das três métricas está fora do alvo e em qual tipo de dispositivo.
  2. Para LCP alto, olhe primeiro a imagem principal — formato, tamanho, prioridade de carregamento — e o tempo de resposta do servidor.
  3. Para CLS alto, procure elementos sem dimensão reservada: imagens, iframes, anúncios, blocos que aparecem depois.
  4. Para INP alto, identifique quais interações estão lentas e reduza o trabalho de JavaScript que acontece nelas.
  5. Meça de novo em campo depois de cada mudança; ganhos de laboratório nem sempre se confirmam com usuários reais.

Em muitos sites, um punhado de mudanças resolve a maior parte do problema: otimizar a imagem do topo, remover dois ou três scripts desnecessários, ajustar o carregamento das fontes e ativar cache no servidor.

Por que isso importa para o negócio

A relação entre velocidade e conversão é bem documentada. Cada segundo a mais no carregamento reduz a probabilidade de o visitante continuar. Em e-commerce, isso significa carrinho abandonado antes da vitrine carregar. Em captação de leads, significa formulário nunca visto. Em conteúdo, significa taxa de rejeição alta e menos páginas por sessão.

Há também um efeito de custo. Um site mais leve consome menos banda, menos processamento no servidor e é mais barato de rastrear para os mecanismos de busca — o que ajuda a indexação de sites grandes. E há o efeito de marca: um site lento comunica desleixo, mesmo que o visitante não saiba dizer o porquê.

Performance se mantém, não se conquista

O erro mais comum é tratar performance como um projeto pontual: contrata-se uma otimização, a nota sobe, todo mundo comemora e, seis meses depois, ela caiu de novo. Isso acontece porque cada nova funcionalidade, cada plugin, cada tag de marketing e cada imagem publicada sem cuidado consome um pouco do orçamento de desempenho.

Manter os Core Web Vitals no verde exige processo:

  • Um “orçamento de performance” definido — tamanho máximo de página, número máximo de requisições — verificado antes de publicar.
  • Pipeline que mede as métricas a cada mudança e alerta quando piora.
  • Otimização automática de imagens no momento do upload.
  • Revisão periódica das tags de terceiros: cada uma ainda é necessária?
  • Acompanhamento mensal dos dados de campo no Search Console.

LCP em detalhe: o que atrasa o carregamento

O LCP alto quase sempre tem uma de quatro causas, e vale investigá-las nesta ordem. A primeira é o tempo de resposta do servidor: se ele demora um segundo para começar a mandar o HTML, esse segundo já entra na conta antes de qualquer imagem. Cache de página e um servidor bem dimensionado resolvem.

A segunda é o carregamento da imagem principal: formato antigo, arquivo grande, sem prioridade de carregamento, ou pior, uma imagem que só é descoberta pelo navegador depois de baixar e processar um arquivo CSS ou JavaScript. Declarar a imagem do topo com prioridade alta e servi-la em formato moderno costuma cortar segundos.

A terceira são recursos que bloqueiam a renderização — folhas de estilo e scripts que o navegador precisa processar antes de desenhar qualquer coisa. A quarta é a fonte personalizada, que pode segurar o texto ou causar um “flash” quando troca. Controlar como as fontes carregam elimina os dois problemas.

CLS em detalhe: o que faz o layout pular

O deslocamento de layout tem uma causa central: elementos que ocupam espaço na página sem que esse espaço tenha sido reservado de antemão. Os culpados mais comuns:

  • Imagens e vídeos sem atributos de largura e altura, ou sem proporção definida no CSS.
  • Anúncios e embeds de terceiros que chegam depois e empurram o conteúdo.
  • Banners de consentimento de cookies inseridos no topo depois do carregamento inicial.
  • Conteúdo carregado dinamicamente acima do que o usuário já está lendo.
  • Fontes que mudam a altura da linha quando a fonte final substitui a de fallback.

A correção é sempre a mesma ideia: reservar o espaço antes. Toda imagem com dimensão declarada, todo slot de anúncio com altura mínima fixa, todo elemento dinâmico inserido abaixo da área visível ou em um espaço já reservado.

INP em detalhe: o custo do JavaScript

O INP mede o tempo entre a interação do usuário e a próxima atualização visual da tela. Quando esse tempo é alto, é porque a thread principal do navegador está ocupada executando JavaScript e não consegue responder ao clique. As fontes típicas:

  • Handlers de evento que fazem trabalho pesado de forma síncrona.
  • Scripts de terceiros — chat, analytics, testes A/B — que rodam com frequência.
  • Renderização de listas ou tabelas grandes sem virtualização.
  • Frameworks que reprocessam mais do que o necessário a cada interação.

As soluções envolvem quebrar tarefas longas em pedaços, adiar o que não é urgente, reduzir o número de scripts de terceiros e, quando aplicável, mover processamento para fora da thread principal.

Ferramentas úteis

  • PageSpeed Insights — combina dados de laboratório e de campo para uma URL.
  • Search Console → Core Web Vitals — visão agregada do site inteiro, por grupo de páginas.
  • Chrome DevTools — aba Performance para o carregamento, aba de INP para diagnosticar interações lentas.
  • WebPageTest — testes detalhados em diferentes dispositivos e conexões, com cascata completa.
  • Relatório CrUX — dados de campo agregados, disponíveis também via BigQuery para análise histórica.

Um mito comum: nota 100 no Lighthouse

A nota de 0 a 100 do Lighthouse é um dado de laboratório e mede uma simulação, não a experiência dos seus usuários. É possível ter nota 100 e Core Web Vitals ruins em campo, e vice-versa. Perseguir os 100 pontos costuma levar a otimizações de retorno decrescente que não mexem no que o usuário sente.

O que importa é a proporção de acessos reais dentro dos alvos — idealmente acima de 75% para cada métrica, que é o critério que o Google usa para considerar a página “aprovada”. Use o Lighthouse para diagnosticar e testar hipóteses, mas decida com os dados de campo.

Como a Jumps trata

A Jumps inclui performance no escopo de sites e portais desde o início — não como um ajuste no fim — e mantém o acompanhamento na sustentação, com orçamento de performance verificado a cada publicação e revisão mensal dos dados de campo.

Se o seu site está com Core Web Vitals no vermelho ou você quer garantir que um projeto novo nasça rápido, fale com a Jumps para uma auditoria.