Quase todo guia sobre Core Web Vitals segue o mesmo roteiro: apresenta as três métricas, mostra os limites, indica umas ferramentas e lista dicas de otimização. Tudo certo, e tudo pensado para uma página de cada vez. Só que o Google não olha o seu site uma página de cada vez, e a empresa que corrige a URL errada gasta semanas de desenvolvimento sem mudar nada no relatório.
Este guia explica as métricas, mas o foco está no que os primeiros resultados da busca deixam de fora: como o Search Console julga o site inteiro, por que um grupo de páginas pode reprovar por causa de uma única métrica e por que a página inicial é, nos dados mais recentes do mercado, a que mais reprova. No fim, você sai com uma ordem de ataque para corrigir o que de fato pesa.
O que são as Core Web Vitals e o que cada métrica mede?
Core Web Vitals são um conjunto de três métricas criadas pelo Google para medir a experiência de quem usa uma página, e não a percepção de quem a construiu. Cada uma cobre um momento da visita: o carregamento, a resposta à interação e a estabilidade visual. O ponto decisivo é que elas são medidas com usuários reais, a partir do Chrome UX Report (CrUX), a base que reúne dados de navegação de usuários do Chrome.
- LCP (Largest Contentful Paint): o tempo até o maior elemento visível da tela aparecer, em geral a imagem de destaque, um vídeo ou um bloco grande de texto. É a resposta à pergunta “a página já carregou?”.
- INP (Interaction to Next Paint): o tempo que a página leva para responder a cliques, toques e teclas durante toda a visita. O valor final é a interação mais lenta observada, descontados os casos extremos.
- CLS (Cumulative Layout Shift): a soma dos deslocamentos inesperados de layout ao longo da visita. É o botão que muda de lugar no instante em que o dedo vai tocá-lo.
Cada métrica tem três faixas. O relatório do Search Console usa exatamente estas:
| Métrica | Bom | Precisa melhorar | Ruim |
|---|---|---|---|
| LCP (carregamento) | até 2,5 s | até 4 s | acima de 4 s |
| INP (resposta à interação) | até 200 ms | até 500 ms | acima de 500 ms |
| CLS (estabilidade visual) | até 0,1 | até 0,25 | acima de 0,25 |
Ajuda do Google Search Console, “Core Web Vitals report”, seção Status definitions.
Um detalhe que muda a leitura: o número exibido é o percentil 75 das visitas dos últimos 28 dias. Na ajuda do Search Console, o LCP do grupo é descrito como o tempo que 75% das visitas levaram, ou menos, para chegar ao maior conteúdo. Ou seja, o resultado reflete o quarto de visitantes com a pior experiência, não a média, e muito menos o teste feito no computador do escritório.
As Core Web Vitals influenciam o ranking no Google?
Sim, mas com uma ressalva que o próprio Google repete e que boa parte dos artigos omite. A página oficial sobre experiência na página, atualizada em setembro de 2026, é direta nos dois sentidos:
A mesma página acrescenta que, quando há muito conteúdo útil disponível para uma busca, uma boa experiência pode contribuir para o sucesso, e que buscar uma nota perfeita só por SEO pode não ser o melhor uso do tempo. A nossa leitura: Core Web Vitals funcionam como critério de desempate entre páginas igualmente relevantes, e como fator de conversão para quem já chegou. Não compensam conteúdo fraco, mas podem custar a posição quando o concorrente responde tão bem quanto você.
Outro trecho vale para quem administra o site como um todo: o Google diz que avalia a experiência em geral por página, mas que também tem algumas avaliações no nível do site. É mais um motivo para olhar o relatório agregado, e não só a URL que está aberta na tela.
O que mudou nas Core Web Vitals com a chegada do INP?
A mudança mais recente nas três métricas aconteceu em 12 de março de 2024, quando o INP substituiu o FID (First Input Delay) como métrica de resposta. O anúncio do web.dev, “Interaction to Next Paint becomes a Core Web Vital on March 12”, explica que o FID deixou de fazer parte do programa e que o Search Console removeu o FID na mesma data.
A troca não foi cosmética. O FID media só o atraso da primeira interação; o INP observa as interações de toda a visita. Um site que respondia bem ao primeiro toque e travava no filtro de produtos passava no FID e pode reprovar no INP. Se você encontrar material que ainda apresenta o trio como LCP, FID e CLS, ele é anterior a 2024 e precisa ser lido com esse desconto.
Desde então, os limites seguem os mesmos: LCP até 2,5 s, INP até 200 ms e CLS até 0,1. O que mudou de 2024 para 2025 foi o desempenho do mercado, não a régua, como mostram os números do Web Almanac mais adiante.
Como o Search Console avalia as Core Web Vitals do site inteiro?
Este é o ponto que muda a forma de trabalhar. O relatório de Core Web Vitals do Search Console não foi feito para mostrar o status de uma URL específica; a ajuda do Google diz isso com todas as letras. Ele foi feito para mostrar o desempenho do site como um todo e para localizar problemas que afetam muitas páginas ao mesmo tempo.
Para isso, o Google junta as URLs em grupos de páginas parecidas, que presumivelmente usam o mesmo modelo e sofrem dos mesmos problemas: todas as páginas de produto, todos os posts, todas as páginas de serviço. O status de LCP, INP e CLS vale para o grupo inteiro, mesmo que uma URL isolada esteja melhor ou pior.
Três consequências práticas saem dessa regra:
- Uma métrica derruba o grupo. Melhorar o que já está bom não muda o status; só a métrica pior muda.
- Um modelo de página derruba dezenas de URLs. Se o template de post tem um banner que empurra o texto, todos os posts herdam o CLS ruim. A correção também é em lote: arrumou o modelo, arrumou o grupo.
- O celular e o desktop são julgados separadamente. Um grupo pode estar bom no desktop e precisar melhorar no celular; a ajuda do Google traz exatamente esse exemplo.
O relatório ainda dá uma pista de onde começar dentro do grupo: os membros aparecem ordenados por impressões, da maior para a menor. As URLs do topo da lista são as que mais pesam no status, e a ajuda recomenda corrigi-las nessa ordem.
E quando o grupo não tem dados suficientes?
Por privacidade, um grupo precisa de um volume mínimo de dados para aparecer. Quando não tem, o Search Console cria um grupo de origem, que soma todas as URLs do mesmo protocolo e host, por exemplo, tudo o que está sob https://www.seusite.com.br. Se nem a origem tiver dados, o site simplesmente não aparece no relatório.
Duas observações importam para empresa média. Primeiro, a origem inclui o protocolo, então http:// e https:// são origens diferentes. Segundo, o grupo de origem mistura páginas que vendem com páginas que ninguém visita: o status dele diz algo sobre o site, mas pouco sobre a landing page da campanha.
O corte de volume vem do próprio CrUX. A metodologia do Chrome UX Report informa que só entram páginas e origens “suficientemente populares”, com um número mínimo de visitantes que o Google não divulga, e que precisam ser publicamente encontráveis. Para a leitura de uma URL isolada quando o PageSpeed Insights avisa que não há dados de campo, o caminho está no nosso guia sobre como ler o PageSpeed Insights começando pelo campo; aqui o assunto é o site.
Qual a diferença entre o Search Console, o CrUX e o Lighthouse?
As três ferramentas aparecem juntas em toda conversa sobre velocidade, e confundi-las é a origem de muito retrabalho. Elas respondem perguntas diferentes:
| Search Console | CrUX | Lighthouse | |
|---|---|---|---|
| De onde vem o dado | Do CrUX, usuários reais | Usuários reais do Chrome | Um carregamento simulado |
| Unidade de análise | Grupos de URLs e origem | URL ou origem | Uma URL, no momento do teste |
| Mede INP? | Sim | Sim | Não; usa o Total Blocking Time como pista |
| Pergunta que responde | Onde o site reprova, e em quantas páginas? | Como foi a experiência real nos últimos 28 dias? | Por que esta página está lenta? |
| Quando usar | Priorizar e validar a correção | Conferir uma URL ou um concorrente | Achar a causa e testar antes de publicar |
Elaborado pela Alliance Comunicação a partir da Ajuda do Search Console e da documentação do CrUX.
A ajuda do Search Console avisa que o número de uma URL no PageSpeed Insights pode não bater com o do grupo, porque aquela URL pode ser um ponto fora da curva. Não é erro de nenhuma das duas ferramentas: uma fala da página, a outra do conjunto.
Quantos sites passam nas Core Web Vitals hoje?
Menos da metade, no celular. O retrato mais recente é o capítulo de performance do Web Almanac 2025, publicado pelo HTTP Archive com dados do CrUX de julho de 2025, cobrindo milhões de sites.
O avanço no celular é real, mas lento: quatro pontos em um ano. E a distribuição por métrica mostra onde está o gargalo. No celular, o CLS e o INP já passam em quase quatro de cada cinco sites; o LCP fica para trás, com 62%, e ainda tem 13% de sites na faixa ruim, quase o dobro dos 7% do desktop. Como o site precisa passar nas três ao mesmo tempo, a métrica mais fraca é a que define o resultado, a mesma lógica do grupo no Search Console.
Por que a página inicial é a que mais reprova?
Aqui está o dado que quase ninguém usa. Além dos números por site, o Web Almanac 2025 compara a página inicial com as páginas internas, a partir de dados do CrUX por URL:
O Almanac aponta dois motivos. A home costuma ser a primeira navegação do visitante, sem nada guardado em cache, e precisa baixar e executar mais recursos; quem navega para uma página interna já chega com parte dos arquivos no aparelho. E a home muda com mais frequência e concentra componentes dinâmicos, como carrossel, vídeo de fundo, banner de campanha e pop-up, enquanto as internas tendem a seguir modelos mais estáveis.
Os números por métrica ajudam a localizar a diferença. No celular, a home tem INP melhor que as internas (80% bom contra 69%) e CLS quase igual (79% contra 81%), segundo as Figuras 7.15 e 7.19 do mesmo capítulo. Se a home perde no total por 11 pontos, mesmo indo melhor no INP e quase empatando no CLS, a leitura que fazemos é que o peso está no carregamento, o LCP, coerente com a explicação do cache e da imagem de destaque. O Almanac não publica o LCP separado por tipo de página, então trate isso como inferência, a ser confirmada no seu próprio relatório.
Para a empresa média, isso importa por um motivo simples: a home costuma ser a porta de entrada de quem busca a marca pelo nome, de quem clica no perfil do Instagram e de quem chega pelo anúncio institucional. É a página com mais primeiras visitas e, pelos dados, a que mais falha justamente na primeira visita.
Qual métrica das Core Web Vitals corrigir primeiro?
A ordem que recomendamos junta a regra do Search Console com os dados de mercado. A própria ajuda do Google manda corrigir primeiro o que está “ruim” e, dentro de cada status, o que afeta mais URLs ou as URLs mais importantes. Traduzido em sequência de trabalho:
1. Comece pelo celular
O celular é onde o mercado mais reprova (48% de aprovação contra 56% no desktop) e, na maioria dos sites de empresa, de onde vem a maior parte das visitas. Confira no seu analytics antes, mas não comece pelo desktop por ser mais fácil de testar.
2. Ataque os grupos “ruins” antes dos que “precisam melhorar”
Um grupo que sai de ruim para precisa melhorar já deixa de ser o pior do relatório. Dentro do grupo, siga a ordem de impressões que o Search Console mostra: as primeiras URLs são as que mais mexem no status.
3. Dentro do grupo, ataque só a pior métrica
Como o status é o da métrica mais lenta, otimizar o que já está verde não move o ponteiro. Se o grupo está ruim por CLS, a semana inteira vai para o CLS.
4. Trate a home como um grupo à parte
A página inicial costuma ter modelo próprio e mais elementos dinâmicos que qualquer outra. Rode o PageSpeed Insights nela, confira qual é o elemento de LCP no celular e o que acontece antes dele aparecer.
5. No LCP, olhe primeiro a imagem de destaque e o servidor
O Web Almanac 2025 mostra que em 76% das páginas no celular o elemento de LCP é uma imagem, que cerca de 16% das páginas ainda aplicam carregamento preguiçoso (lazy loading) justamente nessa imagem, atrasando o conteúdo principal, e que o atributo fetchpriority="high", que pede ao navegador prioridade para ela, aparece em só 17% das páginas no celular com imagem de LCP. Do lado do servidor, só 44% dos sites têm tempo de resposta (TTFB) bom no celular. São quatro pontos de verificação baratos antes de qualquer reforma maior.
Como medir e validar a correção no Search Console?
Corrigir é metade do trabalho; a outra metade é provar que funcionou, e o relatório tem um fluxo próprio para isso. O roteiro:
- Antes de mexer, registre o estado atual: quantas URLs em ruim, precisa melhorar e bom no celular e no desktop, e qual o valor do grupo na métrica-problema.
- Teste a correção no laboratório, com o PageSpeed Insights ou o Lighthouse, antes de publicar, para confirmar que a causa foi atacada.
- Publique e, na página de detalhes do problema, clique em “Iniciar acompanhamento” (Start Tracking) para abrir a validação.
- Espere a janela inteira. A validação acompanha 28 dias; se o problema aparecer em qualquer URL nesse período, ele não é dado como corrigido.
- Se a validação falhar, corrija o que restou e inicie uma nova validação, que reinicia a contagem.
A ajuda também explica um susto comum: o status de muitas páginas pode mudar sem que ninguém tenha mexido no site. Quando várias URLs estão no limite entre duas faixas, um evento pequeno, como um pico de tráfego ou um serviço de imagens mais lento, empurra todas de uma vez. Por isso vale anotar o valor do grupo, e não só a cor.
Para quem quer entender os outros relatórios da ferramenta e o que eles deixam de fora, o guia sobre o que os relatórios do Search Console não mostram complementa esta leitura.
Quais são os erros mais comuns com Core Web Vitals?
- Corrigir a página que está aberta, não o grupo. Uma URL perfeita dentro de um grupo ruim não muda o relatório; o modelo de página, sim.
- Otimizar a métrica que já está boa. O status é o da pior métrica, então o esforço nas outras não aparece.
- Medir só no desktop. É onde o mercado mais passa e, em geral, onde menos visitas acontecem.
- Esquecer a home porque “é só uma página”. É a que mais reprova e a que recebe as primeiras visitas de quem busca a marca.
- Comemorar no dia seguinte. O dado é de 28 dias; a melhoria aparece aos poucos e a validação leva o mesmo tempo.
- Ler material com FID. A métrica foi substituída pelo INP em março de 2024; diagnóstico baseado em FID está desatualizado.
- Tratar Core Web Vitals como atalho de ranking. O Google diz que relatório verde não garante o topo; conteúdo relevante continua mandando.
O que muda por tipo de negócio?
A lógica de grupo e de pior métrica vale para todos, mas o ponto de partida muda conforme o site:
| Tipo de site | Onde costuma reprovar | Por onde começar |
|---|---|---|
| Institucional de serviços | Home com vídeo ou carrossel no topo; poucas visitas nas internas | LCP da home no celular; conferir se o relatório mostra grupos ou só a origem |
| E-commerce | Páginas de produto e de categoria, com filtros e scripts de terceiros | INP no grupo de produto, seguindo a ordem de impressões |
| Blog ou portal com anúncios | Espaços de anúncio e banners sem tamanho reservado no modelo de post | CLS no grupo de posts: corrigir o modelo arruma todas as URLs |
| Landing pages de campanha | Imagem de destaque pesada e páginas que viram grupo próprio ou caem na origem | LCP no celular e validação de 28 dias antes de escalar a verba |
Elaborado pela Alliance Comunicação com base na prática de projetos de SEO e desenvolvimento web.
Em todos os casos, o pedido certo para quem cuida do site é o mesmo: “o grupo X está ruim no celular por causa da métrica Y; corrija o modelo e abra a validação”. É um pedido verificável, com prazo de conferência conhecido, muito mais útil que “deixar o site mais rápido”.
Por onde começar hoje?
Abra o relatório de Core Web Vitals do Search Console no celular, anote os grupos ruins e a métrica que derruba cada um, e coloque a página inicial na lista mesmo que ela não apareça entre os exemplos. Ataque um grupo e uma métrica por vez, começando pelo LCP quando ele estiver entre os problemas, e abra a validação ao publicar a correção.
Core Web Vitals são uma das frentes técnicas do trabalho de SEO e GEO da Alliance, que trata desempenho, rastreamento e conteúdo como um conjunto. Se você quer saber onde a velocidade do site entra entre as prioridades do seu marketing, o diagnóstico de marketing gratuito devolve essa ordem em cerca de 30 minutos.