Os Core Web Vitals são três métricas com que a Google mede a experiência real de uma página: LCP (velocidade de carregamento), INP (rapidez de resposta à interação) e CLS (estabilidade visual). Passas quando, no percentil 75 dos utilizadores reais, tens LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1.
Parece técnico, mas a lógica é simples: a Google quer saber se a tua página carrega depressa, responde quando lhe tocam e não salta enquanto se lê. E a fasquia é real: em maio de 2026, só 55,9% dos sites acompanhados pelo Chrome UX Report passavam as três métricas. Este guia explica cada uma sem jargão, com os valores de 2026 e o que fazer para os atingir. Faz parte do nosso pilar de SEO na era da IA.
O que são os Core Web Vitals e porque existem?
São o conjunto mínimo de métricas de experiência que a Google definiu para todo e qualquer site. Em vez de medir tudo, escolheu três dimensões: carregar (LCP), responder (INP) e manter-se estável (CLS). Os dados vêm do Chrome User Experience Report (CrUX), ou seja, de utilizadores reais do Chrome, não de testes de laboratório.
A avaliação é feita ao percentil 75 numa janela móvel de 28 dias. Tradução: passas uma métrica quando pelo menos 75% das visitas reais têm uma experiência “boa”. Não chega o teu portátil rápido no escritório; conta o telemóvel médio em rede móvel.
Quais são os valores de referência em 2026?
Os limiares para classificação “boa” mantêm-se estáveis:
- LCP (Largest Contentful Paint): até 2,5 segundos. Precisa de melhorar: 2,5 a 4s. Mau: acima de 4s.
- INP (Interaction to Next Paint): até 200 milissegundos. Precisa de melhorar: 200 a 500ms. Mau: acima de 500ms.
- CLS (Cumulative Layout Shift): até 0,1. Precisa de melhorar: 0,1 a 0,25. Mau: acima de 0,25.
As taxas de aprovação mostram onde está a dificuldade: 68,6% dos sites têm LCP bom, 81,3% têm CLS bom e 86,6% têm INP bom. O LCP é a métrica que mais chumba. E o desktop passa mais que o mobile: 57,1% contra 49,7%.
O que é o LCP e como se melhora?
O Largest Contentful Paint mede quanto tempo demora a aparecer o maior elemento visível do ecrã, normalmente a imagem de destaque ou o título principal. É a métrica que melhor traduz a sensação de “já carregou”.
As correções com mais impacto: serve imagens comprimidas e no tamanho certo (WebP ou AVIF), dá prioridade ao elemento principal com fetchpriority="high", usa uma CDN e cache no servidor, e elimina CSS e scripts que bloqueiam a renderização. Na maioria dos sites, o culpado do LCP é uma imagem hero pesada ou um servidor lento a responder.
O que é o INP e porque substituiu o FID?
O Interaction to Next Paint mede o tempo entre uma interação (clique, toque, tecla) e a próxima atualização visível do ecrã. Substituiu o FID em março de 2024 porque o FID só media a primeira interação e escondia problemas: uma página podia passar no FID e continuar lenta a responder o resto da sessão.
O INP degrada-se quando o JavaScript monopoliza a thread principal. As correções: reduzir e dividir tarefas longas de JavaScript, adiar scripts de terceiros (analytics, chats, pixels de ads), e dar feedback visual imediato à interação mesmo que o processamento demore. Se o teu site é pesado em JavaScript, o INP é o teu risco maior.
O que é o CLS e o que o provoca?
O Cumulative Layout Shift mede quanto a página “salta” durante o carregamento. Conheces a experiência: vais tocar num botão e ele foge porque carregou um banner por cima. O CLS soma todos esses saltos inesperados numa pontuação; até 0,1 é aceitável.
As causas habituais têm correção direta: imagens e vídeos sem dimensões declaradas no HTML (declara sempre width e height), anúncios e embeds que empurram conteúdo (reserva-lhes espaço fixo), e fontes web que trocam tarde (usa font-display: swap com fallback parecido). É normalmente a métrica mais barata de corrigir.
Os Core Web Vitals afetam mesmo o ranking e o negócio?
No ranking, funcionam como desempate, não como fator primário. Conteúdo relevante e autoridade continuam a pesar mais; entre páginas equivalentes, ganha a que oferece melhor experiência. Vitals fortes não salvam conteúdo fraco, mas Vitals maus tiram-te de empates que podias vencer.
No negócio, o efeito é direto e está medido. Cada segundo extra de LCP acima de 2,5 segundos reduz a conversão em 4 a 8% em média. A Rakuten 24 mediu +53,4% de receita por visitante e +33,1% de conversão nas sessões com LCP bom (case study web.dev). A Vodafone melhorou o LCP em 31% e as vendas subiram 8%. A velocidade paga-se a si própria.
Como medir: laboratório vs utilizadores reais?
Há dois tipos de dados e precisas dos dois. Os dados de campo (CrUX) são o que a Google usa para te avaliar: vês o veredicto no relatório Core Web Vitals da Search Console e no PageSpeed Insights (secção “Descobre o que os teus utilizadores reais estão a experienciar”). Os dados de laboratório (Lighthouse, a secção de diagnóstico do PageSpeed Insights) servem para descobrir porquê e testar correções antes de as lançar.
Fluxo prático: Search Console para identificar grupos de páginas a falhar, PageSpeed Insights para diagnosticar uma página exemplo, corrigir, e esperar pela janela de 28 dias do CrUX para confirmar. Os Core Web Vitals são um dos pontos do nosso checklist de SEO técnico para 2026, onde encontras o resto da camada de infraestrutura.
Perguntas frequentes
Preciso de passar as três métricas para ter benefício?
O estado “bom” da Google exige as três ao percentil 75, e é esse o objetivo. Mas o benefício é gradual: cada melhoria de LCP, INP ou CLS melhora a experiência e a conversão por si só. Começa pela métrica em que estás pior; na maioria dos sites é o LCP.
Os Core Web Vitals contam para as respostas de IA?
Indiretamente. Os motores de resposta citam páginas que conseguem obter e ler depressa, e um site lento ou instável degrada os sinais de experiência que alimentam o ranking clássico, que continua a ser a base de recuperação de muitas respostas de IA. Um site rápido não garante citações, mas um site lento dificulta-as.
Com que frequência devo verificar os Core Web Vitals?
Mensalmente chega para a maioria dos sites, mais uma verificação obrigatória depois de qualquer mudança grande: redesign, tema novo, plugin novo, migração. Lembra-te de que o CrUX usa uma janela de 28 dias: depois de corrigires, o relatório demora até um mês a refletir a melhoria completa.
