As Core Web Vitals são as três métricas com que a Google mede como se vive uma página: quanto tempo demora a aparecer o conteúdo principal (LCP), quanto tempo a página demora a reagir quando lhe toca (INP) e quanto se mexe enquanto carrega (CLS). Uma página passa quando, em 75% das visitas reais (separadamente no telemóvel e no computador), as três métricas ficam na coluna «Boa» (web.dev):
| Métrica | Boa | A melhorar | Má |
|---|---|---|---|
| LCP (carregamento) | até 2,5 s | de 2,5 a 4 s | mais de 4 s |
| INP (resposta) | até 200 ms | de 200 a 500 ms | mais de 500 ms |
| CLS (estabilidade) | até 0,1 | de 0,1 a 0,25 | mais de 0,25 |
As siglas vêm do inglês: Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift. O INP substituiu o antigo FID a 12 de março de 2024 (web.dev). Se um guia ainda fala do FID, está desatualizado.
Contam para o posicionamento na Google?
Sim, mas não decidem tudo. A Google confirma que os seus sistemas de classificação usam as Core Web Vitals e, ao mesmo tempo, que procura sempre mostrar o conteúdo mais relevante, mesmo quando a experiência da página fica aquém (Google Search Central). Um site rápido não compensa um conteúdo que não responde ao que se procura; entre duas páginas igualmente úteis, ajuda.
Onde a velocidade mais se nota é no negócio. Num estudo encomendado pela Google à Deloitte e à 55 sobre 37 marcas europeias e norte-americanas, tornar o site móvel 0,1 s mais rápido aumentou as conversões em 8,4% nas lojas online e em 10,1% nos sites de viagens; nos sites de angariação de clientes, mais 21,6% de utilizadores chegaram à página de envio do formulário (web.dev). Os dados são de 2019 e foram medidos com métricas anteriores às atuais, mas nas lojas e nas viagens a direção é clara.
Onde ver os dados do seu site
- Dados de campo, os que a Google usa: vêm de visitas reais com o Chrome (o relatório CrUX). Encontra-os no relatório Core Web Vitals da Search Console, que resume os últimos 28 dias e agrupa as páginas semelhantes (Ajuda da Search Console), e na parte de cima do PageSpeed Insights. Se o seu site recebe poucas visitas, pode ainda não haver dados.
- Dados de laboratório: um teste simulado, como o do Lighthouse na parte de baixo do PageSpeed Insights. Ajudam a encontrar o problema, mas não são o que a Google mede. O teste do Lighthouse no PageSpeed Insights não consegue medir o INP, porque ninguém usa a página durante o teste, e usa em seu lugar o Total Blocking Time (TBT) (web.dev).
Depois de corrigir alguma coisa, pode clicar em «Iniciar rastreamento» na Search Console: a Google acompanha essas páginas durante 28 dias antes de dar o problema por resolvido.
Como melhorar cada uma
LCP: o essencial primeiro
- Não atrase a imagem principal. Nunca com carregamento diferido (
loading="lazy"), e de preferência comfetchpriority="high", para que o navegador a peça mais cedo (web.dev). - Imagens leves: em WebP ou AVIF e não maiores do que o tamanho em que são mostradas.
- Um servidor que responda depressa e uma rede de distribuição de conteúdos (CDN) perto dos seus visitantes.
- A imagem principal no HTML: se o JavaScript a acrescentar depois, o navegador não a encontra a tempo.
INP: uma página que responde logo
- Menos JavaScript, e o que restar dividido em tarefas curtas: enquanto o navegador executa uma tarefa longa, não consegue responder a um toque (web.dev).
- Reveja os scripts de terceiros, como chats, píxeis de publicidade ou widgets: todos disputam a mesma thread.
- Responda logo com algo visível, nem que seja um «a carregar», e deixe o trabalho pesado para depois.
- Uma página não demasiado grande: quanto mais elementos tiver, mais custa ao navegador desenhar cada alteração.
CLS: nada se mexe
- Largura e altura em todas as imagens e vídeos (
widtheheight, ouaspect-ratioem CSS), para que o navegador reserve o seu espaço (web.dev). - Reserve espaço para o que chega tarde: anúncios, vídeos incorporados ou um aviso que aparece no topo. Mais vale fazê-los flutuar por cima do que empurrar o conteúdo.
- Tipos de letra web com um tipo de letra de recurso ajustado às suas medidas (
size-adjust), para que o texto não salte quando muda o tipo de letra. - Anime com
transform, não movendotopouleft.
Como o fazemos na Vetro
O nosso próprio site é uma experiência 3D, e a velocidade faz parte do design desde o início:
- o texto chega no HTML;
- o logótipo do ecrã de carregamento tem prioridade alta e o seu espaço reservado;
- os tipos de letra têm tipos de letra de recurso ajustados às suas medidas;
- a cena 3D só carrega se o navegador desenhar com a placa gráfica e quem visita não tiver pedido para reduzir o movimento. Se não, recebe uma versão leve com o mesmo conteúdo.
No PageSpeed Insights, que nos nossos testes mede sem aceleração gráfica e por isso recebe essa versão leve, a página inicial obtém 100 em desempenho no telemóvel (medido a 5 de outubro de 2026). É o mesmo que aplicamos em cada site que desenhamos.
Perguntas frequentes
Se o meu site tem boa nota no PageSpeed Insights, já passa nas Core Web Vitals? Não necessariamente. A nota é um teste de laboratório; o que conta para a Google são os dados das suas visitas reais dos últimos 28 dias.
Porque é que a nota muda sempre que repito o teste? Porque as condições mudam: a rede, o servidor ou o dispositivo de teste (Chrome for Developers). Repita-o várias vezes e olhe para a tendência, não para um número isolado.
E se o meu site tem poucas visitas e não há dados de campo? Siga os dados de laboratório e corrija o que assinalarem. Quando houver visitas suficientes, a Search Console começará a mostrar os dados reais.
Fontes
- As Core Web Vitals: o que são e os seus limites (web.dev).
- O INP passa a ser uma Core Web Vital a 12 de março de 2024 (web.dev).
- A experiência da página nos resultados de pesquisa da Google (Google Search Central).
- Relatório Core Web Vitals (Ajuda da Search Console).
- Otimizar o LCP, o INP e o CLS (web.dev).
- Milliseconds make millions: o estudo da Deloitte para a Google (web.dev).
- Como se calcula a pontuação de desempenho do Lighthouse (Chrome for Developers).
