Core Web Vitals explicados para donos de sites

Os Core Web Vitals são três medições que o Google usa para descrever como uma página é sentida por um visitante real: com que rapidez aparece o conteúdo principal, com que rapidez a página reage quando alguém toca ou clica e se o esquema da página salta durante o carregamento. Fazem parte dos sinais de experiência de página do Google, mas a razão mais importante para se preocupar é mais simples. Os visitantes abandonam páginas lentas e instáveis, e raramente lhe dizem porquê.

Este guia explica as três métricas em linguagem simples, os limites que o Google publica e como decidir o que corrigir primeiro num site normal de uma pequena empresa.

As três métricas em resumo

Métrica	O que mede	Bom	Fraco
LCP (Largest Contentful Paint)	Tempo até o maior elemento visível ser apresentado	2,5 segundos ou menos	Mais de 4 segundos
INP (Interaction to Next Paint)	Quanto tempo a página demora a responder visualmente após um toque, clique ou tecla	200 milissegundos ou menos	Mais de 500 milissegundos
CLS (Cumulative Layout Shift)	Quanto conteúdo visível se move inesperadamente	0,1 ou menos	Mais de 0,25

Os valores entre "bom" e "fraco" ficam numa faixa de "precisa de melhorias". O Google avalia uma página no percentil 75 das visitas reais, o que significa que três quartos dos seus visitantes devem ter uma experiência igual ou melhor do que o limite. Um teste rápido no seu portátil não prova que a página passa.

Largest Contentful Paint: a página aparece?

O LCP analisa a maior imagem, cartaz de vídeo ou bloco de texto no primeiro ecrã e regista quando termina de ser apresentado. Na maioria dos sites é uma imagem de destaque ou um título grande. Um LCP lento vem geralmente de uma de quatro causas: uma resposta lenta do servidor, uma imagem pesada ou mal formatada, CSS ou JavaScript que bloqueiam a apresentação, ou o navegador descobrir a imagem principal demasiado tarde.

Interaction to Next Paint: a página responde?

O INP substituiu a antiga métrica First Input Delay em março de 2024. Enquanto o First Input Delay olhava apenas para a primeira interação e só para o atraso antes de começar, o INP considera as interações ao longo de toda a visita e reporta uma das mais lentas, desde a ação até ser desenhada a imagem seguinte. As páginas que carregam depressa mas ficam "presas" ao abrir um menu ou carregar num botão têm geralmente um problema de JavaScript: demasiado código a correr em simultâneo na thread principal.

Cumulative Layout Shift: a página fica quieta?

O CLS soma o movimento inesperado de elementos visíveis. Já o sentiu quando foi tocar numa ligação e um banner carregou por cima, empurrando a ligação para baixo. As causas comuns são imagens sem atributos de largura e altura, anúncios e conteúdos incorporados que carregam tarde, tipos de letra que mudam e alteram o tamanho do texto e banners de cookies injetados no topo da página.

Dados de laboratório versus dados de campo

Há dois tipos de medição, e confundi-los causa equívocos.

• Os dados de campo vêm de visitantes reais com dispositivos e redes reais. O Google recolhe-os de utilizadores do Chrome e mostra-os no PageSpeed Insights e no Search Console quando o seu site tem tráfego suficiente. É o que conta para a avaliação.
• Os dados de laboratório vêm de um teste simulado, como o Lighthouse. São reproduzíveis, o que os torna ideais para depuração, mas correspondem a um dispositivo numa ligação.

Um site pequeno pode não ter dados de campo. Nesse caso, use testes de laboratório para encontrar problemas e trate os resultados como orientação, não como veredicto.

Por onde começar a corrigir

1. Meça as páginas que contam. Teste a página inicial, a página de destino mais visitada e um artigo ou página de produto típicos num perfil móvel. Não faça a média do site inteiro.
2. Corrija primeiro a métrica mais lenta. Se o LCP é fraco e o CLS está bem, trabalhe no LCP.
3. Comece pelos ganhos baratos. Comprima e redimensione a imagem de destaque, defina as dimensões das imagens, ative a cache, pondere uma CDN e remova plugins ou scripts que já não usa.
4. Volte a testar depois de cada alteração. Altere uma coisa de cada vez para saber o que ajudou.
5. Espere que os dados de campo acompanhem. Os números do mundo real são recolhidos num período contínuo, pelo que as melhorias demoram algumas semanas a aparecer por inteiro.

O que o alojamento tem a ver com isto

Os Core Web Vitals dizem sobretudo respeito à forma como uma página é construída, mas o alojamento define o patamar mínimo. Uma resposta lenta do servidor atrasa tudo o que se segue, o que prejudica diretamente o LCP. Servidores sobrelotados, versões de PHP desatualizadas e falta de cache no servidor acrescentam tempo antes de o navegador receber o primeiro byte. Um bom trabalho no front-end não consegue compensar totalmente um back-end lento.

Uma expectativa realista

Passar nas três métricas é um objetivo que vale a pena, mas não é um interruptor mágico de posicionamento. A relevância do conteúdo continua a contar muito mais. Pense nos Core Web Vitals como a remoção de atrito: não vão fazer uma página fraca subir nos resultados, mas uma página lenta e instável dificulta a retenção dos visitantes que já conquistou.

Erros comuns dos donos de sites

• Perseguir uma pontuação perfeita no Lighthouse. Uma pontuação de 100 num teste de laboratório não é o objetivo. O objetivo é passar os três limites para os visitantes reais.
• Testar apenas em computador. A maior parte da avaliação é feita em dispositivos móveis, que têm processadores e ligações mais lentos.
• Instalar um plugin de velocidade e ficar por aí. Os plugins podem ajudar na cache e no tratamento de imagens, mas não conseguem eliminar uma imagem de destaque de 3 MB nem uma dúzia de scripts de marketing.
• Ignorar os modelos. As páginas construídas a partir do mesmo modelo costumam partilhar os mesmos problemas, por isso corrigir o modelo corrige muitas páginas de uma vez. O Search Console agrupa URLs semelhantes precisamente por esta razão.

Mantenha um registo simples do que alterou e da pontuação antes e depois. Poupa palpites quando algo regride após a atualização de um plugin.

Páginas rápidas começam no servidor

Na Zebra Hosting Cloud, todos os planos incluem o painel de controlo Plesk, onde pode escolher versões atuais de PHP, e a CDN Cloudflare está disponível nos sites alojados para servir ficheiros estáticos mais perto dos visitantes. Em conjunto, cobrem o lado do servidor da equação para que se possa concentrar na página em si. Veja o que cada plano oferece na panorâmica de alojamento.