Core Web Vitals: o que são e por que seu site precisa passar

Google roda mais de 8,5 bilhões de buscas por dia e, desde junho de 2021, usa a experiência técnica da página como fator direto de ranqueamento. Não é opinião de agência de design. É o próprio buscador afirmando que velocidade, estabilidade visual e capacidade de resposta pesam na hora de decidir quem aparece primeiro nos resultados.

Se o seu site demora pra carregar, trava quando alguém clica em um botão ou os elementos pulam de lugar enquanto a página monta, o problema não é só estético. Você perde posição no Google antes mesmo de alguém ler uma linha do seu conteúdo e perde cliente que desiste no meio do carregamento.

Este post explica o que são as três métricas de Core Web Vitals (LCP, INP e CLS), qual é a meta de cada uma, como medir seu site agora com ferramentas gratuitas e o que priorizar primeiro pra sair da faixa "ruim" no relatório do Google.

O que são Core Web Vitals e por que o Google se importa

Core Web Vitals é um conjunto de três métricas que o Google usa pra medir a experiência real de quem navega em uma página: velocidade de carregamento do conteúdo principal, capacidade de resposta a cliques e toques e estabilidade visual durante o carregamento.

Elas fazem parte de um grupo maior chamado Page Experience, que também considera HTTPS, ausência de anúncios intrusivos (interstitials) e compatibilidade com dispositivos móveis. Mas as três métricas de Core Web Vitals são as únicas com peso direto e mensurável no algoritmo de busca, documentado pelo próprio Google no web.dev.

O Google classifica o desempenho de cada métrica em três faixas: bom, precisa melhorar e ruim. Essa classificação é feita no percentil 75 dos visitantes reais do site — ou seja, 75% das pessoas que acessam a página precisam ter uma experiência "boa" pra a URL ser aprovada. Não adianta o site carregar rápido só na sua máquina de desenvolvimento com internet de fibra: o que conta é o celular do seu cliente, muitas vezes em conexão 4G.

Isso muda a lógica de quem trata performance como detalhe técnico pra depois do lançamento. Se o site não passa no Core Web Vitals, ele compete em desvantagem contra concorrentes que passam, mesmo com o mesmo conteúdo e a mesma qualidade de design.

LCP (Largest Contentful Paint): a velocidade percebida

LCP mede quanto tempo leva pra o maior elemento visível da tela — geralmente uma imagem de destaque, um banner ou um bloco de texto — aparecer completamente renderizado na tela do visitante. É a métrica mais próxima do que a pessoa sente como "a página carregou".

Meta: até 2,5 segundos é bom. Entre 2,5s e 4s precisa melhorar. Acima de 4s é ruim e cada segundo a mais nessa faixa aumenta a taxa de abandono antes mesmo do conteúdo aparecer.

As causas mais comuns de LCP alto:

1. Servidor lento pra responder à primeira requisição (TTFB alto), geralmente por hospedagem compartilhada barata ou ausência de cache de servidor
2. Imagens pesadas, sem compressão ou em formatos antigos (JPEG/PNG) carregando no topo da página, em vez de formatos modernos como WebP ou AVIF
3. CSS e JavaScript bloqueando a renderização antes do conteúdo principal poder aparecer na tela
4. Fontes customizadas carregando de forma síncrona, atrasando a exibição do texto principal

Pra melhorar: comprima e redimensione imagens antes do upload, carregue a imagem principal com prioridade (fetchpriority="high") e deixe o resto da página em lazy load, migre pra hospedagem com CDN e evite frameworks que empacotam JavaScript demais pra renderizar o que deveria ser uma página estática. É o mesmo racional técnico que já detalhamos em velocidade de site e o impacto direto nas conversões: cada segundo de atraso custa conversão, além de ranking.

INP (Interaction to Next Paint): a resposta à interação

Em março de 2024, o Google substituiu o FID (First Input Delay) pelo INP como métrica oficial de responsividade dentro do Core Web Vitals. A diferença importa: FID só media o atraso do primeiro clique da visita. INP mede a responsividade da página durante toda a sessão, do primeiro ao último clique, toque ou tecla pressionada.

Meta: até 200 milissegundos é bom. Entre 200ms e 500ms precisa melhorar. Acima de 500ms é ruim — nessa faixa, o usuário sente o site travando literalmente enquanto tenta usar.

INP alto normalmente vem de:

• JavaScript pesado demais rodando na thread principal do navegador (menus animados, sliders, chats ao vivo, formulários com validação em tempo real)
• Excesso de re-renderizações em frameworks front-end mal configurados, recalculando a tela inteira a cada interação pequena
• Event listeners duplicados ou mal escritos, comum em sites montados com dezenas de plugins acumulados ao longo dos anos
• Scripts de terceiros — pixel de anúncio, chat de atendimento, ferramenta de heatmap — competindo por processamento com o conteúdo do próprio site

Pra melhorar: divida tarefas longas de JavaScript em blocos menores (requestIdleCallback ou scheduler.yield), adie o carregamento de scripts de terceiros pra depois da primeira interação do usuário e revise plugins que injetam código em toda página mesmo quando a funcionalidade não é usada ali. Sites com excesso de plugins, comum em WordPress mal configurado, costumam sofrer justamente nesse ponto.

CLS (Cumulative Layout Shift): a estabilidade visual

CLS mede o quanto os elementos da página se movem de forma inesperada enquanto ela carrega. É aquele momento de tentar clicar em um botão e o layout empurrar o botão pra outro lugar no último instante, geralmente porque uma imagem, um banner de cookies ou um anúncio carregou depois e empurrou o conteúdo visível.

Meta: até 0,1 é bom. Entre 0,1 e 0,25 precisa melhorar. Acima de 0,25 é ruim. É a única das três métricas sem unidade de tempo: é um score calculado pela distância que os elementos se deslocam multiplicada pelo impacto visual desse deslocamento na tela.

As causas mais comuns:

• Imagens e vídeos sem width e height definidos no HTML, forçando o navegador a redimensionar o espaço reservado quando o arquivo termina de carregar
• Fontes web substituindo a fonte padrão do sistema depois que o texto já apareceu na tela (efeito conhecido como FOIT/FOUT)
• Banners, pop-ups ou barras de cookie injetados dinamicamente sem reservar espaço fixo no layout
• Conteúdo carregado via JavaScript e inserido acima de um bloco que o usuário já estava vendo

CLS baixo também depende de como o layout se comporta em diferentes tamanhos de tela e orientações. Por isso vale revisar a estrutura de design responsivo mobile-first já na fase de design, não só na implementação técnica depois — layout que quebra em telas pequenas é fonte constante de deslocamento inesperado.

Como medir o Core Web Vitals do seu site

Existem duas categorias de ferramenta pra medir performance: dados de campo (o que usuários reais experimentaram de fato, com aparelho e conexão reais) e dados de laboratório (uma simulação controlada em ambiente padronizado). As duas importam, mas o Google ranqueia com base em dados de campo — a simulação é só um proxy útil pra debugar.

Ferramenta	Tipo de dado	Melhor uso
Google Search Console (relatório Core Web Vitals)	Campo	Ver quais URLs do site estão reprovando, agrupadas por padrão de página
PageSpeed Insights	Campo + laboratório	Diagnóstico rápido de uma URL específica, com lista de sugestões técnicas
Chrome UX Report (CrUX)	Campo	Dados agregados de performance em escala, útil pra comparar com concorrentes
Lighthouse (DevTools do Chrome)	Laboratório	Auditoria detalhada durante o desenvolvimento, antes de publicar a página

Pra um diagnóstico completo, siga esta ordem:

1. Abra o Google Search Console e confira o relatório de Core Web Vitals pra ver quantas URLs do site estão em cada faixa — boa, precisa melhorar ou ruim
2. Rode a página mais visitada do site no PageSpeed Insights e anote a nota exata de LCP, INP e CLS
3. Compare os dados de campo (usuários reais) com os de laboratório (simulação) — se forem muito diferentes, o problema provavelmente é específico de conexões móveis ou aparelhos mais fracos, não do ambiente de desenvolvimento
4. Priorize as páginas com mais tráfego orgânico primeiro. Corrigir a home e as páginas de serviço que geram lead vale mais do que revisar o site inteiro de uma vez

Erros que reprovam sites no Core Web Vitals com frequência

Alguns padrões aparecem o tempo todo em auditorias de sites que reprovam nas três métricas ao mesmo tempo:

• Hospedagem compartilhada barata, sem cache de servidor nem CDN configurado
• Temas de WordPress genéricos carregando CSS e JavaScript de funcionalidades que a página nem usa
• Vídeo de fundo em autoplay na home, sem otimização de peso nem compressão
• Carrossel de imagens no topo da página carregando todas as imagens de uma vez, não só a que está visível
• Chat de atendimento, pixel de rastreamento e ferramenta de heatmap carregando de forma síncrona, antes do conteúdo principal

Nenhum desses problemas é sobre estética. São decisões técnicas que ninguém revisou depois que o site foi ao ar e que continuam custando posição no Google mês após mês — muitas vezes sem que o dono do negócio saiba que o motivo da queda de tráfego é técnico, não de conteúdo. Vale cruzar esse diagnóstico com os sinais descritos em por que seu site não aparece no Google, porque performance ruim costuma ser uma das causas raiz.

Core Web Vitals também não é uma métrica isolada da acessibilidade. Um site que carrega rápido, não trava ao interagir e não desloca elementos tende a ser mais fácil de navegar por leitor de tela e por teclado. As boas práticas se sobrepõem: reduzir JavaScript desnecessário, estruturar HTML semântico e reservar espaço fixo pra imagens ajuda tanto o CLS quanto a experiência de quem usa tecnologia assistiva. Se isso ainda não é um critério formal no seu processo de desenvolvimento, vale revisar o guia de acessibilidade na web em paralelo a essa auditoria de performance. Segundo dados públicos do HTTP Archive e Chrome UX Report, a maioria dos sites no mundo ainda reprova em pelo menos uma das três métricas — corrigir isso é, na prática, uma vantagem competitiva direta contra concorrentes que não se preocuparam com o assunto.

Conclusão

Comece pela página que mais gera tráfego orgânico, não pelo site inteiro de uma vez. Rode o PageSpeed Insights nela agora, anote a nota de LCP, INP e CLS e corrija o item com pior nota primeiro — na maioria dos casos é imagem sem compressão no topo da página ou script de terceiro carregando cedo demais.

Se o diagnóstico mostrar que o problema é estrutural — tema pesado, hospedagem ruim, arquitetura do site inteira construída sem pensar em performance — corrigir página por página não resolve. Nesse cenário, o retorno real vem de reconstruir a base técnica do site com performance como requisito desde o início, não de aplicar remendos em um projeto que já nasceu pesado.