O teste local abre rápido, o Lighthouse fica verde e o deploy parece resolvido. Aí entram os usuários reais, com celulares de quatro anos, redes instáveis, extensões, abas demais e condições que não aparecem no notebook de quem desenvolveu a página. A distância entre laboratório e uso real não é novidade, mas agora existe um conjunto de dados bem maior para observar onde essa experiência começa a degringolar.
A Cloudflare publicou o BEACON, sigla para Browser Experience Across Cloudflare’s Observed Network. O conjunto reúne bilhões de medições anônimas de usuários reais em 10 mil sites de grande porte, cobre os principais motores de navegador e recebe atualizações diárias no BigQuery. Mais importante do que o volume, porém, é o nível de detalhe: além dos Core Web Vitals, os dados separam o LCP e o INP nas etapas que formam cada métrica.
O download nem sempre é o maior culpado do LCP
O Largest Contentful Paint mede quando o maior elemento visível da página termina de aparecer. É fácil olhar para um LCP ruim, encontrar uma imagem grande no topo e concluir que basta comprimir o arquivo. Às vezes basta mesmo. Os dados agregados do BEACON mostram, porém, que essa explicação está longe de cobrir todos os casos.
O conjunto divide o LCP em quatro partes: o tempo até o primeiro byte do documento, o atraso até o navegador descobrir o recurso principal, a duração do download e o atraso entre o recurso estar disponível e finalmente ser renderizado. Nas experiências classificadas como ruins, a duração do download apareceu com participação menor do que o atraso de descoberta e, principalmente, o atraso de renderização.
- TTFB do documento: quanto tempo o HTML inicial leva para começar a chegar.
- Atraso de carregamento: quanto o navegador espera até descobrir que precisa buscar a imagem, fonte ou vídeo do LCP.
- Duração do carregamento: o tempo efetivamente gasto transferindo esse recurso.
- Atraso de renderização: o intervalo entre o recurso estar pronto e aparecer na tela.
Isso muda a investigação. Uma imagem pode estar bem comprimida e ainda aparecer tarde porque só foi descoberta depois da execução de JavaScript, porque recebeu prioridade inadequada ou porque o navegador ficou ocupado com outras tarefas antes de pintar o elemento. Otimizar bytes continua importante, mas não resolve uma cadeia de carregamento mal organizada.
No INP, JavaScript pesa, mas o navegador ainda precisa desenhar
O Interaction to Next Paint observa a latência das interações ao longo da visita. Ele não mede apenas quanto tempo o event handler levou para executar. O BEACON separa a métrica em atraso de entrada, tempo de processamento e atraso de apresentação.
Nas interações mais lentas, o processamento ocupa a maior parcela. É o território conhecido de handlers grandes, hidratação, bibliotecas de terceiros e tarefas longas segurando a main thread. O dado interessante é que o atraso de apresentação também cresce bastante. Depois que o código responde ao clique ou toque, o navegador ainda pode gastar tempo recalculando estilos, fazendo layout e pintando a atualização.
Na prática, quebrar uma função grande pode melhorar o processamento e ainda deixar a interface travada se a mudança provocar uma árvore enorme de atualizações. O painel Performance do navegador, os dados de campo e a divisão do INP em subpartes ajudam a distinguir esses problemas. Sem essa separação, tudo tende a receber o rótulo genérico de “JavaScript lento”.
Histogramas mostram a cauda que a média esconde
Outro detalhe útil é a publicação de histogramas completos, não apenas de uma média global ou do percentil 75. Isso permite observar a cauda da distribuição: usuários para os quais a experiência degrada muito além do resultado típico.
Duas páginas com o mesmo P75 podem esconder comportamentos bem diferentes. Uma pode manter a maior parte das visitas próxima do limite, enquanto outra funciona muito bem para quase todos e muito mal para um grupo específico. País, tipo de conexão, aparelho e motor do navegador ajudam a recortar esses cenários sem fingir que existe um único “usuário médio”.
Como transformar o conjunto em investigação prática
O BEACON não conhece a arquitetura da sua aplicação nem aponta automaticamente qual componente deve ser corrigido. O valor está em comparar padrões da web com o comportamento observado no seu próprio produto. Um fluxo razoável pode seguir quatro etapas:
- confirmar nos dados de campo qual métrica e qual grupo de usuários estão sofrendo;
- separar LCP ou INP em subpartes para localizar a etapa dominante;
- reproduzir uma condição parecida no DevTools, usando limitação de CPU e rede quando fizer sentido;
- medir novamente depois da mudança, sem assumir que uma melhora de laboratório aparecerá igual em produção.
Para LCP, isso pode levar à revisão do HTML inicial, da prioridade dos recursos, do uso de lazy loading no elemento principal ou do trabalho que bloqueia a renderização. Para INP, pode significar reduzir tarefas longas, limitar o alcance de atualizações de DOM, revisar layouts caros ou adiar trabalho que não precisa acontecer antes do próximo frame.
O que os dados não conseguem provar
O conjunto é amplo, mas continua sendo observacional. Quando duas medidas caminham juntas, isso não prova que uma causou a outra. Um país apresentar transferências menores, por exemplo, pode refletir sites adaptados à rede local, diferenças de conteúdo, público ou várias condições misturadas. A própria análise inicial da Cloudflare trata algumas dessas leituras como hipóteses para investigação futura.
Também há uma escolha deliberada de privacidade. Domínios e caminhos não são expostos, e grupos com poucos pontos são descartados antes da publicação. Isso protege usuários e sites, mas impede usar a base como uma tabela pública para comparar marcas específicas.
O ganho real do BEACON não é substituir o RUM da aplicação ou o profiler do navegador. É oferecer uma referência pública, grande e consultável para testar suposições. Se o time ainda trata performance como “comprimir imagens e rodar Lighthouse”, os dados mostram que existe bastante coisa acontecendo antes do download e depois do clique.