Guias

Os Core Web Vitals são um conjunto de métricas definidas pela Google para captar como uma página se sente realmente ao usar, por oposição a quão rápida é em abstrato. Concentram-se em três experiências do mundo real: com que rapidez o conteúdo principal aparece, quão estável é o layout enquanto carrega, e com que prontidão a página responde ao seu input. Como são medidas em visitas reais, recompensam páginas que dão boa sensação em vez de páginas que apenas pontuam bem em laboratório.

LCP, CLS e INP explicados

A primeira métrica, Largest Contentful Paint, mede quanto tempo demora o maior elemento visível — normalmente uma imagem hero, um título ou um bloco de texto — a renderizar. É um indicador de «quando é que a página parece carregada?». Um LCP lento significa que os visitantes ficam a olhar para um ecrã em branco ou meio construído, e é uma das razões mais comuns pela qual uma página parece lenta mesmo quando está tecnicamente funcional.

A segunda, Cumulative Layout Shift, mede o movimento inesperado de conteúdo à medida que a página carrega. Já sentiu uma má pontuação CLS sempre que um botão salta mesmo quando vai tocar-lhe, porque uma imagem ou um anúncio carregou por cima dele e empurrou tudo para baixo. Quantifica essa instabilidade incómoda, e melhorá-la passa em grande parte por reservar espaço para o conteúdo antes de ele chegar.

A terceira, Interaction to Next Paint, mede a capacidade de resposta — com que rapidez a página reage visivelmente depois de clicar, tocar ou escrever. Um INP fraco significa que a interface parece lenta e pouco reativa, muitas vezes porque a main thread do navegador está ocupada a executar JavaScript quando tenta interagir. Para aplicações ricas em scripts, esta é frequentemente a mais difícil das três de acertar.

Corrigir cada métrica

Melhorar o LCP resume-se normalmente a entregar mais cedo o conteúdo importante. Otimize e dimensione corretamente as imagens, sirva-as em formatos modernos e use as sugestões de loading e prioridade que a plataforma fornece; garanta que o seu servidor ou CDN responde rapidamente; e evite bloquear a renderização inicial com scripts e folhas de estilo desnecessários. O objetivo é que os pixels mais importantes cheguem o mais cedo possível.

• LCP — com que rapidez o conteúdo principal aparece; otimize imagens e resposta do servidor
• CLS — estabilidade do layout; reserve espaço para imagens, embeds e tipos de letra
• INP — capacidade de resposta; reduza e divida o JavaScript na main thread
• SPA: code-splitting, lazy-loading, emagreça os bundles; acrescente SSR para um primeiro paint rápido
• Meça com dados de campo reais (CrUX), não apenas uma única execução de laboratório

Corrigir o CLS passa sobretudo por reservar espaço com antecedência. Defina sempre largura e altura explícitas (ou um rácio de aspeto) em imagens e elementos incorporados para que o navegador lhes deixe lugar antes de carregarem, evite inserir conteúdo por cima do que o utilizador já está a ler, e tenha cuidado com os web fonts para que o texto não se reorganize quando o tipo de letra personalizado entra. São alterações pequenas e mecânicas com um efeito desproporcionado em quão estável uma página parece.

Melhorar o INP significa fazer menos trabalho na main thread no momento da interação. Divida as tarefas JavaScript de longa execução, adie ou remova scripts que não são necessários de imediato, e seja disciplinado com o código de terceiros, que é uma causa frequente e invisível de falta de resposta. Quanto menos o navegador tiver de fazer quando um utilizador clica, mais rapidamente pode desenhar o resultado.

Cuidado especial com as single-page apps

As single-page applications precisam aqui de atenção particular, porque as suas forças e os seus riscos para os Core Web Vitals vêm da mesma fonte. O bundle de JavaScript que torna a navegação instantânea pode também atrasar o primeiro paint e bloquear as interações se crescer demasiado. O code-splitting, para que cada rota carregue apenas o que precisa, o lazy-loading de componentes pesados e o emagrecimento das dependências são as alavancas que mantêm uma SPA fluida e rápida a carregar.

A renderização no servidor e a geração estática ajudam as SPA exatamente nestas métricas. Ao enviar conteúdo real e renderizado na primeira resposta — via Nuxt, Next.js ou uma build estática — dá ao utilizador um LCP rápido em vez de um ecrã em branco à espera dos scripts. A aplicação depois hidrata-se na sua forma interativa, pelo que mantém a navegação suave enquanto corrige o problema do primeiro carregamento pesado que prejudica os Vitals.

Meça com dados de campo reais

Por fim, meça com dados reais, não apenas com um teste de laboratório pontual. Ferramentas como o PageSpeed Insights e o Lighthouse são úteis para diagnóstico, mas os dados de campo de utilizadores reais — através do Chrome User Experience Report ou da sua própria monitorização — dizem-lhe o que os visitantes realmente experienciam em diferentes dispositivos e redes. Melhorar os Core Web Vitals é um hábito contínuo de medir, corrigir o pior infrator e medir de novo, não uma caixa que se assinala uma única vez.