O Lighthouse abre uma página em condições controladas, executa uma bateria de diagnósticos e devolve um relatório que cabe bem num pull request. É útil, reproduzível e rápido. Também é a experiência de um usuário hipotético, em uma execução específica. A pessoa real pode estar em outro aparelho, outra rede, outra rota e com o cache em um estado completamente diferente.
Quando o relatório de laboratório está verde e reclamações continuam chegando, não existe contradição. Laboratório e campo respondem perguntas diferentes. Real User Monitoring, ou RUM, coleta métricas durante sessões reais para mostrar como o produto se comportou na variedade que a simulação não cobre.
Laboratório explica; campo representa
Ferramentas de laboratório são ótimas para diagnosticar causas. Você controla o throttling, repete o teste, desativa um script e compara o resultado. Isso ajuda a encontrar recursos que bloqueiam renderização, JavaScript excessivo, imagens grandes e trabalho pesado na main thread.
No campo, não existe essa limpeza. O usuário abre uma rota interna depois de vinte minutos de sessão, recebe uma campanha de terceiro, interage antes do carregamento terminar e usa um celular com economia de bateria. RUM registra essa bagunça, que é justamente a realidade do produto.
Core Web Vitals são um começo
LCP observa quando o maior conteúdo relevante aparece. INP acompanha a responsividade das interações. CLS mede deslocamentos inesperados de layout. A biblioteca oficial web-vitals fornece callbacks para capturar essas métricas de usuários reais de maneira alinhada às medições do Chrome.
import { onCLS, onINP, onLCP } from 'web-vitals';
const report = (metric) => {
navigator.sendBeacon(
'/rum',
JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
path: location.pathname,
}),
);
};
onCLS(report);
onINP(report);
onLCP(report);O exemplo é deliberadamente pequeno. Em produção, defina amostragem, retenção, consentimento e proteção de dados. Evite enviar URL completa quando ela carrega identificadores ou termos sensíveis. Métrica de performance não merece virar vazamento de informação.
A média esconde a pessoa que está sofrendo
Uma média boa pode misturar muitos desktops rápidos com uma cauda ruim de celulares intermediários. Por isso Core Web Vitals costuma ser analisado no percentil 75. Ainda assim, um número geral não mostra onde agir. Segmente por rota, classe de dispositivo, conexão, navegador e versão do release.
Também conecte métricas técnicas a fluxos. Tempo até o formulário estar utilizável, duração da busca, falha no envio e abandono de checkout podem dizer mais sobre o produto do que uma pontuação global. O LCP ajuda a localizar lentidão; não conhece sozinho a tarefa que o usuário queria terminar.
CrUX e RUM próprio não são a mesma coisa
O Chrome User Experience Report agrega dados de usuários elegíveis do Chrome e alimenta ferramentas como PageSpeed Insights. É excelente para acompanhar URLs e origins públicos com volume suficiente. Um RUM próprio oferece dados mais rápidos e detalhados sobre rotas autenticadas, versões e eventos do negócio, dentro das escolhas de privacidade da aplicação.
Os dois podem divergir por população, janela e método de agregação. Em vez de perguntar qual está “certo”, verifique se eles estão medindo o mesmo público e período.
Um fluxo que fecha o diagnóstico
- Use RUM para encontrar rotas, segmentos e releases com regressão.
- Reproduza o cenário no laboratório com rede e aparelho aproximados.
- Investigue com Performance panel, traces e dados de atribuição.
- Corrija e proteja o caso com budgets ou testes automatizados.
- Confirme no campo se a distribuição melhorou após o release.
Lighthouse continua no processo. Ele impede regressões óbvias e produz recomendações acionáveis antes do deploy. Só não deve carregar sozinho a responsabilidade de representar todos os usuários.
A pontuação verde é um bom sinal sobre aquela execução. RUM responde se o ganho atravessou redes ruins, sessões longas e páginas que o teste não abriu. Performance deixa de ser uma nota quando o ciclo conecta campo, diagnóstico e validação.
SPAs precisam separar a sessão por navegação
Em uma SPA, usar location.pathname no momento do callback pode associar uma métrica à rota errada. A versão 6 do web-vitals passou a medir soft navigations separadamente nos navegadores compatíveis e fornece navigationURL e navigationType.
const report = (metric) => {
const url = new URL(metric.navigationURL);
navigator.sendBeacon('/rum', JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
route: normalizeRoute(url.pathname),
navigationType: metric.navigationType,
release: APP_VERSION,
}));
};Normalize IDs no caminho e mantenha versão do coletor. Separar soft navigations muda a unidade medida: CLS e INP deixam de representar a sessão inteira. Não compare a série nova com a antiga como se apenas o pacote tivesse sido atualizado.
Atribuição transforma percentil em hipótese
Os builds de attribution da biblioteca acrescentam informações como elemento de LCP, alvo da interação e parcelas do INP. Use esses campos para agrupar causas, não para enviar texto, seletor completo ou URL com dado pessoal. Uma boa investigação liga rota, release e categoria de causa com cardinalidade controlada.
- LCP alto por descoberta tardia pede prioridade de recurso, não menos JavaScript por reflexo;
- INP dominado por input delay indica main thread ocupada antes do handler;
- presentation delay alto aponta para renderização e pintura depois do código;
- CLS precisa do elemento e do instante da mudança para separar anúncio, imagem e hidratação.
Defina um orçamento de amostragem e retenção. RUM detalhado em 100% das sessões pode custar mais e coletar mais dados do que o diagnóstico exige. A profundidade deve aumentar quando existe regressão, e voltar ao nível básico depois que a causa foi confirmada.