Medindo Core Web Vitals no GA4 e BigQuery com a Biblioteca Web-Vitals.js

1. O Fim dos Testes Sintéticos: A Necessidade do RUM

A maioria das equipes de tecnologia e marketing ainda comete o erro clássico de avaliar a velocidade do site rodando auditorias isoladas no PageSpeed Insights ou Lighthouse em computadores de escritório com conexões de fibra ótica de 500 Mbps.

Esses testes sintéticos de laboratório são úteis para depuração imediata, mas não refletem a dura realidade dos consumidores: clientes comprando através de smartphones intermediários, navegando em redes 4G instáveis no transporte público ou com dezenas de abas abertas competindo pela memória RAM do dispositivo.

O Google utiliza os dados de usuários reais coletados no Chrome User Experience Report (CrUX) para compor seus fatores de ranqueamento de SEO e custos de leilão no Google Ads. Implementar o Real User Monitoring (RUM) via web-vitals.js e GA4 permite que sua equipe veja exatamente os mesmos números antes de sofrer penalizações na busca orgânica.

2. As Três Métricas Canônicas: LCP, INP e CLS

As três métricas fundamentais que definem a experiência técnica da página são:

• Largest Contentful Paint (LCP): Mede a velocidade de carregamento percebida pelo usuário. Registra o tempo decorrido até que o maior elemento visual visível na tela (geralmente a imagem hero do produto ou título H1 principal) seja totalmente renderizado. Meta: <= 2,5 segundos.
• Interaction to Next Paint (INP): Mede a responsividade da interface. Avalia a latência de resposta a cliques, toques e teclas ao longo de toda a sessão do usuário. Meta: <= 200 milissegundos.
• Cumulative Layout Shift (CLS): Mede a estabilidade visual da página. Quantifica a pontuação acumulada de saltos inesperados de layout causados por imagens sem dimensões declaradas ou anúncios dinâmicos que empurram o conteúdo enquanto a página carrega. Meta: <= 0,1.

3. A Biblioteca Oficial web-vitals.js do Google

Desenvolvida pela equipe do Chrome do Google, a biblioteca de código aberto web-vitals.js padroniza o uso das APIs modernas de PerformanceObserver do navegador.

Ela abstrai todas as peculiaridades e diferenças de suporte entre versões do Chrome, Edge, Opera e navegadores baseados em Chromium, retornando objetos simples contendo o valor numérico exato da métrica, o delta de atualização, a classificação de qualidade e o seletor CSS do elemento que disparou a medição.

4. Infográfico Vetorial: Pipeline da Captura no Navegador ao BigQuery

5. Implementação Técnica no Google Tag Manager

Crie uma Tag do tipo HTML Personalizado no GTM acionada em Consent Initialization ou All Pages que carrega o script oficial a partir de uma CDN confiável ou de seu próprio servidor:

<script type="module">
  import { onCLS, onINP, onLCP } from 'https://unpkg.com/web-vitals@4?module';

  function sendToGTM(metric) {
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
      event: 'core_web_vitals',
      cwv_name: metric.name,
      cwv_value: Math.round(metric.name === 'CLS' ? metric.value * 1000 : metric.value),
      cwv_rating: metric.rating,
      cwv_id: metric.id,
      cwv_element: metric.entries.length ? metric.entries[0].element ? metric.entries[0].element.tagName : 'unknown' : 'none'
    });
  }

  onCLS(sendToGTM);
  onINP(sendToGTM);
  onLCP(sendToGTM);
</script>

6. Consultas SQL no BigQuery: Distribuição do Percentil 75 (p75)

Para calcular o Percentil 75 oficial utilizado pelo Google em suas auditorias:

-- Cálculo do Percentil 75 (p75) de LCP no BigQuery
SELECT
  APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS lcp_p75_ms,
  COUNT(1) AS total_amostras
FROM (
  SELECT
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'cwv_value') AS metric_value
  FROM `projeto.analytics_123456789.events_*`
  WHERE
    event_name = 'core_web_vitals'
    AND (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'cwv_name') = 'LCP'
    AND _TABLE_SUFFIX BETWEEN '20261001' AND '20261014'
);

7. A Matemática da Conversão: Correlacionando Latência e Receita

O maior trunfo de enviar os Core Web Vitals para o BigQuery é poder cruzar o tempo de carregamento da sessão diretamente com a ocorrência do evento de purchase:

Em análises empíricas, sessões onde o LCP fica abaixo de 1,8s apresentam taxa de conversão média de 3,4%. Quando o LCP salta para mais de 4,0s, a taxa de conversão despenca para 1,1%. Esse número fornece à equipe de engenharia o argumento financeiro irrefutável para priorizar sprints de performance e otimização de imagens.

8. Checklist de Governança de Core Web Vitals

Perguntas Frequentes sobre medir core web vitals ga4 bigquery

Por que o meu site tem nota 95 no Lighthouse mas o Google Search Console aponta Core Web Vitals ruins?

O Lighthouse roda em condições simuladas de laboratório em uma única máquina. O Google avalia seu ranqueamento com base no CrUX (Chrome User Experience Report), que mede a experiência real de milhares de usuários reais em celulares de entrada e redes móveis lentas. O RUM via web-vitals.js mede exatamente o mesmo dataset do CrUX.

O que substituiu o FID (First Input Delay) nos Core Web Vitals?

O Google substituiu oficialmente o FID pelo INP (Interaction to Next Paint). Enquanto o FID media apenas o atraso do primeiro clique, o INP avalia a latência de TODAS as interações do usuário durante a visita, selecionando a pior resposta como nota da sessão.

Carregar a biblioteca web-vitals.js não vai deixar meu site mais lento?

Não. A biblioteca web-vitals.js compactada tem menos de 2 KB e utiliza as APIs nativas do navegador (PerformanceObserver) de forma totalmente assíncrona, consumindo quase zero tempo de CPU.

Como o Google define se uma página é 'Boa', 'Precisa Melhorar' ou 'Ruim'?

A avaliação é baseada no Percentil 75 (p75): pelo menos 75% das visitas devem atingir a faixa 'Boa' (LCP <= 2.5s, INP <= 200ms e CLS <= 0.1) para que a página seja aprovada nos algoritmos de ranqueamento do Google.