Core Web Vitals são três métricas que o Google usa para medir a experiência real do usuário em uma página: o LCP avalia a velocidade de carregamento, o INP mede a resposta às interações e o CLS verifica a estabilidade visual. Manter as três dentro das faixas recomendadas melhora a experiência, reduz a taxa de abandono e soma um sinal de ranqueamento. É um desempate valioso em buscas competitivas.
Atenção a uma mudança importante. Em 2024 o Google aposentou o antigo FID e colocou o INP no lugar. Qualquer estratégia atual de Core Web Vitals trabalha com LCP, INP e CLS.
Aqui você vê o que cada métrica mede, quais são as faixas ideais e como otimizar cada uma. Cobrimos as causas dos problemas, as soluções práticas e como medir tudo corretamente. O foco é experiência de usuário que também ajuda o ranqueamento.
O Que São Core Web Vitals
Os Core Web Vitals são um conjunto de métricas de experiência do Google. Eles medem como o usuário percebe a página na prática. Velocidade, resposta e estabilidade são os três eixos.
Essas métricas fazem parte do sinal de page experience. O Google as usa para avaliar a qualidade técnica da página. Elas refletem a frustração ou o conforto de quem navega No artigo Robots.txt e Sitemap, aprofundamos esse tema. Vale ler também Hierarquia H1-H6 no blog..
O ponto central é que elas medem a experiência real. Não é um teste de laboratório isolado, é o que o usuário sente. Por isso o Google as leva a sério Vale ler também HTTPS + HSTS Header no blog. Detalhamos isso em Local Schema Markup..
As Três Métricas em Resumo
O LCP mede quanto tempo leva para o conteúdo principal carregar. O INP mede a rapidez com que a página responde às interações. O CLS mede se os elementos pulam na tela durante o carregamento Detalhamos isso em Local Schema Markup..
Cada uma cobre uma frustração comum do usuário. Página lenta, página travada e página que se move sozinha. Juntas, elas resumem a saúde da experiência.
| Métrica | O que mede | Frustração que evita |
|---|---|---|
| LCP | Velocidade de carregamento | Esperar o conteúdo aparecer |
| INP | Resposta às interações | Clicar e nada acontecer |
| CLS | Estabilidade visual | Elementos pulando na tela |
Por Que Core Web Vitals Importam Para o Ranqueamento
O Google confirmou os Core Web Vitals como fator de ranqueamento. O peso é leve, mas real. Em disputas equilibradas, eles desempatam a favor da melhor experiência.
O efeito vai além do sinal direto. Páginas rápidas e estáveis retêm mais usuários. Menos abandono e mais engajamento reforçam o desempenho de forma indireta.
Há ainda o impacto na conversão. Uma página lenta perde vendas e contatos. Otimizar os Core Web Vitals melhora resultado de negócio, não só de SEO.
O Equilíbrio Entre Expectativa e Realidade
É importante ter expectativa realista sobre o ganho. Core Web Vitals não são um multiplicador mágico de tráfego. Eles são um entre muitos fatores de ranqueamento.
O maior valor está na combinação com bom conteúdo. Uma página relevante e rápida supera uma relevante e lenta. A técnica potencializa o conteúdo, não o substitui.
Pense neles como uma fundação de qualidade. Eles não vencem a corrida sozinhos. Mas a sua ausência atrapalha tudo o mais.
Dados de Laboratório Versus Dados de Campo
Existe uma distinção que confunde muita gente. Os Core Web Vitals têm duas fontes de dados. A de laboratório e a de campo.
Os dados de laboratório vêm de testes simulados controlados. Eles são úteis para diagnosticar e depurar problemas. Mas não refletem a experiência real dos usuários.
Os dados de campo vêm de usuários reais ao longo do tempo. São eles que o Google usa para o ranqueamento. Essa é a fonte que realmente conta.
| Tipo de dado | Origem | Uso principal |
|---|---|---|
| Laboratório | Teste simulado controlado | Diagnosticar e depurar |
| Campo | Usuários reais ao longo do tempo | Base para o ranqueamento |
A consequência prática é direta. Você melhora usando o laboratório, mas é avaliado pelo campo. Por isso uma correção leva semanas para refletir no que o Google vê.
LCP: Largest Contentful Paint
O LCP mede o tempo até o maior elemento de conteúdo aparecer. Esse elemento costuma ser uma imagem grande, um vídeo ou um bloco de texto. É o momento em que o usuário sente que a página carregou.
A métrica responde a uma pergunta simples. Quanto tempo o visitante esperou para ver o conteúdo principal? Quanto menor o LCP, mais rápida a página parece.
O LCP foca no que importa para o usuário. Não é o carregamento técnico completo, é a percepção visual. Por isso ele mede o maior elemento da área visível.
As Faixas de LCP
O Google define três faixas claras para o LCP. Elas separam a boa experiência da ruim. A meta é sempre ficar na faixa verde.
| Faixa | Tempo de LCP | Avaliação |
|---|---|---|
| Bom | Até 2,5 segundos | Meta a alcançar |
| Precisa melhorar | Entre 2,5 e 4 segundos | Zona de atenção |
| Ruim | Acima de 4 segundos | Prejudica a experiência |
A meta de 2,5 segundos vale para os dados de campo. Mais precisamente, para 75% das visitas reais. Atingir a faixa boa para a maioria dos usuários é o objetivo.
As Causas Mais Comuns de LCP Ruim
A causa mais frequente é o servidor lento. Se o servidor demora a responder, tudo atrasa. O carregamento nem começa direito.
Imagens pesadas são outra causa clássica. Uma imagem grande sem otimização trava o LCP. Ela costuma ser justamente o maior elemento medido.
Recursos que bloqueiam a renderização também pesam. CSS e JavaScript carregados antes do conteúdo atrasam a exibição. O navegador espera por eles antes de pintar a tela.
| Causa | Por que atrasa o LCP |
|---|---|
| Servidor lento | Resposta inicial demorada |
| Imagens pesadas | O maior elemento demora a carregar |
| Recursos bloqueantes | CSS e JS atrasam a renderização |
| Carregamento no cliente | Conteúdo montado tarde pelo navegador |
Como Otimizar o LCP
A otimização do LCP ataca cada causa de frente. As soluções vão do servidor às imagens. Aplicadas juntas, elas costumam resolver o problema.
Acelerar a Resposta do Servidor
Um servidor rápido é a base de tudo. Uma hospedagem de qualidade reduz o tempo de resposta. Esse é o primeiro elo da corrente.
O cache acelera as respostas repetidas. Páginas em cache são servidas sem reprocessamento. Isso corta o tempo de espera de forma drástica.
Uma CDN aproxima o conteúdo do usuário. Ela distribui cópias do site em servidores pelo mundo. O visitante recebe os dados do ponto mais próximo.
Otimizar as Imagens
A compressão reduz o peso sem perda visível de qualidade. Uma imagem menor carrega mais rápido. Esse é o ganho mais direto no LCP.
Os formatos modernos ajudam bastante. WebP e AVIF entregam a mesma qualidade com menos peso. Eles costumam ser bem menores que JPG e PNG.
O dimensionamento correto evita desperdício. Sirva a imagem no tamanho em que ela aparece. Carregar uma imagem enorme para exibi-la pequena é puro desperdício.
Priorizar o Conteúdo Visível
O preload antecipa o carregamento do elemento principal. Você sinaliza ao navegador o que carregar primeiro. A imagem ou recurso do LCP ganha prioridade.
Adie o que não é visível de imediato. Scripts e imagens abaixo da dobra podem esperar. O lazy loading carrega esses recursos só quando necessário.
O cuidado é não adiar o próprio elemento do LCP. Aplicar lazy loading na imagem principal é um erro comum. Isso atrasa justamente o que deveria carregar primeiro.
Reduzir Recursos Bloqueantes
O CSS crítico deve carregar primeiro e rápido. O restante pode ser adiado. Assim o navegador pinta a tela sem esperar tudo.
O JavaScript não essencial deve ser adiado ou assíncrono. Scripts pesados travam a renderização inicial. Liberá-los da fila crítica acelera o LCP.
Um caso real mostra o efeito combinado. Um site comprimiu as imagens, ativou CDN e adiou scripts não essenciais. O LCP de campo caiu de cerca de 4,5 para menos de 2,5 segundos em poucas semanas.
INP: Interaction to Next Paint
O INP mede a rapidez da resposta às interações do usuário. Ele avalia o tempo entre o clique e a reação visível da página. É a métrica que substituiu o antigo FID em 2024.
A diferença em relação ao FID é importante. O FID media só a primeira interação. O INP avalia todas as interações da visita, o que é bem mais rigoroso.
O INP responde a uma frustração comum. Você clica e a página parece travada por um instante. Quanto menor o INP, mais responsiva a página parece.
As Faixas de INP
O Google define três faixas para o INP. Elas separam a página ágil da lenta para responder. A meta é a faixa verde.
| Faixa | Tempo de INP | Avaliação |
|---|---|---|
| Bom | Até 200 milissegundos | Meta a alcançar |
| Precisa melhorar | Entre 200 e 500 ms | Zona de atenção |
| Ruim | Acima de 500 ms | Sensação de travamento |
Como nas outras métricas, a meta vale para o campo. Conta a experiência de 75% das visitas reais. Atingir os 200 ms para a maioria é o objetivo.
As Causas Mais Comuns de INP Ruim
O vilão principal é o JavaScript pesado. Quando o navegador está ocupado processando scripts, ele não responde ao clique. A interação fica na fila esperando.
Tarefas longas travam a linha principal de execução. Enquanto uma tarefa demorada roda, a página congela. O usuário clica e nada acontece de imediato.
Scripts de terceiros agravam o problema. Rastreadores, widgets e anúncios consomem processamento. Eles competem com a resposta às interações do usuário.
Como Otimizar o INP
A estratégia central é aliviar a linha principal. Quebre tarefas longas em pedaços menores. Assim o navegador respira entre uma e outra e responde aos cliques.
Adie o JavaScript não essencial. Scripts que não são necessários de início podem esperar. Liberar a linha principal acelera a resposta.
Audite os scripts de terceiros sem dó. Remova o que não traz valor real. Cada script removido devolve capacidade de resposta à página.
| Causa de INP ruim | Solução |
|---|---|
| JavaScript pesado | Adiar e reduzir scripts |
| Tarefas longas | Dividir em tarefas menores |
| Scripts de terceiros | Auditar e remover o desnecessário |
CLS: Cumulative Layout Shift
O CLS mede a estabilidade visual da página. Ele detecta elementos que pulam de lugar durante o carregamento. É a métrica da página que não fica quieta.
A frustração que ele combate é familiar. Você vai clicar em um botão e ele se move. Acaba clicando no lugar errado por causa do deslocamento.
O CLS não é medido em tempo, mas em pontuação. Ele soma os deslocamentos inesperados ao longo do carregamento. Quanto menor a pontuação, mais estável a página.
As Faixas de CLS
O Google define três faixas de pontuação para o CLS. Elas separam a página estável da instável. A meta é manter a pontuação baixa.
| Faixa | Pontuação de CLS | Avaliação |
|---|---|---|
| Bom | Até 0,1 | Meta a alcançar |
| Precisa melhorar | Entre 0,1 e 0,25 | Zona de atenção |
| Ruim | Acima de 0,25 | Página instável |
A pontuação é cumulativa, como o nome diz. Vários pequenos saltos somam uma nota alta. Por isso até deslocamentos discretos importam.
As Causas Mais Comuns de CLS Ruim
A causa mais comum são imagens sem dimensões definidas. O navegador não reserva o espaço delas. Quando a imagem carrega, ela empurra o conteúdo.
Anúncios e banners dinâmicos provocam o mesmo efeito. Eles aparecem depois e deslocam o que já estava na tela. O usuário perde a referência visual.
Fontes que trocam durante o carregamento também contam. O texto pode mudar de tamanho ao trocar a fonte. Isso reorganiza o layout de repente.
Como Otimizar o CLS
A solução base é reservar o espaço de cada elemento. Defina largura e altura para imagens e vídeos. Assim o navegador guarda o lugar antes de carregar.
Reserve espaço também para anúncios e elementos dinâmicos. Um contêiner com tamanho fixo evita o salto. O conteúdo dinâmico preenche o espaço já garantido.
Cuide do carregamento das fontes. Técnicas de exibição de fonte evitam a troca brusca. O texto se estabiliza sem reorganizar a página.
| Causa de CLS ruim | Solução |
|---|---|
| Imagens sem dimensões | Definir largura e altura |
| Anúncios dinâmicos | Reservar espaço fixo |
| Troca de fontes | Controlar a exibição da fonte |
Um caso real mostra o impacto da correção. Um portal definiu dimensões em todas as imagens e reservou espaço para os anúncios. O CLS caiu de 0,3 para menos de 0,1, e as reclamações de cliques errados sumiram.
As Ferramentas Para Medir os Core Web Vitals
Otimizar sem medir é trabalhar no escuro. Cada ferramenta serve a um propósito. Combiná-las dá o panorama completo.
A escolha depende do tipo de dado que você precisa. Dados de campo para o que o Google avalia. Dados de laboratório para diagnosticar e corrigir.
| Ferramenta | Tipo de dado | Melhor uso |
|---|---|---|
| Search Console | Campo | Ver o que o Google avalia no site |
| PageSpeed Insights | Campo e laboratório | Diagnóstico por página |
| Lighthouse | Laboratório | Depurar e testar correções |
| Chrome DevTools | Laboratório | Investigar problemas a fundo |
Por Onde Começar a Medição
O Google Search Console é o ponto de partida. Ele mostra os Core Web Vitals do site inteiro com dados de campo. É o reflexo direto do que o Google enxerga.
O relatório agrupa as páginas por status. Boas, que precisam melhorar e ruins. Você identifica de imediato onde estão os problemas.
Depois, use o PageSpeed Insights em páginas específicas. Ele detalha cada métrica e sugere correções. É a ponte entre o diagnóstico e a solução.
A Paciência com os Dados de Campo
Os dados de campo se atualizam ao longo de semanas. Uma correção não aparece no dia seguinte. O relatório considera uma janela de 28 dias de usuários reais.
Por isso o laboratório serve para validar a correção rápido. Você conserta e confirma no laboratório. Depois espera o campo refletir a melhoria.
Não se assuste se o número demorar a mudar. A defasagem é normal e esperada. A consistência da correção é o que conta.
Checklist de Auditoria dos Core Web Vitals
Uma checklist organiza a otimização das três métricas. Ela cobre as causas mais comuns de cada uma. Conferir item a item evita esquecimentos.
| Métrica | Item de verificação |
|---|---|
| LCP | Servidor rápido, imagens otimizadas, CDN ativa |
| LCP | Elemento principal sem lazy loading |
| INP | JavaScript adiado e tarefas divididas |
| INP | Scripts de terceiros auditados |
| CLS | Imagens com largura e altura definidas |
| CLS | Espaço reservado para anúncios e fontes |
Erros Comuns na Otimização
Alguns erros sabotam o próprio esforço de otimização. Eles são sutis e fáceis de cometer. Conhecê-los protege o resultado.
| Erro | Impacto | Correção |
|---|---|---|
| Otimizar só o laboratório | Campo não melhora, ranking não muda | Focar nos dados de campo |
| Lazy loading no elemento do LCP | LCP fica mais lento | Priorizar o conteúdo principal |
| Ignorar scripts de terceiros | INP alto persistente | Auditar e remover o desnecessário |
| Imagens sem dimensões | CLS elevado | Definir largura e altura |
| Esperar resultado imediato | Abandono precoce da otimização | Aguardar a janela do campo |
O erro mais comum é o foco no laboratório. Um número bonito no teste não significa campo bom. O Google avalia o usuário real, não a simulação.
Perguntas frequentes
O que são Core Web Vitals?
São três métricas do Google que medem a experiência real do usuário. LCP para carregamento, INP para resposta e CLS para estabilidade visual. Elas compõem o sinal de page experience.
O FID ainda existe?
Não, o Google substituiu o FID pelo INP em 2024. O INP é mais rigoroso, pois mede todas as interações. Estratégias atuais trabalham com LCP, INP e CLS.
Quais são as faixas ideais?
LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1. Essas metas valem para 75% das visitas reais. Atingi-las coloca a página na faixa boa.
Core Web Vitals garantem mais tráfego?
Não há garantia de aumento específico de tráfego. Eles são um fator de ranqueamento leve, mas real, e melhoram a retenção. O maior valor vem combinado com bom conteúdo.
Qual a diferença entre dado de campo e de laboratório?
O dado de campo vem de usuários reais e é o que o Google usa para ranquear. O de laboratório vem de teste simulado e serve para diagnosticar. Você corrige no laboratório, mas é avaliado pelo campo.
Por que minha correção não apareceu nos números?
Os dados de campo consideram uma janela de 28 dias de usuários reais. A melhoria leva semanas para refletir. Use o laboratório para confirmar a correção enquanto espera.
Qual ferramenta devo usar primeiro?
Comece pelo Google Search Console para ver o site inteiro com dados de campo. Depois use o PageSpeed Insights nas páginas problemáticas. O Lighthouse ajuda a testar as correções.
Preciso de conhecimento técnico para otimizar?
Algumas correções são simples, como comprimir imagens e definir dimensões. Outras, como dividir tarefas de JavaScript, pedem apoio técnico. Vale priorizar pelos ganhos mais fáceis primeiro.
Posicionamento Final: Experiência É a Base do Ranqueamento
Os Core Web Vitals traduzem em números a experiência do usuário. Quem otimiza LCP, INP e CLS melhora o que o visitante sente. Esse cuidado se reflete em retenção e em um sinal de ranqueamento.
A chave é tratá-los como fundação, não como atalho. Eles potencializam o bom conteúdo, não o substituem. Página rápida e relevante supera página rápida e vazia.
Quem domina as três métricas e a diferença entre campo e laboratório otimiza com método e paciência. O próximo passo é abrir o Search Console e ver onde o seu site está hoje. A vantagem fica com quem trata a experiência do usuário como a base de todo o ranqueamento.