Core Web Vitals na prática: dominando LCP, INP e CLS sem achismo

Core Web Vitals deixaram de ser um assunto de nicho da engenharia de performance e viraram vocabulário obrigatório de qualquer profissional de SEO. O problema é que, na prática, a maioria das discussões trava em dois extremos igualmente inúteis: de um lado, quem trata a métrica como um número mágico que precisa ficar verde a qualquer custo; de outro, quem descarta tudo dizendo que "conteúdo bom rankeia sozinho". Nenhum dos dois entende o que essas métricas realmente medem — e, portanto, nenhum dos dois consegue melhorá-las de forma consistente.

Este texto parte de uma premissa simples: Core Web Vitals são uma tentativa do Google de traduzir a experiência percebida pelo usuário em três eixos mensuráveis. Carregamento, interatividade e estabilidade visual. Quem entende o que cada eixo tenta capturar consegue diagnosticar problemas com precisão cirúrgica, em vez de sair otimizando às cegas.

O que cada métrica realmente mede#

LCP (Largest Contentful Paint) mede quando o maior elemento visível da viewport termina de renderizar. Na prática, é o momento em que o usuário sente que "a página carregou". Esse maior elemento costuma ser uma imagem de herói, um bloco de texto grande ou um vídeo de capa. O limiar de "bom" é 2,5 segundos no percentil 75 do tráfego real, medido em dispositivos móveis. A palavra-chave aqui é percentil 75: o Google não olha para a sua sessão rápida no MacBook conectado à fibra. Ele olha para o usuário mediano-para-ruim, no 3G intermitente com um Android de entrada.

INP (Interaction to Next Paint) substituiu o antigo FID (First Input Delay) em março de 2024 e mudou o jogo. Enquanto o FID media apenas o atraso da primeira interação — uma métrica notoriamente fácil de enganar —, o INP observa todas as interações do usuário durante a visita e reporta essencialmente a pior latência entre o toque e a próxima pintura de tela. O limiar de "bom" é 200 milissegundos. Isso é muito mais honesto e muito mais difícil de gamear: se o seu menu trava ao abrir, se o botão de adicionar ao carrinho demora meio segundo para responder, o INP vai capturar.

CLS (Cumulative Layout Shift) mede quanto o layout se move de forma inesperada durante o carregamento. É a métrica da frustração: o usuário vai clicar em um link e, no último instante, um banner de cookies empurra o conteúdo para baixo, fazendo-o clicar em outra coisa. O limiar de "bom" é 0,1. Diferente das outras duas, o CLS não é medido em tempo — é uma pontuação adimensional que combina a fração da viewport afetada com a distância do deslocamento.

Dados de laboratório versus dados de campo#

Aqui mora o erro conceitual mais comum. O Lighthouse, embutido no Chrome DevTools e no PageSpeed Insights, gera dados de laboratório: uma simulação controlada, num ambiente sintético, com uma única execução. É excelente para depurar e reproduzir problemas, mas não é o que o Google usa para ranquear.

O que conta para o ranking é o dado de campo, coletado do Chrome User Experience Report (CrUX) — a telemetria real e anônima de usuários do Chrome que optaram por compartilhá-la. Esses dados aparecem no relatório de Core Web Vitals do Google Search Console e representam uma janela móvel de 28 dias. É por isso que você pode "consertar" uma página, ver o Lighthouse ficar verde, e mesmo assim continuar reprovado no Search Console por semanas: o campo precisa acumular sessões suficientes com o novo código antes de refletir a melhoria.

A regra prática: use o laboratório para diagnosticar e iterar rápido; use o campo para saber se você realmente venceu. Nunca confunda um com o outro.

Diagnosticando LCP com precisão#

Um LCP ruim quase sempre se decompõe em quatro subfases, e o segredo é descobrir qual delas domina o seu tempo. A primeira é o tempo até o primeiro byte (TTFB) — quanto o servidor demora para responder. Se o seu TTFB já come 1,2 segundo, nenhuma otimização de imagem vai salvar o LCP; o problema é backend, CDN ou cache de página ausente.

A segunda fase é o atraso de carregamento do recurso: o tempo entre o início do carregamento da página e o navegador descobrir que precisa buscar aquela imagem de herói. Aqui, fetchpriority="high" e preload no recurso do LCP são armas decisivas. A terceira é o tempo de carregamento do recurso em si — resolvido com formatos modernos (AVIF, WebP), dimensionamento correto e compressão. A quarta é o atraso de renderização: o recurso já chegou, mas a thread principal está ocupada demais para pintá-lo.

O antipadrão clássico é aplicar lazy-loading no elemento do LCP. Imagem de herói com loading="lazy" é um tiro no próprio pé: você está pedindo ao navegador para adiar exatamente o elemento cuja rapidez está sendo medida.

O INP é um problema de thread principal#

INP é, quase sempre, um problema de JavaScript disputando a thread principal. Quando o usuário toca em algo, o navegador precisa executar os manipuladores de evento, recalcular o layout e pintar. Se a thread está ocupada rodando um script de analytics de terceiros, hidratando um framework pesado ou processando um bundle gigante, a interação fica na fila.

As alavancas mais eficazes são três. Primeiro, quebrar tarefas longas: qualquer bloco de JavaScript que rode por mais de 50 milissegundos sem ceder o controle é uma tarefa longa que pode engolir uma interação. Técnicas como yield explícito com scheduler.yield() ou o velho truque de fatiar trabalho com setTimeout ajudam. Segundo, reduzir o custo de terceiros: tags de marketing, chats e pixels são os vilões mais frequentes; carregá-los de forma diferida ou em web workers muda o cenário. Terceiro, evitar hidratação desnecessária: entregar HTML já pronto no servidor e enviar o mínimo de JavaScript para o cliente é a diferença entre uma página que responde e uma que engasga. Essa disciplina de fronteira entre servidor e cliente é o mesmo princípio que sustenta uma boa arquitetura de conteúdo em topic clusters: decidir cedo o que é responsabilidade de quem evita retrabalho caro depois.

CLS é reserva de espaço, não sorte#

CLS é a métrica mais fácil de resolver e a que mais gente ignora. A causa raiz é quase sempre a mesma: elementos que entram na página sem que o espaço deles tenha sido reservado de antemão. Uma imagem sem atributos de largura e altura carrega e "empurra" o texto. Uma fonte customizada troca o glifo e reflui o parágrafo. Um anúncio injeta um iframe de 300 pixels de altura que não existia no HTML inicial.

As soluções são conhecidas há anos: sempre declare dimensões explícitas em imagens e embeds, usando aspect-ratio no CSS quando o tamanho for fluido; reserve o espaço de banners e anúncios com um contêiner de altura fixa antes mesmo do conteúdo chegar; use font-display: swap com uma fonte de fallback métrica-compatível para minimizar o reflow tipográfico. Nunca insira conteúdo acima de algo que o usuário já está lendo, a menos que seja em resposta a uma interação explícita dele.

A armadilha do "verde a qualquer custo"#

Vale um alerta estratégico. Core Web Vitals são um sinal de ranking, mas um sinal de desempate — importam de verdade quando dois resultados são comparáveis em relevância e autoridade. Nenhuma quantidade de LCP perfeito coloca uma página irrelevante à frente de um conteúdo genuinamente melhor. A performance é um multiplicador, não um substituto.

Isso significa que perseguir o último décimo de segundo numa página que já está confortavelmente na faixa verde é, quase sempre, um mau uso do seu tempo. O retorno marginal despenca. O esforço rende muito mais quando aplicado a páginas que estão na zona "precisa melhorar" (LCP entre 2,5 e 4 segundos, por exemplo), onde cruzar o limiar tem impacto real tanto na experiência quanto no sinal de ranking.

Terceiros: o custo escondido que você não controla#

Um capítulo à parte merece o impacto de scripts de terceiros, porque é onde a maioria dos sites perde a batalha sem perceber. Tags de analytics, pixels de remarketing, widgets de chat, ferramentas de teste A/B, mapas de calor, botões de compartilhamento social — cada um desses adiciona JavaScript que compete pela thread principal e frequentemente carrega recursos de domínios sobre os quais você não tem controle nenhum. O agravante é que esse custo é invisível na página de desenvolvimento, onde você testa numa máquina rápida, e só aparece no campo, no dispositivo mediano do usuário real.

A disciplina aqui é de curadoria implacável. Cada script de terceiro deveria justificar seu custo em performance com um benefício mensurável de negócio. Os que sobrevivem a esse crivo devem ser carregados da forma menos invasiva possível: com o atributo async ou defer, após a interação do usuário, ou de dentro de um web worker quando a ferramenta permitir. Uma auditoria periódica dos scripts de terceiros — listando o que cada um faz, quanto custa em milissegundos de bloqueio e quem realmente usa o dado que ele coleta — costuma revelar que metade deles pode ser removida sem que ninguém sinta falta, com ganho imediato de INP e LCP.

Vale também entender a diferença entre o custo de rede e o custo de execução de um terceiro. Um script pequeno de baixar pode ser caríssimo de executar, travando a thread por centenas de milissegundos toda vez que roda. As ferramentas de perfilamento do navegador mostram os dois separadamente, e é o custo de execução — não o tamanho do arquivo — que costuma dominar os problemas de interatividade. Otimizar a coisa errada aqui é um desperdício comum: comprimir mais um script que já era pequeno enquanto o vilão real é a execução pesada de outro que ninguém mediu.

Um fluxo de trabalho que funciona#

Na prática, um ciclo saudável de otimização de Core Web Vitals se parece com isto. Comece pelo Search Console para identificar quais grupos de URLs estão reprovando e em qual métrica — o relatório agrupa páginas por padrão de comportamento, o que economiza um tempo enorme. Pegue uma URL representativa de cada grupo e leve ao PageSpeed Insights para ver campo e laboratório lado a lado. Use o painel de Performance do DevTools, com throttling de CPU e rede ativado, para reproduzir e depurar o problema específico. Aplique a correção, valide no laboratório, e então espere — o campo levará dias a semanas para confirmar. Documente o que mudou, porque a próxima regressão vai acontecer, e você vai querer saber o que funcionou antes.

Core Web Vitals recompensam quem trata performance como uma disciplina de engenharia contínua, não como uma faxina pontual antes de uma auditoria. As três métricas mudam de nome e de limiar ao longo dos anos — o FID virou INP, os limiares se ajustam —, mas o princípio permanece: o Google está tentando medir se o seu site respeita o tempo e a atenção de quem o visita. Sites que respeitam ganham. É menos sobre enganar um algoritmo e mais sobre não fazer o usuário esperar, travar ou clicar no lugar errado.