Core Web Vitals: Meça e Melhore o Desempenho Web

Você construiu um site rápido, mas os usuários ainda reclamam de lentidão. Ou talvez seu ranking de SEO tenha caído após uma atualização do Google. O culpado pode ser as Core Web Vitals—um conjunto de métricas que o Google usa para medir a experiência real do usuário. Ignorá-las pode prejudicar tanto a satisfação do usuário quanto a visibilidade na busca.

Neste guia, você aprenderá o que são as Core Web Vitals, como medi-las com precisão e passos práticos para melhorar cada métrica. Vamos focar nas três métricas atuais: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS).

O que são Core Web Vitals?

Core Web Vitals são um subconjunto das Web Vitals que o Google considera essenciais para proporcionar uma ótima experiência ao usuário. Elas quantificam a rapidez com que o conteúdo carrega, quão responsiva a página é às interações e quão visualmente estável ela é.

O Google usa essas métricas como sinal de ranking, mas, mais importante, elas refletem pontos de dor reais dos usuários. Um LCP lento frustra os usuários que esperam pelo conteúdo; um INP alto faz a página parecer lenta; um CLS alto causa cliques errados e aborrecimento.

As Três Core Web Vitals

• Largest Contentful Paint (LCP): Mede o desempenho de carregamento. Marca o momento em que o maior elemento de conteúdo (imagem, vídeo ou bloco de texto) se torna visível. Um bom LCP é de 2,5 segundos ou menos.
• Interaction to Next Paint (INP): Mede a responsividade. Registra a latência de todas as interações (cliques, toques, pressionamentos de tecla) e reporta um único valor. Um bom INP é de 200 milissegundos ou menos.
• Cumulative Layout Shift (CLS): Mede a estabilidade visual. Quantifica mudanças inesperadas de layout durante o carregamento. Um bom CLS é de 0,1 ou menos.

Esses limites são baseados em dados de campo de usuários reais, não em testes de laboratório. O Google os avalia no 75º percentil de carregamentos de página, o que significa que 75% das experiências do usuário devem atender ao limite "bom".

Como Medir as Core Web Vitals

Você precisa de dados de laboratório e de campo. Ferramentas de laboratório simulam um único carregamento de página sob condições controladas, enquanto dados de campo (Real User Monitoring, RUM) capturam experiências reais de usuários em diferentes dispositivos e redes.

Ferramentas de Laboratório

• Lighthouse: Integrado ao Chrome DevTools, audita o desempenho e fornece pontuações para LCP, CLS e total blocking time (TBT), que se correlaciona com o INP. Execute-o no modo anônimo para evitar que extensões distorçam os resultados.
• PageSpeed Insights: Combina dados de laboratório (Lighthouse) e de campo (CrUX). Use-o para ver tanto suas pontuações de laboratório quanto métricas de usuários reais.
• WebPageTest: Oferece testes avançados de múltiplos locais e dispositivos. Fornece filmstrips e gráficos de cascata para diagnosticar problemas de carregamento.

Ferramentas de Campo

• Chrome User Experience Report (CrUX): Um conjunto de dados público de métricas de usuários reais do Chrome. Disponível via PageSpeed Insights, CrUX Dashboard ou BigQuery.
• Google Search Console: Mostra o status das Core Web Vitals do seu site com base nos dados do CrUX. Agrupa URLs por desempenho.
• Biblioteca JavaScript web-vitals: Uma pequena biblioteca para medir métricas no seu próprio RUM. Você pode enviar dados para sua plataforma de analytics.

Veja como usar a biblioteca web-vitals para registrar métricas no console:

import {onLCP, onINP, onCLS} from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  // Use navigator.sendBeacon() ou fetch() para enviar dados
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
  fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Para uma verificação rápida sem programar, você pode usar ferramentas online que analisam dados de desempenho. Por exemplo, se você tem logs de servidor, o Nginx Log Analyzer pode ajudá-lo a identificar respostas lentas que podem afetar o LCP.

Melhorando o Largest Contentful Paint (LCP)

O LCP geralmente é a métrica mais impactante de otimizar. Ele é afetado pelo tempo de resposta do servidor, tempo de carregamento de recursos e renderização no lado do cliente.

Otimize a Resposta do Servidor

• Use um CDN para servir conteúdo de locais mais próximos dos usuários.
• Habilite cache (navegador e servidor) para ativos estáticos.
• Otimize consultas de banco de dados e código do servidor para reduzir o TTFB (Time to First Byte).
• Atualize para HTTP/2 ou HTTP/3 para multiplexação e conexões mais rápidas.

Otimize Recursos

• Pré-carregue recursos críticos: Use <link rel="preload"> para a imagem ou fonte do LCP.
• Comprima e dimensione imagens corretamente: Use formatos modernos como WebP ou AVIF, e sirva imagens responsivas com srcset.
• Minimize CSS e JavaScript: Remova caracteres e comentários desnecessários.
• Atrase JavaScript não crítico: Use atributos async ou defer.
• Incorpore CSS crítico: Coloque estilos acima da dobra diretamente no HTML para evitar requisições que bloqueiam a renderização.

Elimine Recursos que Bloqueiam a Renderização

CSS e JavaScript no <head> bloqueiam a renderização. Incorpore o CSS crítico e carregue o restante de forma assíncrona. Para JavaScript, use defer ou async.

Melhorando o Interaction to Next Paint (INP)

O INP mede o tempo desde uma interação do usuário até a próxima pintura. É influenciado pela execução de JavaScript, manipulação de eventos e trabalho de renderização.

Reduza o Tempo de Execução de JavaScript

• Divida tarefas longas (acima de 50ms) usando setTimeout ou requestIdleCallback.
• Use web workers para cálculos pesados.
• Aplique debounce ou throttle em manipuladores de eventos de scroll, resize e input.
• Evite scripts síncronos grandes; faça code-splitting e lazy-loading de módulos.

Otimize a Manipulação de Eventos

• Use listeners de eventos passivos para eventos de toque e roda para melhorar o desempenho de rolagem.
• Minimize a manipulação do DOM; agrupe atualizações e use requestAnimationFrame.
• Reduza o escopo de recálculos de estilo evitando seletores complexos.

Melhore o Desempenho de Renderização

• Use CSS will-change ou transform para animações acionarem aceleração de GPU.
• Evite layout thrashing lendo e escrevendo estilos em fases separadas.

Melhorando o Cumulative Layout Shift (CLS)

O CLS mede mudanças inesperadas de layout. É causado por elementos mudando de posição durante o carregamento, muitas vezes devido a imagens sem dimensões, anúncios ou conteúdo injetado dinamicamente.

Sempre Inclua Atributos de Tamanho

Para imagens e vídeos, defina atributos width e height ou use CSS aspect-ratio. Isso reserva espaço e previne mudanças.

<img src="#" width="800" height="600" alt="Hero">

Reserve Espaço para Conteúdo Dinâmico

• Use CSS min-height para contêineres que carregam conteúdo de forma assíncrona (ex.: anúncios, embeds).
• Evite inserir conteúdo acima do conteúdo existente, a menos que seja acionado por interação do usuário.

Use Font-Display Swap

Fontes personalizadas podem causar texto invisível (FOIT) ou mudanças de layout quando carregam. Use font-display: swap para mostrar o texto de fallback imediatamente, e pré-carregue fontes para reduzir o tempo de troca.

Juntando Tudo: Um Fluxo de Trabalho Prático

1. Meça: Comece com o PageSpeed Insights para obter dados de laboratório e de campo. Identifique qual métrica precisa de melhoria.
2. Diagnostique: Use o Lighthouse e o painel Performance do Chrome DevTools para encontrar gargalos. Observe o waterfall, a atividade da thread principal e as mudanças de layout.
3. Otimize: Aplique as técnicas acima, priorizando mudanças que afetam a pior métrica.
4. Teste: Reexecute testes de laboratório para confirmar melhorias. Implante em um ambiente de staging e use RUM para monitorar dados de campo.
5. Monitore: Configure RUM contínuo com a biblioteca web-vitals e alerte sobre regressões. Use o Search Console para acompanhar o status das Core Web Vitals.

Lembre-se de que otimizações podem ter trade-offs. Por exemplo, lazy-loading de imagens pode melhorar o carregamento inicial, mas pode prejudicar o LCP se a imagem do LCP for carregada com lazy-loading. Sempre teste com usuários reais.

FAQ

Quais são os limites atuais das Core Web Vitals?

Para LCP, bom é ≤2,5s, precisa melhorar é ≤4,0s, e ruim é >4,0s. Para INP, bom é ≤200ms, precisa melhorar é ≤500ms, e ruim é >500ms. Para CLS, bom é ≤0,1, precisa melhorar é ≤0,25, e ruim é >0,25. Esses limites são avaliados no 75º percentil de carregamentos de página.

Com que frequência devo verificar as Core Web Vitals?

Monitore dados de campo continuamente com RUM. Verifique o Search Console mensalmente para tendências gerais. Execute testes de laboratório após grandes mudanças de código ou implantações. As Core Web Vitals podem mudar com atualizações do seu site ou scripts de terceiros.

Posso melhorar as Core Web Vitals sem um desenvolvedor?

Algumas melhorias são possíveis via plugins ou configurações (ex.: habilitar cache, otimizar imagens). No entanto, ganhos significativos geralmente exigem mudanças de código como incorporar CSS crítico, atrasar JavaScript ou reestruturar como os recursos carregam. A ajuda de um desenvolvedor geralmente é necessária para INP e otimizações avançadas de LCP.

Pronto para analisar o desempenho do seu servidor? Experimente nosso Nginx Log Analyzer para identificar requisições lentas que podem estar impactando suas Core Web Vitals.