Core Web Vitals: quanto performance realmente pesa no ranking

Core Web Vitals produzem dois tipos de reação, as duas erradas.

A primeira trata performance como fator decisivo de ranqueamento e gasta meses perseguindo nota verde em página que não responde a nenhuma busca. A segunda trata como irrelevante porque "conteúdo é o que importa" e deixa um site que demora oito segundos para mostrar qualquer coisa no celular.

A posição defensável está no meio, e o próprio Google é bem explícito sobre onde.

As três métricas

LCP (Largest Contentful Paint) mede quando o maior elemento visível da tela termina de carregar. É a aproximação mais próxima de "quando a página parece pronta". Bom até 2,5 segundos.

INP (Interaction to Next Paint) mede quanto tempo a página demora para responder visualmente a uma interação: clique, toque, tecla. Substituiu o FID, que media apenas o primeiro atraso. Bom até 200 milissegundos.

CLS (Cumulative Layout Shift) mede quanto o conteúdo se move sozinho durante o carregamento. É a métrica do botão que muda de lugar no instante em que você vai clicar. Bom até 0,1.

O peso real no ranqueamento

A documentação do Google é direta sobre isso: a experiência da página é considerada, e conteúdo relevante continua prevalecendo. Não existe substituição de qualidade de resposta por velocidade.

Na prática, o que eu observo é o seguinte:

Performance muito ruim atrapalha. Não como penalidade, mas como atrito. Página que demora a aparecer perde visitante antes de ser lida, e o comportamento resultante não ajuda em nada.

Performance boa não compensa conteúdo fraco. Página instantânea que responde mal à busca continua atrás de página lenta que responde bem. Isso é o que mais gente gostaria que fosse diferente.

A diferença entre "bom" e "ótimo" raramente muda posição. Sair de LCP de 6 segundos para 2,5 é um trabalho com efeito perceptível. Sair de 2,5 para 1,8 é um trabalho de engenharia com efeito de busca próximo de zero.

O que costuma causar cada problema

LCP alto é quase sempre imagem. Imagem grande sem compressão, sem dimensão declarada, carregada por script em vez de estar no HTML inicial. Depois vem fonte externa que bloqueia a renderização, e servidor lento em responder o primeiro byte.

INP alto é JavaScript. Script de terceiro que ocupa a thread principal, e aqui a lista é previsível: tag de chat, mapa de calor, gerenciador de tags carregando dez ferramentas. O diagnóstico mais rápido é desativar tudo e medir de novo.

CLS alto é dimensão faltando. Imagem sem width e height, banner que é inserido no topo depois do carregamento, fonte que troca e muda a altura do texto, aviso de cookies que empurra o conteúdo para baixo.

Quando priorizar, e quando deixar para depois

Vale priorizar quando o dado de campo aponta a maioria das URLs como ruim, quando o site é loja ou gera lead e a perda tem valor calculável, ou quando o problema está em um template, e portanto uma correção resolve o site inteiro.

Vale deixar para depois quando o site já está na faixa boa e alguém quer chegar ao verde perfeito, quando a causa é um script de terceiro que a operação comercial usa e não abre mão, ou quando o site não tem conteúdo que responda às buscas do setor. Nesse último caso, performance é o problema menos urgente que existe: não há o que carregar rápido.

A ordem que eu uso é essa: primeiro o site ser indexável, depois existir conteúdo que responda à busca, depois performance. Inverter essa ordem produz sites muito rápidos que ninguém encontra.