O verdadeiro impacto dos Core Web Vitals na faturação

Os Core Web Vitals são frequentemente apresentados como um tema puramente de SEO. Essa perspetiva é redutora: como sinal direto de posicionamento têm um peso moderado — o próprio Google confirmou que uma página com excelente conteúdo e resposta exata pode superar uma página rápida com conteúdo fraco.

A verdadeira razão para otimizar estas métricas é a taxa de conversão. Um visitante que abandona o website antes da renderização completa converte a zero por cento — e nenhuma posição orgânica compensa essa perda.

Eis o que as três métricas avaliam, o que causa maus resultados e como corrigi-las por ordem de prioridade.

As três métricas fundamentais

Largest Contentful Paint (LCP)

O momento em que o maior elemento visual visível termina de renderizar. Habitualmente a imagem principal (hero image), o título H1 ou um bloco de texto central.

• Bom: abaixo de 2,5 segundos
• A melhorar: 2,5 a 4,0 segundos
• Fraco: acima de 4,0 segundos

O LCP é o indicador mais fiel de quando a página se tornou útil para o utilizador. É a métrica com maior prioridade de resolução.

Cumulative Layout Shift (CLS)

A quantidade de deslocamento visual dos elementos durante o carregamento. Acontece quando o utilizador tenta tocar num link, uma imagem ou banner carrega tardiamente, a página desloca-se e o toque acerta noutro elemento.

• Bom: abaixo de 0,1
• Fraco: acima de 0,25

O CLS é habitualmente o mais rápido e económico de corrigir, dado que as suas causas técnicas são bem conhecidas.

Interaction to Next Paint (INP)

A rapidez com que a página responde visualmente às interações do utilizador (cliques, toques e digitação). O INP substituiu o antigo First Input Delay (FID) em março de 2024 e é muito mais rigoroso: avalia todas as interações ao longo de toda a sessão.

• Bom: abaixo de 200 ms
• Fraco: acima de 500 ms

Um INP deficiente é quase sempre provocado por excesso de JavaScript a bloquear a thread principal do navegador.

Dados de Laboratório versus Dados de Campo

Os relatórios do Lighthouse no navegador medem 'Dados de Laboratório' sob condições simuladas. No entanto, os algoritmos do Google e o relatório Chrome User Experience Report (CrUX) avaliam exclusivamente 'Dados de Campo' (Real User Monitoring): medições reais de utilizadores em redes e dispositivos autênticos durante 28 dias.

Se os seus clientes utilizam smartphones modestos em redes móveis 4G, é essa experiência que determina as suas métricas reais.

Plano de ação por prioridade

1. Otimizar o LCP

1. Otimize a imagem principal: Utilize formatos modernos como WebP ou AVIF, dimensões responsivas e adicione fetchpriority="high".
2. Elimine CSS e JavaScript bloqueadores: Carregue scripts não críticos de forma assíncrona com defer ou async.
3. Melhore o tempo de resposta do servidor (TTFB): Implemente uma rede CDN com cache na borda (Edge Caching).

2. Otimizar o CLS

1. Defina dimensões explícitas em imagens e vídeos: Inclua sempre atributos width e height ou utilize a propriedade CSS aspect-ratio.
2. Reserve espaço para conteúdo dinâmico: Banners promocionais e avisos de cookies devem ter contentores com altura fixa reservada.
3. Evite saltos de fontes: Utilize font-display: swap com fontes de fallback de dimensões equivalentes.

3. Otimizar o INP

1. Reduza bibliotecas JavaScript pesadas: Remova scripts de rastreio e widgets redundantes via Tag Manager.
2. Divida tarefas longas na thread principal: Utilize scheduler.yield() ou quebras assíncronas para manter a interface responsiva.
3. Minimize mutações complexas do DOM: Evite re-renderizações desnecessárias em elementos interativos.

Websites rápidos têm melhor visibilidade orgânica, mas acima de tudo convertem significativamente mais visitantes em clientes.