Core Web Vitals: o que são, como medir e como otimizar (guia completo)

As Core Web Vitals são um conjunto de três métricas criadas pelo Google para medir, de forma objetiva, a experiência real que um usuário tem ao navegar em uma página: o quão rápido o conteúdo carrega, o quão responsiva a página é aos cliques e toques, e o quão estável ela é visualmente. Desde 2021, elas fazem parte dos fatores de posicionamento do Google — o que significa que afetam diretamente o quanto o seu site aparece nos resultados de busca.

Mais do que um detalhe técnico para desenvolvedores, as Core Web Vitals impactam o SEO, a taxa de conversão e a satisfação de quem visita o seu site. Neste guia completo e atualizado, você vai entender o que são as três métricas (incluindo a mudança importante de 2024, quando o INP substituiu o FID), quais são os valores ideais, a diferença entre dados de laboratório e dados de campo, como medir tudo isso e, principalmente, como otimizar cada uma delas na prática.

O que são as Core Web Vitals?

As Core Web Vitals (algo como “métricas essenciais da web”, em tradução livre) são um subconjunto das Web Vitals, a iniciativa do Google para padronizar a medição de qualidade da experiência em páginas web. Enquanto as Web Vitals incluem várias métricas, as Core Web Vitals são as três consideradas mais importantes e que se aplicam a todas as páginas.

Cada uma mede uma dimensão diferente da experiência do usuário:

• Carregamento — quão rápido o conteúdo principal aparece na tela (métrica LCP).
• Interatividade / responsividade — quão rápido a página responde quando o usuário interage (métrica INP).
• Estabilidade visual — o quanto os elementos da página “pulam” ou se deslocam inesperadamente durante o carregamento (métrica CLS).

O grande diferencial das Core Web Vitals é que elas não medem velocidade no vácuo: medem a experiência percebida por pessoas reais. Por isso se tornaram a referência do Google para avaliar se uma página entrega uma boa experiência — e um dos sinais que compõem o ranqueamento.

As três métricas das Core Web Vitals

Vamos a cada uma em detalhe, com o que medem e os valores que o Google considera bons.

LCP — Largest Contentful Paint (Maior Conteúdo com Pintura)

O LCP mede o tempo de carregamento percebido: quanto tempo leva, a partir do momento em que a página começa a carregar, até que o maior elemento visível na tela (geralmente uma imagem de destaque, um vídeo ou um bloco grande de texto) seja totalmente renderizado. É o momento em que o usuário sente que “a página carregou”.

Os valores de referência do Google são:

• Bom: até 2,5 segundos
• Precisa de melhoria: entre 2,5 e 4,0 segundos
• Ruim: acima de 4,0 segundos

O LCP é, na prática, a métrica que mais sites falham em atingir — é a mais difícil de passar, porque depende de muitos fatores: velocidade do servidor, tamanho das imagens, carregamento de fontes e scripts.

Para diagnosticar por que o LCP está alto, vale saber que ele se divide em quatro fases: o TTFB (tempo até o servidor enviar o primeiro byte), o atraso no carregamento do recurso (quanto o navegador demora para começar a baixar o elemento LCP, como a imagem de destaque), o tempo de carregamento do recurso em si, e o atraso de renderização (o tempo entre o recurso terminar de carregar e ele de fato aparecer na tela). Identificar qual dessas fases consome mais tempo é o que indica onde agir — se o gargalo está no servidor, no download da imagem ou em scripts que travam a exibição.

INP — Interaction to Next Paint (Interação até a Próxima Pintura)

Aqui está a mudança mais importante e recente das Core Web Vitals, e o ponto onde a maioria dos artigos brasileiros está desatualizada. Em março de 2024, o Google substituiu oficialmente a antiga métrica FID (First Input Delay) pela INP (Interaction to Next Paint).

O INP mede a responsividade da página: quanto tempo ela leva para responder visualmente às interações do usuário (cliques, toques, digitação) ao longo de toda a visita. A diferença para o antigo FID é fundamental: o FID media apenas o atraso da primeira interação, enquanto o INP avalia todas as interações da sessão e reporta a pior (ou quase a pior) delas. Ou seja, o INP captura muito melhor a sensação real de “site travado” que um usuário pode ter a qualquer momento da navegação.

Os valores de referência são:

• Bom: até 200 milissegundos
• Precisa de melhoria: entre 200 e 500 milissegundos
• Ruim: acima de 500 milissegundos

Se o seu site ainda é avaliado por algum material com base no FID, é hora de atualizar: o FID foi descontinuado e não é mais uma Core Web Vital.

Para entender o que torna o INP lento, ele pode ser decomposto em três partes: o atraso de entrada (input delay), que é o tempo até o navegador começar a processar a interação — geralmente porque a thread principal está ocupada com outro script; a duração do processamento, que é o tempo que o código da própria interação leva para rodar; e o atraso de apresentação (presentation delay), o tempo até a tela ser de fato repintada com o resultado. Na grande maioria dos casos, o vilão é o atraso de entrada causado por JavaScript pesado ocupando a thread principal — por isso as otimizações de INP quase sempre passam por aliviar esse JavaScript.

CLS — Cumulative Layout Shift (Mudança Cumulativa de Layout)

O CLS mede a estabilidade visual: o quanto os elementos da página se movem de forma inesperada enquanto ela carrega. Você já deve ter vivido isso — vai clicar em um botão e, no último instante, um banner carrega acima, empurra tudo para baixo e você acaba clicando em outra coisa. Esse “pulo” é exatamente o que o CLS penaliza.

Diferente das outras duas, o CLS não é medido em tempo, e sim em uma pontuação (um número sem unidade que representa a quantidade de deslocamento):

• Bom: até 0,1
• Precisa de melhoria: entre 0,1 e 0,25
• Ruim: acima de 0,25

Um CLS alto frustra o usuário e prejudica a confiança no site, especialmente em telas de checkout e formulários.

Como o Google avalia: o percentil 75 e a aprovação

Um detalhe técnico que quase ninguém explica direito, mas que faz toda a diferença: o Google não usa a média dos seus tempos. Ele avalia o percentil 75 das visitas. Na prática, isso significa que pelo menos 75% dos carregamentos da sua página precisam atingir o valor “Bom” em cada métrica para que ela seja considerada aprovada.

Há ainda dois detalhes que mudam tudo na hora de interpretar os resultados. O primeiro: a avaliação é separada por tipo de dispositivo. O Google mede as Core Web Vitals de celular e de desktop de forma independente — e é perfeitamente possível (e comum) um site passar no desktop e falhar no celular, já que aparelhos móveis costumam ter menos poder de processamento e conexões mais instáveis. Como o índice do Google é majoritariamente mobile-first, o desempenho no celular é o que mais importa — é nele que você deve focar.

O segundo: os dados de campo são agrupados por conjuntos de páginas semelhantes, não página por página isoladamente. Quando uma URL específica não tem tráfego suficiente para gerar dados próprios, o Google a avalia com base no desempenho do grupo de páginas parecidas a que ela pertence (ou do site como um todo). Por isso, melhorar a performance de um modelo de página tende a beneficiar todas as páginas daquele tipo de uma vez.

A lógica é proteger a experiência da grande maioria. Se 25% dos seus visitantes têm uma experiência ruim, isso é considerado relevante demais para ser ignorado por uma média que “esconderia” esses casos. Por isso, otimizar pensando só no “melhor caso” (um teste rápido na sua máquina veloz) engana: o que vale é como o site se comporta para o conjunto real de usuários, inclusive os de conexão e dispositivos mais modestos.

Para “passar” nas Core Web Vitals, uma página precisa estar na faixa “Bom” nas três métricas ao mesmo tempo, no percentil 75. Vale notar o tamanho do desafio. Segundo o Web Almanac 2025 (que usa dados reais do CrUX), apenas 48% das páginas no celular e 56% no desktop passam nas três métricas ao mesmo tempo. Ou seja, mais da metade da web móvel ainda entrega uma experiência que o Google classifica como “a melhorar” ou “ruim” — e é exatamente aí que está a sua oportunidade de se destacar.

Os dados também revelam qual métrica é o verdadeiro gargalo: no celular, cerca de 81% das páginas passam no CLS e 77% no INP, mas só 62% atingem um bom LCP. Em outras palavras, quando um site falha nas Core Web Vitals, o culpado quase sempre é o LCP — o carregamento. É por isso que ele costuma ser o ponto certo por onde começar a otimização.

Dados de laboratório x dados de campo: a confusão mais comum

Esta é a distinção que mais gera erro de interpretação — inclusive em quem já mexe com performance. Existem dois tipos de dados de Core Web Vitals, e eles servem a propósitos diferentes.

Os dados de campo (field data) são os reais, coletados de usuários de verdade que visitaram o seu site, por meio do CrUX (Chrome User Experience Report). São esses os dados que o Google usa para ranquear, porque refletem a experiência real, em dispositivos e conexões variados. A desvantagem é que precisam de um volume mínimo de tráfego para existir, e mostram a média dos últimos 28 dias — ou seja, não refletem mudanças recentes na hora.

Os dados de laboratório (lab data) são simulados, gerados por uma ferramenta que carrega a página em um ambiente controlado (como o Lighthouse). São ótimos para diagnosticar e testar melhorias na hora, mas não representam necessariamente a experiência real. Um detalhe importante: o INP não é medido em laboratório, porque depende de interações reais do usuário; no lab, usa-se uma métrica aproximada chamada TBT (Total Blocking Time) como referência.

A lição prática: um site pode ter nota 100 no Lighthouse (laboratório) e ainda assim falhar nas Core Web Vitals reais (campo), porque os usuários reais têm dispositivos e conexões diferentes do ambiente de teste. Por isso é um erro otimizar apenas para a nota de laboratório. Esse é, aliás, um dos pontos centrais do nosso guia sobre o que é PageSpeed e como melhorar a velocidade do site.

Vale conhecer também algumas métricas de apoio que não são Core Web Vitals, mas ajudam a diagnosticar os problemas. Além do TTFB (tempo de resposta do servidor) e do TBT (Total Blocking Time, usado no laboratório como aproximação do INP), há o FCP (First Contentful Paint) — que mede quando o primeiro conteúdo qualquer aparece na tela, enquanto o LCP mede quando o maior elemento aparece. O FCP é útil para entender a percepção inicial de velocidade: um FCP rápido faz o usuário sentir que “algo começou a acontecer”, mesmo antes de a página terminar de carregar.

Por que as Core Web Vitals são importantes

Investir nelas vale a pena por três motivos concretos:

• SEO. As Core Web Vitals fazem parte do sinal de “experiência na página” do Google desde 2021. Elas não são o fator mais forte do ranqueamento — relevância e qualidade do conteúdo pesam mais —, mas funcionam como um critério de desempate: entre duas páginas de qualidade semelhante, a mais rápida e estável leva vantagem.
• Conversão e retenção. Há uma correlação clara entre performance e resultados de negócio. Sites lentos têm taxas de abandono muito maiores: uma parcela enorme dos usuários de celular desiste de páginas que demoram mais de três segundos para carregar. Melhorar as Core Web Vitals costuma se refletir em mais vendas e menos rejeição.
• Experiência do usuário. No fim, as três métricas medem frustrações reais: esperar demais, clicar e nada acontecer, ou clicar no lugar errado porque a tela se mexeu. Resolver isso é cuidar de quem visita o seu site.

Como medir as Core Web Vitals

Há várias ferramentas gratuitas do próprio Google e de terceiros. As principais:

• PageSpeed Insights. A mais usada. Combina dados de campo (CrUX) e de laboratório (Lighthouse) numa só tela, e dá diagnósticos e sugestões. Ideal para uma visão completa de uma URL específica.

• Google Search Console. Tem um relatório dedicado de “Core Web Vitals” que mostra o desempenho do site inteiro (agrupado por tipo de página) com base em dados de campo reais. É o melhor lugar para monitorar a saúde geral do site ao longo do tempo.

• Lighthouse. Embutido nas Ferramentas do Desenvolvedor do Chrome (aba Lighthouse), gera uma auditoria de laboratório na hora. Bom para testar mudanças durante o desenvolvimento.
• Chrome DevTools (aba Performance). Para diagnóstico aprofundado de INP e CLS, permitindo ver exatamente quais interações e elementos causam problemas.
• Ferramentas de terceiros, como o GTmetrix, que organizam os diagnósticos de forma amigável. Temos um guia específico sobre como melhorar a performance do WordPress usando o GTmetrix.

A recomendação é combinar duas fontes: o Search Console para monitorar os dados reais (campo) e o PageSpeed Insights / Lighthouse para diagnosticar e testar correções (laboratório).

Como otimizar cada Core Web Vital

Aqui está a parte prática. Como cada métrica mede algo diferente, as estratégias de otimização também são específicas.

Como melhorar o LCP (carregamento)

O LCP depende muito da velocidade de entrega do conteúdo. As ações mais eficazes:

• Reduza o tempo de resposta do servidor (TTFB). Uma hospedagem rápida e bem configurada é a base — não adianta otimizar o resto se o servidor é lento para responder. Cache no servidor ajuda bastante.
• Otimize as imagens. Comprima-as, use formatos modernos (como WebP ou AVIF) e dimensione-as corretamente. A imagem de destaque (que costuma ser o elemento LCP) merece atenção especial.
• Use uma CDN (rede de distribuição de conteúdo) para entregar os arquivos a partir de servidores próximos do usuário.
• Priorize o carregamento do conteúdo “acima da dobra” (o que aparece sem rolar a tela) e adie o que não é essencial.
• Minimize CSS e JavaScript que bloqueiam a renderização.

Como melhorar o INP (responsividade)

O INP está ligado, na maioria dos casos, ao JavaScript que ocupa a thread principal do navegador e atrasa a resposta às interações:

• Quebre tarefas longas de JavaScript em pedaços menores, para que o navegador consiga responder ao usuário entre uma e outra.
• Reduza e adie scripts de terceiros (chats, pixels de rastreamento, widgets) — eles são causa frequente de lentidão na interação.
• Remova JavaScript não utilizado e otimize o código que roda durante as interações.
• Use técnicas de carregamento sob demanda para que scripts pesados só rodem quando realmente necessários.

Como melhorar o CLS (estabilidade visual)

O CLS quase sempre vem de elementos que carregam depois e empurram o conteúdo. As soluções são bem diretas:

• Defina dimensões (largura e altura) para imagens, vídeos, anúncios e embeds, para que o navegador reserve o espaço antes de carregá-los.
• Reserve espaço para conteúdo dinâmico, como banners e blocos de anúncio, evitando que eles “empurrem” o restante.
• Evite inserir conteúdo acima de algo que o usuário já está vendo, a não ser que o espaço já esteja reservado.
• Use fontes com cuidado, evitando que a troca de fonte cause um reposicionamento brusco do texto.
• Prefira animações com transform do CSS em vez de propriedades que alteram o layout (como margin ou top).

O papel da hospedagem nas Core Web Vitals

Um ponto frequentemente esquecido: por mais que você otimize imagens, código e plugins, existe um teto imposto pela infraestrutura onde o site roda. O LCP, em particular, começa com o TTFB (Time to First Byte) — o tempo que o servidor leva só para começar a responder. Se a hospedagem é lenta, sobrecarregada ou está fisicamente distante do seu público, esse atraso se propaga para todas as métricas, e nenhuma otimização de front-end compensa totalmente.

Por isso, uma hospedagem de qualidade — com bons recursos, cache eficiente e servidores bem localizados — não é um detalhe, e sim parte da fundação das suas Core Web Vitals. É o alicerce sobre o qual todas as outras otimizações se apoiam.

Perguntas frequentes

Conclusão

As Core Web Vitals traduzem, em três números objetivos, algo que todo visitante sente na pele: se a página carrega rápido (LCP), se responde bem ao toque (INP) e se é visualmente estável (CLS). Dominar esses conceitos — e lembrar que o que vale são os dados reais de campo, no percentil 75, e não a nota de laboratório — coloca você à frente da maioria dos sites, que ainda falha nessas métricas.

O caminho prático é claro: meça com o Search Console e o PageSpeed Insights, ataque cada métrica com as estratégias certas (servidor e imagens para o LCP, JavaScript para o INP, dimensões e espaço reservado para o CLS) e garanta uma base sólida de hospedagem. Lembre-se de que performance não é um projeto com fim: vale monitorar de tempos em tempos, porque uma atualização, um plugin novo ou uma mudança de conteúdo podem fazer as métricas regredirem. Cuidar das Core Web Vitals é, no fundo, cuidar de quem visita o seu site — e o Google recompensa quem faz isso bem.