Core Web Vitals explicadas sem jargão para quem decide o orçamento do site

O Google mede a experiência de carregamento e de resposta das páginas em usuários reais. Esse conjunto de métricas se chama Core Web Vitals, e desde 2021 ele entra na conta do ranqueamento de busca. São três números, cada um com um limite público e uma forma própria de dar errado.

A confusão começa quando alguém abre o Lighthouse, vê uma nota verde de 95 e conclui que o assunto está resolvido. Não está. A nota do Lighthouse e o dado que o Google usa para ranquear vêm de fontes diferentes, medem coisas diferentes e discordam com frequência.

Este artigo explica o que cada uma das Core Web Vitals mede, quais limites o Google documenta como bons, de onde vem o dado que conta e o que fazer quando os dois relatórios contam histórias opostas. Sem fórmula mágica: são problemas de engenharia com causas identificáveis.

O que são as Core Web Vitals

São três indicadores de experiência de carregamento que o Google padronizou para descrever, com número, aquilo que o visitante sente. Um mede velocidade de exibição, outro mede resposta a interação, o terceiro mede estabilidade visual.

A escolha desses três não é arbitrária. Cada um cobre um momento distinto da visita: o instante em que a página aparece, o instante em que ela obedece a um clique e o intervalo em que ela para de se mexer sozinha. Um site pode ir bem em dois e mal no terceiro — é o caso mais comum que encontramos.

Os nomes:

• LCP (Largest Contentful Paint): quanto tempo até o maior elemento visível ser desenhado.
• INP (Interaction to Next Paint): quanto tempo a página demora para responder visualmente a uma interação.
• CLS (Cumulative Layout Shift): quanto o conteúdo se desloca depois de já ter aparecido.

Métricas que não fazem parte do conjunto

TTFB, First Contentful Paint e Total Blocking Time aparecem nos relatórios e são úteis para diagnóstico, mas não entram nas Core Web Vitals. Elas explicam as três principais. Um TTFB alto empurra o LCP para cima; um Total Blocking Time alto costuma anteceder problema de resposta. Trate essas secundárias como pistas, não como meta.

LCP: quanto tempo até o conteúdo principal aparecer

O LCP marca o momento em que o maior bloco de conteúdo visível na área inicial termina de ser desenhado. Normalmente é a imagem do topo, um vídeo em pôster ou um bloco grande de texto do título.

Segundo a documentação do Google, abaixo de 2,5 segundos é considerado bom; entre 2,5 e 4 segundos precisa de melhoria; acima de 4 segundos é ruim.

O erro típico é otimizar a página inteira sem saber qual elemento está sendo medido. Cada página tem o seu, e ele muda entre celular e desktop porque a área visível muda. Antes de comprimir qualquer arquivo, identifique o elemento — o passo a passo de como isolamos o elemento medido começa exatamente por aí, porque otimizar o recurso errado consome semana e não move o número.

O que costuma pesar

Servidor lento na primeira resposta, imagem de topo em formato antigo e sem prioridade de carregamento, fonte customizada que bloqueia a pintura do texto, e carrossel em JavaScript que só monta a primeira imagem depois que o script termina. Nessa ordem de frequência.

INP: quanto tempo a página demora para responder

O INP mede a latência entre a interação do usuário e a próxima atualização visual da tela. Clique, toque, tecla. A métrica observa praticamente todas as interações da visita e reporta um valor próximo do pior caso, não a média.

Segundo o Google, abaixo de 200 milissegundos é bom, entre 200 e 500 precisa de melhoria, e acima de 500 é ruim.

Essa métrica substituiu o FID em março de 2024, e a troca reprovou muito site que estava confortável. O FID media apenas o atraso da primeira interação, e apenas o atraso — não o tempo de processar nem o de desenhar. Era um exame fácil de passar. A régua nova cobre a visita inteira, e o que mudou na prática quando o FID saiu de cena explica por que painéis, filtros e menus são os primeiros a aparecer no relatório.

A causa quase sempre é JavaScript

Tarefas longas na thread principal, handlers de evento que fazem trabalho demais em vez de agendar, e frameworks que re-renderizam a árvore inteira a cada digitação. Scripts de terceiros — chat, mapa de calor, testes A/B — entram na lista com frequência desproporcional ao valor que entregam.

CLS: quanto o layout se move sozinho

O CLS soma os deslocamentos inesperados de conteúdo já visível durante a vida da página. É a métrica do dedo que erra o botão porque um banner apareceu meio segundo depois.

O limite documentado: abaixo de 0,1 é bom, até 0,25 precisa de melhoria, acima disso é ruim. É o único dos três que não tem unidade de tempo — é uma pontuação, calculada pela fração da tela afetada multiplicada pela distância do movimento.

A boa notícia é que costuma ser o mais barato de corrigir. Imagem sem largura e altura declaradas, fonte que troca de família depois de carregar, iframe de anúncio sem espaço reservado e aviso de cookie injetado no topo respondem pela maioria dos casos. Como reservamos espaço para cada um desses elementos é um trabalho de CSS, não de infraestrutura.

Quais são os limites que o Google considera bons?

Reunindo o que está documentado:

Métrica	Bom	Precisa melhorar	Ruim
LCP	até 2,5 s	2,5 s a 4 s	acima de 4 s
INP	até 200 ms	200 ms a 500 ms	acima de 500 ms
CLS	até 0,1	0,1 a 0,25	acima de 0,25

Uma URL só é aprovada nas Core Web Vitals quando as três métricas ficam na faixa boa. Duas verdes e uma amarela reprovam o conjunto.

O percentil 75 e por que ele importa

O número que aparece no relatório não é a média das visitas. É o percentil 75: o valor abaixo do qual ficam 75% dos carregamentos. Em outras palavras, o Google exige que três em cada quatro visitas tenham experiência boa.

Isso tem uma consequência prática que muda prioridade. Melhorar a experiência de quem já estava rápido não move o indicador. O que move é encurtar a cauda: o celular de quatro anos em rede móvel instável, longe do seu servidor. É por isso que testar só no seu MacBook com fibra produz diagnóstico otimista e inútil.

Dados de campo e dados de laboratório: qual conta?

Existem duas origens de dado, e confundi-las é a raiz da maior parte da frustração com performance.

Campo (CrUX)

O Chrome User Experience Report reúne medições anônimas de usuários reais que navegam no Chrome com a coleta ativada. É o dado que alimenta o relatório de Core Web Vitals do Search Console e a seção superior do PageSpeed Insights. É este que o Google usa para ranquear.

Ele tem três características que precisam ser entendidas antes de cobrar resultado. Usa janela móvel de 28 dias, então reage devagar. Só existe se a URL tiver volume suficiente de visitas — sites pequenos aparecem sem dado ou agrupados por origem. E reflete o mundo real, com todos os aparelhos e redes que você não controla.

Laboratório (Lighthouse)

O Lighthouse roda uma simulação controlada: um carregamento, um dispositivo emulado, uma rede definida por você. Serve para diagnosticar e para comparar antes e depois de uma mudança, no mesmo ambiente.

Ele também mede coisas diferentes. Não existe INP no laboratório, porque não há usuário clicando; o relatório mostra Total Blocking Time como aproximação. O CLS de laboratório observa apenas o intervalo do teste, e não capta o deslocamento causado por algo que o visitante fez rolando a página.

Por que a nota do Lighthouse não é a nota que ranqueia

Aquele número de 0 a 100 é uma média ponderada de métricas de laboratório, com pesos que o Google já mudou mais de uma vez entre versões. Ele foi criado para orientar desenvolvedor durante o trabalho, não para servir de critério de busca.

Dá para ter 100 no laboratório e reprovar no campo. Acontece quando o servidor responde rápido para o robô e devagar no horário de pico, quando o público real usa aparelhos mais fracos que o emulado, ou quando o problema aparece em interações que a simulação não executa.

O caminho oposto também existe: nota mediana no laboratório e campo aprovado, porque os pontos descontados estão em itens que não afetam a experiência do seu público. Use o laboratório para descobrir a causa e o campo para decidir se está resolvido. Quem inverte a ordem otimiza um placar.

Isso muda a posição do meu site no Google?

Muda pouco, sozinho. O próprio Google descreve a experiência de página como critério de desempate entre conteúdos de qualidade semelhante. Nenhum ajuste de performance vai colocar um texto raso à frente de um texto melhor.

O que muda de forma consistente é o comportamento de quem chega. Página que demora abre espaço para o visitante voltar ao resultado de busca antes de ver qualquer coisa; formulário que trava perde preenchimento na metade. Esse efeito aparece em receita antes de aparecer em posição, e é o argumento honesto para investir aqui.

Também vale o inverso: se o seu site já passa nas Core Web Vitals, mais milissegundos não trazem retorno. Nesse ponto, o dinheiro rende mais em conteúdo e arquitetura de informação. É o que costumamos avaliar junto no nosso trabalho de sites com SEO técnico, porque otimizar velocidade em um site sem conteúdo relevante é resolver o problema errado com precisão.

O que custa corrigir cada uma das Core Web Vitals

Corrigir as três métricas não custa igual, e essa diferença deveria entrar na conversa antes de o orçamento ser fechado.

CLS costuma ser o mais barato. Quase sempre é declarar dimensão de imagem, reservar espaço para o que chega depois e ajustar o carregamento de fonte. É trabalho de horas, o resultado aparece no deploy seguinte e raramente exige tocar em arquitetura.

LCP fica no meio. Trocar formato de imagem, priorizar o recurso certo e remover o que bloqueia a renderização resolve boa parte dos casos. O custo sobe quando a causa é servidor lento ou uma arquitetura que só monta a página depois de baixar todo o JavaScript — aí não é ajuste, é fundação.

INP é o que mais surpreende no orçamento. Ele cobra o custo acumulado de tudo que roda na thread principal. Quando a lentidão vem de biblioteca pesada, framework mal configurado ou scripts de terceiros que ninguém quer remover, a correção vira decisão de arquitetura e de negócio, não uma flag de build.

A consequência prática: um site reprovado nas três raramente cabe em um orçamento único e fechado. O caminho honesto é tratar CLS e LCP primeiro, esperar o campo confirmar o ganho e só então decidir se o INP justifica o investimento maior. Quem promete resolver as Core Web Vitals inteiras por um valor fixo, sem ter medido o site, está chutando o item mais caro da lista.

Por onde começar

Uma sequência que funciona e não desperdiça esforço:

1. Abra o relatório de Core Web Vitals no Search Console e veja quais grupos de URL estão reprovados. Ele agrupa páginas parecidas, o que evita corrigir uma landing por vez.
2. Escolha o grupo com mais tráfego, não o de pior nota. Corrigir uma página sem visitas não altera o percentil.
3. Rode o laboratório nessa URL para encontrar a causa, e trate uma métrica por vez.
4. Publique, e só volte a ler o campo depois de quatro semanas, por causa da janela móvel.
5. Congele o que foi conquistado: revise o impacto antes de adicionar qualquer script novo.

Esse ciclo é chato de propósito. Performance regride sozinha, porque o site ganha funcionalidade ao longo do tempo e ninguém mede o custo de cada acréscimo. Manter as três métricas na faixa boa é uma rotina, não um projeto com data de encerramento.