Core Web Vitals: o que realmente é medido

O que são, em uma frase cada

Core Web Vitals são três métricas que o Google escolheu como proxy da experiência de carregamento e uso de uma página. Elas não medem se a sua página é bonita ou útil. Medem três frustrações específicas e mensuráveis:

• LCP (Largest Contentful Paint): quanto tempo até o maior elemento visível da tela inicial aparecer. Responde "quando eu vi alguma coisa que importa?".
• INP (Interaction to Next Paint): quanto tempo a página leva para responder visualmente depois que você toca em algo. Responde "quando eu toco, ela reage?".
• CLS (Cumulative Layout Shift): quanto o conteúdo pula de lugar sozinho durante o uso. Responde "o botão ainda vai estar onde eu estou mirando?".

As três foram escolhidas porque descrevem coisas que o usuário sente e que dependem de decisões de quem construiu a página. Nenhuma delas mede velocidade de conexão do visitante, e é por isso que dá para melhorá-las de verdade.

Os limiares oficiais, e a regra do percentil 75

Falta a parte que quase nunca é citada junto e que muda tudo: esses limiares não são aplicados sobre a média. São aplicados sobre o percentil 75 das visitas reais, em uma janela móvel de 28 dias, separando celular de computador.

Percentil 75 significa que 75% dos carregamentos precisam estar abaixo do limiar. Traduzindo para consequência prática: a sua média pode ser ótima e a sua página ser classificada como ruim, porque um quarto dos seus usuários tem aparelho mais fraco ou rede pior. Otimizar para a média é otimizar para quem já estava bem servido.

A janela de 28 dias tem outro efeito colateral que assusta quem não sabe: depois de um deploy que corrige o problema, o relatório não muda no dia seguinte. Ele muda gradualmente, ao longo de semanas, conforme visitas antigas saem da janela. Isso não é bug e não adianta redeployar.

Campo e laboratório: a confusão que faz gente consertar o nada

Esta é a seção mais importante do artigo. Quando você abre o PageSpeed Insights, recebe dois relatórios na mesma tela, e eles medem coisas diferentes com nomes parecidos.

A consequência prática é dura: o Lighthouse não mede INP. Ele não pode, porque ninguém tocou na tela. No lugar, ele reporta TBT (Total Blocking Time), que é uma aproximação razoável do bloqueio da thread principal, mas não é a mesma coisa. Dá para ter TBT baixo e INP ruim, e o contrário também.

O CLS também difere. Em laboratório, ele é medido apenas durante o carregamento. Em campo, ele acumula durante toda a vida da página, incluindo o que pula depois que o usuário rolou, clicou em algo ou abriu um acordeão.

LCP: por que a sua página demora a mostrar algo

O LCP registra quando o maior bloco de conteúdo visível terminou de ser pintado. Costuma ser a imagem do topo, um bloco de texto grande ou um vídeo de fundo. O primeiro passo de qualquer diagnóstico é descobrir qual elemento é o LCP naquela página, porque otimizar outro não muda nada. O Chrome DevTools e o próprio relatório do Lighthouse informam isso.

Depois de identificado, o tempo total se decompõe em quatro pedaços. Descobrir em qual deles está o gasto é o que separa correção de chute:

1. Tempo até o primeiro byte. Servidor lento, redirecionamento em cadeia, resposta gerada dinamicamente sem cache. Página estática servida de CDN resolve quase todo esse pedaço.
2. Atraso até começar a baixar o recurso. O navegador só descobriu a imagem depois de baixar e processar o CSS, ou ela é injetada por JavaScript. Aqui entram preload e fetchpriority="high".
3. Tempo baixando o recurso. A imagem é grande demais para o espaço em que aparece, ou está num formato caro.
4. Atraso até pintar. CSS ou JavaScript bloqueando a renderização, ou conteúdo que só existe depois que o JavaScript roda.

As correções que mais rendem

• Nunca colocar loading="lazy" na imagem do topo. É o erro mais comum e mais caro: o desenvolvedor aplica lazy loading em todas as imagens de uma vez e adia justamente a que define o LCP.
• Servir a imagem do topo dimensionada e em formato moderno. Como fazer isso sem perder qualidade está em o guia de otimização de imagem.
• Cortar CSS e JavaScript que bloqueiam a renderização. Script de terceiro no head sem defer é o suspeito número um.
• Se o LCP for texto, garantir que a fonte não atrase a pintura. Esse mecanismo tem armadilhas próprias e está detalhado em como hospedar fonte própria sem atrasar o carregamento.
• Evitar que o conteúdo do topo dependa de renderização no cliente. Se o herói só existe depois do JavaScript executar, o LCP herda todo o custo do bundle.

INP: por que a página trava quando alguém toca

O INP mede o intervalo entre a interação do usuário e a próxima pintura da tela. Ele observa todas as interações da sessão e reporta praticamente a pior delas. Um único botão ruim contamina a métrica da página inteira.

Também se decompõe em três partes, e a maior parte das pessoas otimiza a errada:

• Atraso de entrada. A thread principal estava ocupada com outra coisa quando o dedo tocou. Culpa quase sempre de tarefas longas de terceiros, como scripts de rastreamento e chat.
• Tempo de processamento. O seu próprio manipulador de evento é pesado.
• Atraso de apresentação. O navegador precisou recalcular layout e repintar antes de mostrar o resultado. DOM enorme e CSS caro pesam aqui.

O que costuma resolver

• Quebrar tarefas longas. Qualquer bloco acima de 50 ms na thread principal é candidato. Ceder o controle ao navegador entre pedaços de trabalho resolve mais que micro-otimizar código.
• Dar retorno visual imediato e adiar o trabalho. Pinte o estado de "clicado" primeiro e só depois faça a conta pesada. O INP mede até a pintura, não até o fim da lógica.
• Auditar terceiros. Chat, mapa incorporado, pixel de rede social e teste A/B são as causas mais frequentes de INP ruim em landing page. Carregue sob demanda o que não é essencial.
• Reduzir o tamanho do DOM. Página construída em construtor visual costuma ter milhares de elementos aninhados, e cada recálculo de layout custa proporcional a isso.

CLS: por que o conteúdo pula

O CLS soma os deslocamentos inesperados de layout, ponderados pelo tamanho da área afetada e pela distância que ela se moveu. Não tem unidade, é um índice. Deslocamento causado por ação do usuário dentro de uma janela de 500 ms não conta, e é por isso que abrir um acordeão não penaliza a métrica.

As causas são quase sempre estas cinco:

O CLS é a métrica mais barata de resolver das três, e a que mais irrita o usuário quando está ruim. Deslocamento de layout é a causa direta do toque errado: a pessoa mira num link, o conteúdo sobe e ela clica em outra coisa.

Um fluxo de medição que não engana você mesmo

1. Comece pelo campo. Abra o PageSpeed Insights e leia primeiro o bloco de usuários reais. Se ele não existir, pule direto para instrumentar a página com a biblioteca web-vitals e volte daqui a algumas semanas com dado próprio.
2. Descubra a métrica que está falhando no percentil 75, e separando celular de computador. Não otimize as três de uma vez.
3. Reproduza em laboratório com throttling de rede e de CPU ativados. Testar no seu desktop com fibra é medir uma página que nenhum cliente seu acessa.
4. Identifique o elemento ou a interação culpada no painel de performance do DevTools, não no palpite.
5. Corrija uma coisa por vez e compare o laboratório antes e depois. É o único jeito de saber se a mudança fez algo.
6. Espere o campo confirmar. Semanas, não horas. Só o campo prova que o usuário real melhorou.

A pergunta comercial de fundo, sobre quanto essa melhora vale em dinheiro, tem um artigo próprio: o que a velocidade faz com a conversão. Aqui interessa o método.

Cinco erros que continuam sendo repetidos

• Perseguir a nota de performance do Lighthouse. Ela é uma média ponderada de métricas de laboratório e não é o que classifica a sua página. Serve como termômetro de diagnóstico, não como meta.
• Aplicar loading="lazy" em tudo. Abaixo da dobra, ajuda. No elemento de LCP, piora a métrica principal para economizar bytes que seriam baixados de qualquer jeito.
• Achar que passou porque a média passou. A avaliação é no percentil 75. Se um quarto do seu público usa aparelho mais lento, é ele quem decide a sua nota.
• Otimizar a home e esquecer as outras páginas. A avaliação é por URL. A página que recebe o anúncio pode estar péssima enquanto a home está impecável.
• Tratar Core Web Vitals como projeto de SEO. Elas são um sinal de classificação, entre muitos, e relevância pesa mais. O retorno real está na experiência de quem já chegou, não em subir posições.