As Core Web Vitals mostram se a página de orçamento abre, responde ao toque e fica parada no celular do cliente. O dono do negócio confere no relatório do Search Console, separado entre celular e computador, e corrige pela métrica pior de cada grupo: imagem principal descoberta tarde no LCP, scripts de terceiros no INP e espaço não reservado no CLS.
Resumo com IA
- Nas Core Web Vitals, o LCP mede quando a foto ou o título principal aparece, o INP mede a resposta ao toque e o CLS mede quanto o layout se mexe;
- Nas Core Web Vitals, a página é boa quando 75% das visitas dos últimos 28 dias têm LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1;
- Nos dados de setembro de 2026 do CrUX, 55,9% dos sites passavam nas três métricas das Core Web Vitals, e o LCP era a que mais reprovava;
- O teste de laboratório do PageSpeed Insights não mede o INP das Core Web Vitals e mostra o Total Blocking Time como pista;
- No LCP das Core Web Vitals, o atraso costuma vir da descoberta tardia da imagem principal, e o atributo fetchpriority="high" é uma das correções mais baratas.
Core Web Vitals é o conjunto de três métricas que o Google usa para medir a experiência real de quem acessa um site, avaliando velocidade de carregamento, resposta a toques e cliques e estabilidade visual da página. Para a empresa de serviços, essas métricas mostram se a página de orçamento abre e responde rápido no celular do cliente.
No relatório de Core Web Vitals do Search Console, as três métricas são Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS), e a página é considerada boa quando 75% das visitas dos últimos 28 dias ficam com LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1.
Nos dados de setembro de 2026 do Chrome User Experience Report (CrUX), publicados nas notas mensais do relatório do Chrome em 13 de outubro, 55,9% dos sites medidos passavam nas três métricas. O LCP segue como a métrica que mais reprova, com 68,3% de aprovação, contra 81,7% no CLS e 85,4% no INP, que tomou o lugar da antiga First Input Delay (FID) em março de 2024.
Passar nas três métricas não garante posição no Google: a documentação de experiência na página, atualizada em setembro de 2026, diz que a Pesquisa mostra o conteúdo mais relevante mesmo com experiência inferior, e que a boa experiência pesa quando muitas páginas úteis disputam a mesma busca.
Na prática, é comum encontrar sites que carregam rápido no computador do escritório, mas travam no celular do cliente em uma conexão de rua mais lenta, e é exatamente esse cenário que os Core Web Vitals tentam capturar.
Índice
Como o Google avalia as Core Web Vitals?
Para avaliar as Core Web Vitals, o Google usa as visitas reais de quem navega pelo Chrome, coletadas pelo CrUX, e classifica cada grupo de páginas do site em três faixas, separadas entre celular e computador. O status do grupo é sempre o da pior métrica, segundo a Ajuda do Search Console.
| Métrica | O que mede no site | Bom | Melhorias necessárias | Ruim |
|---|---|---|---|---|
| LCP | Quando a foto ou o título principal aparece na tela | Até 2,5 segundos | Até 4 segundos | Acima de 4 segundos |
| INP | Quanto a página demora para reagir a um toque ou clique | Até 200 milissegundos | Até 500 milissegundos | Acima de 500 milissegundos |
| CLS | Quanto texto e botões mudam de lugar enquanto a página carrega | Até 0,1 | Até 0,25 | Acima de 0,25 |
Na tabela das Core Web Vitals, basta uma métrica na faixa “Ruim” para o grupo inteiro de páginas ficar como “Ruim” no celular. Por isso o dono do negócio olha primeiro a pior das três, e a página de serviço com LCP de 3 segundos e INP de 600 milissegundos tem como prioridade o tempo de resposta ao toque.
O relatório trabalha com dados de campo, as visitas reais, enquanto o PageSpeed Insights, a ferramenta gratuita do Google que testa a velocidade de uma URL, também mostra dados de laboratório, uma simulação de um único carregamento. Quando os dois discordam, o dado de campo é o que o Google usa na avaliação, e o de laboratório serve para achar a causa.
Como ver as Core Web Vitals do meu site?
Para ver as Core Web Vitals do seu site, abra o painel gratuito do Google Search Console, entre em Experiência e escolha o relatório de Core Web Vitals, separado entre celular e computador. Para uma página específica, rode a URL no PageSpeed Insights.
O dono do negócio confirma o que o relatório mostra com cinco testes feitos no próprio celular, sem acesso ao painel do site e sem instalar nada:
- Abrir o relatório de Core Web Vitals e ver, na aba de celular, se algum grupo de páginas está como “Ruim”;
- Rodar a página de serviço no PageSpeed Insights e anotar o resultado de celular;
- Abrir o site pelo celular em uma conexão de rua, fora do wifi do escritório;
- Cronometrar quanto tempo a foto ou o título principal leva para aparecer na tela;
- Tocar no botão de WhatsApp e sentir se a resposta é imediata ou trava por um instante.
O teste de laboratório do PageSpeed Insights, feito pelo Lighthouse, não mede o INP, porque nenhuma pessoa toca na página durante a simulação. No lugar dele, o Lighthouse mostra o Total Blocking Time (TBT), o tempo em que o navegador ficou ocupado demais para responder, que serve como pista do INP ruim.
Quando o Search Console mostra “Não há dados disponíveis”, o site ainda não tem visitas suficientes no Chrome para o Google montar o relatório, o que é comum em empresa local, e o PageSpeed Insights passa a ser o termômetro possível, junto com o roteiro para testar a velocidade de carregamento do site com as ferramentas gratuitas do Google.
Em site de empresa local com pouco tráfego, a nota de laboratório do PageSpeed varia de um teste para outro. Eu rodo a mesma página três vezes e olho a tendência, porque um número isolado costuma enganar mais do que ajudar.
Como melhorar o Core Web Vitals do site?
Para melhorar o Core Web Vitals do site, corrija primeiro o que o Search Console marca como “Ruim” no celular, começando pelas páginas que levam ao pedido de orçamento, e trate cada métrica pela causa dela, porque a correção do LCP não resolve o INP e vice-versa. O roteiro vai do diagnóstico à validação de 28 dias.
- Anotar no Search Console quais grupos de páginas estão como “Ruim” no celular e qual métrica derruba cada grupo;
- Corrigir a métrica pior do grupo, pela causa dela, nas páginas de serviço e de contato;
- Conferir, nos cabeçalhos do Hypertext Transfer Protocol (HTTP) que o servidor envia, se há compressão e cache, com o verificador de cabeçalhos HTTP gratuito, antes de pensar em trocar de hospedagem;
- Manter a página com menos de 500 kilobytes e até 50 recursos, a referência do próprio relatório do Search Console, e tratar esse teto como um orçamento de desempenho conferido a cada novidade que entra no site;
- Clicar em “Iniciar rastreamento” no relatório depois da correção e acompanhar a validação, que monitora as visitas por 28 dias.
Como melhorar o LCP da página?
Para melhorar o LCP, faça o navegador descobrir e baixar a imagem principal o mais cedo possível. Segundo o guia de prioridades de Core Web Vitals do web.dev, atualizado em outubro de 2024, 73% das páginas no celular têm uma imagem como elemento do LCP, e entre as páginas com LCP ruim a imagem começa a carregar 1.290 milissegundos atrasada, mais da metade do limite de 2,5 segundos.
Segundo dados reais do Chrome citados no guia do web.dev, a maioria dos sites com LCP ruim gasta menos de 10% desse tempo baixando a imagem. O atraso vem antes do download, quando a foto de capa só aparece depois que o JavaScript do slider roda ou quando ela está marcada para carregar sob demanda. Comprimir a imagem ajuda pouco se ela é descoberta tarde.
Na prática, o desenvolvedor coloca a foto de capa direto no HTML com a tag de imagem, tira dela o carregamento sob demanda e acrescenta o atributo fetchpriority=”high”, que pede ao navegador para baixá-la antes do resto. Só 15% das páginas elegíveis usavam esse atributo, segundo o Web Almanac de 2024 citado pelo web.dev, o que faz dele uma das correções mais baratas do LCP.
A foto de capa costuma ser o maior elemento da primeira dobra do site no celular (a parte da página que aparece antes de o cliente rolar a tela), e é ela que o Google cronometra. Quando a imagem já sai na hora certa e o LCP continua alto, a causa passa a ser o tempo de resposta do servidor, e aí entram a hospedagem e uma Content Delivery Network (CDN).
Como melhorar o INP do site?
Para melhorar o INP, reduza o trabalho que o navegador executa de uma vez, porque cada tarefa acima de 50 milissegundos, chamada de tarefa longa no guia do web.dev, impede a página de responder ao toque enquanto não termina. A correção é dividir essas tarefas e tirar da frente o que não precisa rodar no carregamento.
Em site de empresa de serviços, as tarefas longas costumam vir de banner de consentimento de cookies, chat, pixels de anúncio e mapas incorporados, todos rodando junto com o primeiro toque do cliente no botão de WhatsApp. Adiar esses scripts para depois do carregamento principal resolve boa parte do INP sem mexer no layout.
Na Lucas Ferraz SEO, antes de recomendar troca de hospedagem, testo a página com o banner de cookies aceito e recusado. Quando o INP muda entre os dois testes, o problema está no script do banner, e trocar de servidor não resolve.
Como melhorar o CLS da página?
Para melhorar o CLS, reserve o espaço de tudo que entra depois do primeiro carregamento. O guia do web.dev aponta que 66% das páginas têm ao menos uma imagem sem largura e altura definidas, e essa imagem nasce com altura zero e empurra o texto para baixo quando chega.
As correções do CLS são definir largura e altura em toda imagem, reservar a área de banners, avisos e vídeos incorporados antes de eles carregarem e evitar animações que mexem em margem ou borda. O resultado aparece no formulário de orçamento: o botão fica parado e o toque do cliente cai no lugar certo, com o CLS abaixo de 0,1.
O que as Core Web Vitals mudam para quem vende por orçamento?
Para quem vende por orçamento, as Core Web Vitals medem com número se o site deixa o cliente chegar ao formulário ou ao WhatsApp. As três métricas são a parte mensurável da experiência do usuário no site: o LCP diz se a oferta aparece a tempo, o INP diz se o botão responde e o CLS diz se o layout fica parado.
Uma clínica cujo botão de agendamento demora a reagir, um escritório de advocacia com formulário que muda de lugar ou uma empresa de manutenção com a foto de capa pesada perdem o contato depois de já terem sido encontrados, no momento em que o cliente decidiu chamar, com o sinal do celular oscilando entre 4G e 5G.
Nas respostas do modo de IA do Google, do ChatGPT e do Perplexity, a página citada vira porta de entrada, e um site que trava no celular perde o visitante justamente quando ele chega com a recomendação na mão. No Generative Engine Optimization (GEO), a página que a IA cita precisa abrir bem no celular, e a velocidade dela entra na consultoria de GEO junto com o texto.
Quando reviso o Core Web Vitals de um site de empresa de serviços, começo pelo grupo de páginas marcado como Ruim no celular e, dentro dele, pelas páginas que levam ao pedido de orçamento: serviço, contato e o botão de WhatsApp.
Lucas Ferraz, especialista em SEO
Perguntas frequentes sobre Core Web Vitals
Donos de site que abrem o Search Console pela primeira vez perguntam sobretudo o que cada sigla mede e quanto tempo a correção leva para aparecer, e a melhora no relatório leva 28 dias para se confirmar.
O LCP, Largest Contentful Paint, é a métrica das Core Web Vitals que mede quanto tempo o maior elemento da primeira tela leva para aparecer, em geral a foto de capa ou o título principal. A página é boa com LCP de até 2,5 segundos e ruim acima de 4 segundos, segundo o Search Console.
O CLS das Core Web Vitals mede quanto os elementos da página mudam de lugar enquanto ela carrega. É o texto que desce quando um banner aparece ou o botão que foge do dedo do cliente. A página é boa com CLS até 0,1 e ruim acima de 0,25, segundo o Search Console.
Não exatamente. Core Web Vitals inclui a velocidade de carregamento, medida pelo LCP, mas também mede se o site responde rápido a toques, pelo INP, e se o layout fica estável enquanto carrega, pelo CLS. São três problemas diferentes, e um site pode carregar rápido e ainda assim travar no botão de contato.
Sim. O PageSpeed Insights é uma ferramenta gratuita do Google que mostra, para uma URL, os dados de Core Web Vitals das visitas reais quando o site tem tráfego suficiente no Chrome, e um teste de laboratório feito pelo Lighthouse. O dado de campo é o que pesa na avaliação, e o de laboratório ajuda a achar a causa.
A melhora no relatório de Core Web Vitals leva cerca de 28 dias para aparecer por inteiro, porque o Google calcula as métricas com as visitas reais desse período. Depois de corrigir, vale clicar em “Iniciar rastreamento” no Search Console e acompanhar a validação, que segue a mesma janela de 28 dias.
Três métricas ruins ao mesmo tempo apontam para a estrutura do site
Quando LCP, INP e CLS aparecem ruins ao mesmo tempo no celular, raramente o problema é um plugin ou uma imagem isolada, e sim a estrutura do site, que já não acompanha o que o Google e o cliente esperam. Nesse caso, a criação de sites com SEO desde a estrutura costuma sair mais barata do que remendos sucessivos.
Um escritório de contabilidade que recebe a maior parte dos contatos pelo celular, por exemplo, ganha mais com a foto de capa leve e o botão de WhatsApp respondendo no primeiro toque do que com qualquer ajuste de texto, porque é nesse toque que o pedido de orçamento acontece.
Quando as Core Web Vitals continuam ruins depois das primeiras correções, peça a análise gratuita: ela confere o título e o resumo que o Google mostra, se a página está liberada para o Google e a presença na IA, e devolve os pontos por escrito, com resposta no mesmo dia útil e proposta em até 48 horas. A consultoria de SEO técnica cruza o relatório de campo com o código, e as 202 avaliações no Google, com nota 5,0, mostram como esse trabalho é conduzido.