Análise de Core Web Vitals

Como funciona esta verificação

O Scanaris não inventa números de desempenho: pede ao PageSpeed Insights, o serviço da Google que executa o Lighthouse, que meça a tua página em modo móvel e lê o resultado. Daí tira a pontuação de 0 a 100 e três métricas: LCP (Largest Contentful Paint, quanto demora a pintar o maior elemento visível), CLS (Cumulative Layout Shift, quanto a página "salta" enquanto carrega) e TBT (Total Blocking Time, quanto tempo o JavaScript bloqueia a thread principal). A pontuação fica guardada num achado informativo que não desconta e que alimenta a nota do pilar de desempenho. Só abre achados com severidade quando uma métrica cai no intervalo que a Google chama "mau": LCP acima de 4 segundos (média), CLS acima de 0,25 (baixa) ou TBT acima de 600 milissegundos (baixa). Se o Lighthouse não devolver pontuação (página não mensurável, erro da ferramenta), não há achado.

Porque importa

O desempenho é experiência de utilizador e é SEO. A Google usa as Core Web Vitals como sinal de ranking desde 2021, e mede as dos teus utilizadores reais no Chrome, não só as de laboratório. Mas o efeito mais direto está no negócio: cada segundo extra de carregamento em móvel reduz as conversões de forma mensurável, e um LCP de 5 segundos significa que boa parte dos teus visitantes vê um ecrã em branco tempo suficiente para ir embora. As métricas medem-se em móvel porque é onde a maioria dos sites rende pior e onde a Google indexa primeiro.

Como corrigir

LCP alto

• A imagem principal costuma ser o elemento LCP. Serve-a em WebP ou AVIF, no tamanho em que é mostrada e não no original, com fetchpriority="high" e sem loading="lazy". No Nuxt e no Next.js, os componentes de imagem (NuxtImg, next/image) fazem isto por ti.
• O tempo de resposta do servidor soma-se a tudo o resto. Cache de página, CDN à frente e, no WordPress, um plugin de cache bem configurado.
• CSS e JavaScript que bloqueiam a pintura: carrega o CSS crítico inline e o resto depois; os scripts de terceiros com defer ou async.
• Fontes web: font-display: swap, pré-carregamento da fonte principal e, se puderes, aloja-as tu em vez de as carregar do Google Fonts.

CLS alto

Quase sempre são imagens sem width e height, anúncios ou embeds que aparecem de repente, e fontes que mudam de tamanho ao carregar. Declara as dimensões de cada imagem e iframe, reserva o espaço dos blocos dinâmicos com min-height e nunca insiras conteúdo acima do que o utilizador já está a ler.

TBT alto

Demasiado JavaScript a executar no arranque. Divide o bundle por rotas, carrega os componentes pesados só quando são precisos, atrasa os scripts de analítica e chat até depois da interação, e revê o peso das bibliotecas: bibliotecas desatualizadas e uma cópia completa do jQuery para um menu são os casos típicos.

Confirma que está corrigido

npx lighthouse https://teudominio.com --only-categories=performance --preset=perf --form-factor=mobile --screenEmulation.mobile --view

Ou cola o URL no PageSpeed Insights, que além da medição de laboratório mostra os dados de utilizadores reais dos últimos 28 dias. Objetivo: LCP abaixo de 2,5 s, CLS abaixo de 0,1 e TBT abaixo de 200 ms. Mede várias vezes: os resultados de laboratório variam um pouco entre execuções.

Perguntas frequentes

O meu site carrega rápido no meu computador. Porque sai mal?

Porque a medição simula um telemóvel de gama média com ligação 4G lenta, que é o que usa uma parte grande dos teus visitantes. O teu portátil com fibra não é o caso representativo.

Um 100 de desempenho ajuda o SEO mais do que um 90?

Não de forma apreciável. A Google distingue entre "bom", "precisa de melhorar" e "mau" por métrica; uma vez em "bom", o resto é experiência de utilizador, não ranking. Concentra-te em sair do vermelho, não em perseguir o 100.

Esta verificação mede todas as minhas páginas?

Só o URL analisado. Se a tua página de produto ou o teu blog têm problemas diferentes, analisa-os à parte. As outras verificações deste pilar, como acessibilidade, também trabalham sobre a página concreta.