Como medir Core Web Vitals reais em um site criado por IA

Uma execução do Lighthouse conta uma história controlada. Os visitantes chegam com celulares, redes, caches, extensões e caminhos diferentes. Se você mede apenas no laboratório, pode corrigir uma página que já estava boa e ignorar a interação que trava no aparelho usado pelo público.

Dados de campo registram o que aconteceu em visitas reais. Essa prática costuma ser chamada de Real User Monitoring, ou RUM. Para Core Web Vitals, ela permite acompanhar LCP, INP e CLS por rota, versão e classe de dispositivo.

Coletar não é despejar cada evento do navegador em um banco. Defina perguntas, limite o payload e trate privacidade antes de publicar o script.

Separe campo de laboratório

As duas fontes respondem perguntas diferentes.

O fluxo oficial de Core Web Vitals com ferramentas Google recomenda campo para medir a experiência real e laboratório para diagnosticar. Não escolha um lado. Use campo para encontrar o problema e laboratório para reproduzir a causa.

O guia de Core Web Vitals em sites criados por IA cobre os conceitos e limites. Aqui o foco é montar uma coleta própria que ajude a decidir o que corrigir.

Comece pelo CrUX quando houver dados

O Chrome User Experience Report reúne dados agregados de usuários elegíveis do Chrome. PageSpeed Insights mostra esses dados quando a página ou a origem tem amostra suficiente.

Verifique:

• se o relatório é da URL ou da origem inteira;
• se o recorte é celular ou desktop;
• o percentil 75 de LCP, INP e CLS;
• as frações classificadas como boas, precisam melhorar ou ruins;
• o período informado pela ferramenta.

A CrUX API também expõe histogramas e percentis para consultas automatizadas. Um site novo ou com pouco tráfego pode não aparecer. Ausência de dados não significa aprovação nem falha.

CrUX localiza a tendência. Ele não costuma dizer qual botão causou o INP ou qual elemento deslocou a página. Para isso, você precisa de atribuição na própria visita.

Use a biblioteca web-vitals

A biblioteca oficial web-vitals implementa as métricas de forma compatível com a medição do Chrome. A versão padrão entrega os valores. A build web-vitals/attribution acrescenta sinais para diagnóstico.

Instale no projeto que gera os arquivos publicados:

bun add web-vitals

Depois, registre apenas os campos necessários:

import { onCLS, onINP, onLCP } from "web-vitals/attribution";

function reportMetric(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    id: metric.id,
    route: location.pathname,
    version: document.documentElement.dataset.version,
  });

  navigator.sendBeacon("/metrics", body);
}

onCLS(reportMetric);
onINP(reportMetric);
onLCP(reportMetric);

O endpoint é ilustrativo. Um site estático precisa enviar os dados a um serviço de analytics ou a uma API externa autorizada. O Site no Ar publica os arquivos do frontend; ele não cria esse coletor nem armazena eventos automaticamente.

Nem todo callback dispara em toda visita. INP não existe se a pessoa não interagir. Algumas métricas só ficam prontas quando a aba muda de estado ou começa a descarregar. Teste navegação, troca de aba e encerramento de sessão.

Inclua dados que levam a uma correção

Um valor sem contexto confirma o problema, mas não aponta o código. A build de attribution pode acrescentar:

• elemento e URL associados ao LCP;
• alvo e tipo da interação do INP;
• atraso de entrada, processamento e apresentação;
• elemento do maior layout shift;
• estado de carregamento em que o evento aconteceu;
• dados de Long Animation Frames em navegadores compatíveis.

O guia do web.dev para depurar performance no campo mostra como esses sinais reduzem a distância entre métrica e causa.

Escolha poucos campos no começo:

function safeAttribution(metric) {
  if (metric.name === "INP") {
    return {
      target: sanitizeTarget(metric.attribution.interactionTarget),
      type: metric.attribution.interactionType,
      inputDelay: Math.round(metric.attribution.inputDelay),
      processing: Math.round(metric.attribution.processingDuration),
      presentation: Math.round(metric.attribution.presentationDelay),
    };
  }

  return {};
}

Não ative todos os eventos processados por padrão. Páginas muito interativas podem aumentar memória e volume de dados. Comece com a interação responsável pelo INP e amplie só quando a pergunta exigir.

Preserve a privacidade

Métricas técnicas ainda podem carregar dados pessoais se você copiar a URL ou o DOM sem cuidado.

Não envie:

• query strings completas;
• texto digitado ou conteúdo de campos;
• nomes, emails, telefones ou IDs de conta;
• seletores com valores criados a partir de dados do visitante;
• conteúdo de mensagens de erro sem revisão;
• IP ou fingerprint criado para unir sessões.

Prefira identificadores definidos no código:

<button data-performance-name="lead-form-submit">Enviar</button>

O gerador de alvo pode devolver apenas esse nome controlado. Se não houver um identificador seguro, use uma classe de componente genérica ou descarte o alvo.

Defina retenção, acesso, finalidade e base legal com quem responde pela privacidade do projeto. Respeite a escolha de consentimento adotada pelo site. Medir performance não autoriza coletar qualquer detalhe da navegação.

Use amostragem e limites

Enviar todas as métricas de todas as visitas pode gerar custo sem melhorar a decisão. Escolha uma amostra estável, por exemplo a partir de um valor aleatório por pageview, e registre a taxa usada.

const sampleRate = 0.1;
const sampled = Math.random() < sampleRate;

if (sampled) {
  onCLS(reportMetric);
  onINP(reportMetric);
  onLCP(reportMetric);
}

0.1 é apenas um exemplo de implementação. O volume necessário depende do tráfego, da variação entre rotas e da precisão esperada.

No coletor:

• limite o tamanho do corpo;
• aceite somente nomes e tipos conhecidos;
• rejeite valores fora de faixas plausíveis;
• aplique rate limit;
• não confie na versão enviada pelo navegador como autorização;
• monitore falhas do próprio endpoint.

Agrupe por rota e versão

Uma média do site inteiro mistura páginas e builds diferentes. Registre dimensões que levem a uma decisão:

• rota normalizada, sem parâmetros pessoais;
• versão ou hash da build;
• celular ou desktop;
• faixa de conexão quando houver justificativa;
• métrica e classificação;
• alvo seguro ou componente;
• fase dominante do INP;
• período da coleta.

Use percentis, não apenas média. Core Web Vitals avalia o percentil 75 porque a cauda da distribuição importa. Um conjunto de visitas muito rápidas pode esconder um grupo relevante com experiência ruim.

Não compare uma rota com dez visitas a outra com dez mil como se a confiança fosse igual. Mostre o tamanho da amostra e evite concluir cedo demais.

Transforme o dado em uma fila de investigação

Um painel útil responde qual trabalho deve começar.

Exemplo de leitura:

Rota: /precos/
Version: 8f3c2a1
Período: 7 dias
Amostra INP: 2.840 visitas com interação
P75: 286 ms
Alvo mais frequente entre casos ruins: pricing-plan-toggle
Fase dominante: presentation delay
Próximo teste: trace do toggle com todos os cards montados

Esse registro aponta uma reprodução. “INP ruim no site” não aponta.

Para LCP, agrupe pelo elemento e fases de descoberta, carregamento e renderização. O artigo sobre LCP da imagem hero mostra as correções possíveis. Para CLS, registre o maior elemento afetado e use o guia de layout shifts.

Não use dados de campo como trace remoto

Attribution reduz o espaço de busca, mas não substitui uma gravação reproduzível. Um seletor e uma duração não mostram toda a pilha, os estilos recalculados ou a pintura.

Quando encontrar um grupo ruim:

1. identifique rota, versão, dispositivo e alvo;
2. reproduza o fluxo no DevTools;
3. grave Performance com condições declaradas;
4. corrija uma causa;
5. compare localmente;
6. publique a nova versão;
7. acompanhe a distribuição depois do deploy.

O guia de redução de INP mostra como ler as fases de uma interação. Para regressões que quebram o orçamento, use também o artigo de orçamento de performance.

Marque a versão publicada

Sem uma versão, os dados anteriores e posteriores se misturam. Injete na build um identificador que não revele segredo e envie o mesmo valor com cada métrica.

No fluxo do Site no Ar:

1. consulte o Site e a Version atuais;
2. altere os arquivos dentro de public/;
3. gere a build com o identificador novo;
4. publique com deploy;
5. acompanhe deploy_status;
6. confirme a URL e o identificador servido;
7. filtre os dados pela nova versão.

A documentação de Publicação descreve Sessions, Versions e a URL entregue. O guia de republicação ajuda a manter o mesmo Site durante o teste.

Espere a janela certa

RUM próprio começa a receber eventos assim que o código entra no ar, mas precisa de amostra. CrUX e ferramentas que usam seus dados trabalham com janelas agregadas e não confirmam uma mudança minutos depois do deploy.

Defina antes:

• tamanho mínimo da amostra;
• período de comparação;
• percentil observado;
• segmentação de dispositivo;
• critério de melhora ou regressão;
• ação se o coletor falhar.

Não atribua qualquer variação à nova versão. Campanhas, tráfego, sazonalidade e mudanças externas alteram o conjunto de visitantes.

Prompt para montar a medição de campo

Planeje a coleta de Core Web Vitals deste site sem publicar ainda.

Rotas prioritárias: [rotas]
Analytics ou endpoint autorizado: [destino]
Version atual: [identificador]
Regras de consentimento e retenção: [regras]

1. Meça LCP, INP e CLS com web-vitals/attribution.
2. Normalize a rota e inclua uma versão da build.
3. Envie somente alvos controlados pelo código.
4. Remova query strings, conteúdo digitado e identificadores pessoais.
5. Defina amostragem, validação e rate limit.
6. Mostre P75, amostra e distribuição por rota e dispositivo.
7. Relacione cada grupo ruim a um teste reproduzível no DevTools.
8. Só proponha a publicação depois da revisão de privacidade.

Medição de campo vale quando muda a próxima decisão. Colete o bastante para encontrar a rota, o alvo e a versão que precisam de trabalho. Depois volte ao código, reproduza o caso e use a publicação seguinte para testar se a distribuição realmente mudou.