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 HTTPS + HSTS Header 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. 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 Detalhamos isso em Profundidade de Cliques..
| 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 Vale ler também Mobile-First Indexing no blog..
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 No artigo JavaScript SEO, aprofundamos esse tema..
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 Detalhamos isso em Site Lento..
Pense neles como uma fundação de qualidade. Eles não vencem a corrida sozinhos. Mas a sua ausência atrapalha tudo o mais Vale ler também URLs Amigáveis para SEO no blog..
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 Vale ler também FAQ Schema e Rich Snippets no blog..
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.