Um guia prático de Core Web Vitals explicado

Este guia explica Core Web Vitals explicado na prática, com foco em decisões de analytics que respeitam a privacidade.

Core Web Vitals são o pequeno conjunto de métricas de desempenho centradas no usuário do Google: Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift. Eles são importantes porque descrevem o que os visitantes sentem: se a página carrega rapidamente, responde quando tocada ou clicada e evita pular.

A documentação atual do Web Vitals do Google identifica LCP, INP e CLS como o Core Web Vitals estável e explica o ciclo de vida da métrica (web.dev Web Vitals). INP substituiu oficialmente o First Input Delay como Core Web Vital em 12 de março de 2024, conforme o Google anunciou em sua [atualização do Search Central] (https://developers.google.com/search/blog/2023/05/introducing-inp).

Trate Core Web Vitals como um sinal de diagnóstico e de experiência de uma página, não como uma chave mágica SEO. Sinais vitais melhores podem ajudar os usuários e remover uma desvantagem de classificação, mas não substituem a relevância, a qualidade do conteúdo, a autoridade ou a adequação do produto.

Os Três Core Web Vitals

Largest Contentful Paint (LCP)

LCP mede quando o maior elemento de conteúdo visível termina a renderização. Geralmente é uma imagem principal, um título grande, uma imagem do produto ou um bloco de conteúdo principal.

Meta: bom LCP é 2,5 segundos ou mais rápido para a maioria dos carregamentos de página.

Problemas comuns do LCP:

• Resposta lenta do servidor
• Grandes imagens de heróis não otimizadas
• Bloqueio de renderização CSS
• Atrasos na renderização do lado do cliente
• Fontes da web bloqueando texto
• Carregamento lento da imagem principal por engano

Como melhorar:

• Sirva HTML rapidamente a partir da borda ou de uma origem rápida.
• Compactar e redimensionar imagens de heróis.
• Use formatos modernos como AVIF ou WebP quando apropriado.
• Pré-carregue a imagem LCP real.
• Inline ou priorize CSS crítico.
• Evite fazer com que o conteúdo principal espere por análises, ferramentas de consentimento ou gerenciadores de tags.

Interaction to Next Paint (INP)

INP mede a capacidade de resposta em todas as interações, não apenas na primeira entrada. Ele captura quanto tempo a página leva para responder visivelmente após cliques, toques e interações do teclado.

Meta: bom INP está abaixo de 200 milissegundos.

INP costuma ser prejudicado pelo JavaScript. Tarefas longas, hidratação, scripts analíticos, widgets de bate-papo, ferramentas de personalização e tags pesadas de terceiros podem competir pelo tópico principal.

Como melhorar:

• Reduza o JavaScript enviado para a página.
• Divida pacotes grandes.
• Adie scripts de terceiros não críticos.
• Evite trabalhos caros em manipuladores de cliques.
• Use web workers para computação pesada.
• Divida tarefas longas em partes menores.
• Teste dispositivos móveis de baixo custo, não apenas laptops de desenvolvedores.

O Analytics pode afetar INP quando anexa ouvintes de eventos excessivos, executa trabalho síncrono ou carrega por meio de um gerenciador de tags volumoso. Um pequeno script que prioriza a privacidade não é apenas melhor para a confiança; muitas vezes é melhor para a capacidade de resposta.

Cumulative Layout Shift (CLS)

CLS mede movimentos visuais inesperados. Uma página parece quebrada quando o texto, botões ou imagens mudam depois que o usuário começa a ler ou tocar.

Alvo: bom CLS é 0,1 ou inferior.

Problemas comuns do CLS:

• Imagens sem dimensões
• Anúncios ou incorporações injetadas sem espaço reservado
• Banners de cookies empurrando conteúdo após carregamento
• Troca de fontes da web tardiamente
• Conteúdo dinâmico inserido acima do conteúdo existente

Como melhorar:

• Defina largura e altura ou proporção da mídia.
• Reserve espaço para banners, incorporações e anúncios.
• Evite inserir conteúdo acima da dobra após o carregamento.
• Use estratégias de carregamento de fontes que minimizem as mudanças.
• Teste com banners de consentimento reais e tags de marketing reais habilitadas.

Dados de campo versus dados de laboratório

Ferramentas de laboratório como Lighthouse são úteis para depuração porque executam testes controlados. Os dados de campo são o que os usuários reais experimentaram. Você precisa de ambos.

Use dados de laboratório para reproduzir e corrigir problemas. Use dados de campo para priorizar. Uma página com boa pontuação no laboratório ainda pode ter um desempenho ruim para visitantes reais em dispositivos lentos, redes móveis congestionadas ou navegadores afetados por scripts de terceiros.

O Chrome User Experience Report (CrUX) do Google é uma fonte de dados de campo público para origens qualificadas. Seu próprio monitoramento de usuário real pode ser mais específico porque pode segmentar por modelo, dispositivo, campanha, estado de login e versão de lançamento.

Ao medir melhorias, mantenha o método consistente. Compare os mesmos modelos, classes de dispositivos, países e janelas de lançamento. Use o 75º percentil porque os limites Core Web Vitals são avaliados em carregamentos de página, e não em um laptop de desenvolvedor.

Por que as escolhas do Analytics são importantes

Os orçamentos de desempenho geralmente se concentram em imagens e pacotes de aplicativos, ignorando os scripts de medição. Isso é um erro.

Os gerenciadores de tags podem carregar vários fornecedores, cada um com solicitações de rede, execução de JavaScript, cookies e ouvintes de eventos. As plataformas de gerenciamento de consentimento também podem afetar o desempenho quando bloqueiam a renderização, injetam UI atrasado ou acionam a reavaliação da tag após a escolha do usuário.

Auditoria:

• Peso total do script de terceiros
• Número de solicitações de rede antes de LCP
• Tempo de bloqueio do thread principal de análises e tags de anúncios
• Se a análise é carregada antes do conteúdo crítico
• Se o consentimento UI causa mudança de layout
• Se as tags não utilizadas ainda são acionadas

Remova tags que não suportam uma decisão atual. Substitua análises pesadas por medições agregadas mais enxutas sempre que possível.

Um pedido prático de otimização

1. Meça LCP, INP e CLS de usuário real em modelos de chave.
2. Identifique o pior modelo, não o pior URL individual.
3. Corrija primeiro a resposta do servidor e a entrega da imagem LCP.
4. Remova ou adie JavaScript não crítico.
5. Reserve espaço de layout para mídia, incorporações, anúncios e banners.
6. Teste novamente no celular.
7. Observe os dados de campo durante pelo menos um ciclo de tráfego completo.

Não busque uma pontuação Lighthouse perfeita às custas de usuários reais. Uma página de checkout com JavaScript um pouco mais pesado pode ser aceitável se for responsiva e estável. Uma página de marketing sem lógica de aplicativo deve ser extremamente enxuta.

Core Web Vitals QA

Antes de declarar vitória, verifique:

• Os dados de laboratório e de campo foram movidos na direção esperada.
• Os piores modelos para celular melhoraram, não apenas a página inicial.
• Banners de consentimento, GTM, anúncios, chat e análises foram ativados durante testes realistas.
• As alterações LCP, INP e CLS estão conectadas à conversão, inscrição, envolvimento de conteúdo, desvio de suporte ou qualidade da receita.
• Os resultados de back-end são reconciliados com a análise do navegador ao medir o impacto nos negócios.

Mantenha as métricas de diagnóstico separadas das métricas de decisão. Uma pontuação INP melhor explica por que um formulário parece mais rápido; a métrica do negócio é se mais pessoas o concluem.

O resultado final

Core Web Vitals recompensa o mesmo comportamento que os visitantes já recompensam: conteúdo rápido, controles responsivos e layouts estáveis. O caminho mais rápido geralmente não é exótico. Envie menos JavaScript, priorize o conteúdo principal, reserve espaço e pare de carregar tags que não valem a pena.