O que o monitoramento de usuários reais prova que o laboratório não consegue

O que é monitoramento de usuários reais (RUM)?

Equipes de performance web usam o monitoramento de usuários reais (real user monitoring, RUM) para coletar dados de desempenho e de erro de forma passiva a partir de visitas reais em navegadores reais, de modo que cada medição carrega atrás de si um dispositivo, uma rede e um local reais. O próprio navegador reporta os números por APIs padrão como PerformanceObserver, e o script os envia de volta depois que a página já fez o trabalho dela. Nada da medição é simulado: se um visitante em um celular Android de cinco anos esperou seis segundos no Wi-Fi de um hotel, esses seis segundos entram no conjunto de dados exatamente como foram vividos.

A palavra "passivo" carrega quase todo o sentido. O monitoramento de usuários reais não dirige o navegador, não escolhe a URL e não decide quando medir. O tráfego decide os três. Isso faz do RUM um censo do que aconteceu, e não um teste do que poderia acontecer.

Qual é a diferença entre dados de campo e dados de laboratório?

Dados de campo vêm de visitas que pessoas reais fizeram, e dados de laboratório vêm de um navegador com script que você configurou e agendou. O monitoramento de usuários reais é dado de campo. O monitoramento sintético é dado de laboratório: um navegador headless carrega uma URL escolhida com perfil de dispositivo fixo, throttling de CPU fixo e forma de rede fixa, a cada poucos minutos, tendo alguém no site ou não.

Os dois respondem perguntas diferentes, e o erro mais comum nas equipes é fazer a um deles a pergunta do outro.

Pergunta	Monitoramento de usuários reais	Monitoramento sintético
Quem é medido	Todo visitante que carrega a página	Um único agente com script
Dispositivo e rede	O que o visitante tiver	Fixados por configuração
Quando roda	Só quando chega tráfego	Em um cronograma que você define
Formato do resultado	Uma distribuição entre visitas	Um número único repetível
Classe de dado	Campo	Laboratório

Se você quer o comparativo completo, a comparação entre RUM e monitoramento sintético vai mais fundo que esta tabela.

O que o monitoramento de usuários reais prova que o sintético não prova?

O monitoramento de usuários reais prova o que os seus visitantes viveram, segmentado pelas condições com que chegaram. Como cada amostra carrega um dispositivo, um país, um tipo de conexão, uma página e uma versão, o RUM responde perguntas que um agente de laboratório não tem como responder: se o Safari no iOS é mais lento que o Chrome no seu checkout, ou se o deploy de terça piorou a página de preços para usuários no Brasil.

O monitoramento sintético prova a classe oposta de coisas. Um agente com script pega um deploy quebrado às 3 da manhã quando não há ninguém no site, mantém cada variável fixa para que dois builds sejam comparados com honestidade, e roda contra uma URL de staging antes que um único usuário a veja. O monitoramento de usuários reais não faz nada disso, porque não tem dado nenhum até alguém visitar.

Use os dois e encaminhe cada um de um jeito. Falhas sintéticas acionam o engenheiro de plantão. Regressões de RUM abrem um chamado com o segmento afetado anexado.

Quais são os limites de Core Web Vitals contra os quais o RUM é avaliado?

O Google avalia os três Core Web Vitals em três níveis, e os cortes publicados no web.dev pela equipe do Chrome seguem inalterados em setembro de 2026. Uma página passa somente quando as três métricas estão boas no percentil 75, medidas separadamente para celular e desktop.

Métrica	O que mede	Bom	Precisa melhorar	Ruim
LCP	Tempo até o maior elemento de conteúdo renderizar	2,5s ou menos	2,5s a 4,0s	Acima de 4,0s
INP	Atraso entre uma interação e a próxima pintura	200ms ou menos	200ms a 500ms	Acima de 500ms
CLS	Movimento inesperado de layout durante a vida da página	0,1 ou menos	0,1 a 0,25	Acima de 0,25

Cada métrica tem as suas próprias causas de falha, e por isso Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift são depurados separadamente, e não como uma nota só. A visão geral dos Core Web Vitals cobre como os três se encaixam.

Por que o monitoramento de usuários reais é lido no p75 e não como média?

Uma média deixa a maioria rápida esconder a minoria lenta, e o percentil 75 não deixa. A equipe do Chrome escolheu o p75 para os Core Web Vitals para atender duas condições ao mesmo tempo: o número precisa descrever a experiência da maioria das visitas, e precisa resistir à distorção de um punhado de outliers. No p75, três de cada quatro visitas bateram a meta, e distorcer o resultado em um conjunto de 100 amostras exige 25 amostras ruins em vez de 5.

O índice do percentil para uma lista ordenada de forma crescente é:

index = ceil(0.75 × N)

Veja um exemplo. Uma página coleta 1.000 amostras de LCP. 700 delas caem em 0,9s em conexões de desktop rápidas, e 300 caem em 6,0s em celular lento.

A média é (700 × 0.9 + 300 × 6.0) / 1000 = 2.43s, que se lê como boa diante do limite de 2,5s.

O índice p75 é ceil(0.75 × 1000) = 750. Ordenada de forma crescente, a amostra 750 fica dentro do grupo de 6,0s, então o p75 do LCP é 6,0s. Isso é ruim, e é o número que o Google usa.

Mesmo conjunto de dados, dois veredictos. A média aprovou a página enquanto 300 pessoas reais esperavam seis segundos. É por isso que um relatório de monitoramento de usuários reais que mostra só médias é pior que relatório nenhum, e por isso todo gráfico de performance que vale a pena manter traz p75, p90 e p99 ao lado da contagem.

As mesmas 1.000 amostras, dois veredictos

Média: 2,43 s

• Mistura 700 carregamentos rápidos em desktop com 300 lentos em mobile
• É lida como boa em relação ao limite de 2,5 s

p75: 6,0 s

• A amostra 750 fica dentro do grupo lento em mobile
• É lida como ruim, e é esse o número que o Google usa

O que um script de monitoramento de usuários reais coleta?

Um script de RUM coleta eventos de tempo e de erro emitidos pelo navegador, mais contexto suficiente para segmentá-los: os Core Web Vitals, os tempos de navegação e de recursos, os erros de JavaScript com stack trace, a rota, e atributos grosseiros de dispositivo, navegador e conexão. Nada disso precisa de cookie nem de identificador persistente.

O peso é a restrição que decide se vale a pena rodar o script, porque qualquer coisa que atrase a página que ele mede corrompe a medição. A Flowsery entrega um script de menos de 10 KB, sem cookies e hospedado na UE, e não aplica amostragem de dados, então o p75 é calculado a partir de cada sessão e não de um subconjunto. Junto com os tempos ela registra a própria sessão e sinaliza rage clicks, dead clicks, erros de JavaScript e abandonos, o que transforma um p75 lento em um session replay que você pode assistir em vez de um número que você tem que adivinhar.

O que o monitoramento de usuários reais deixa passar?

O monitoramento de usuários reais deixa passar todo mundo que nunca chegou e todo mundo que saiu antes de o beacon disparar. Quem abandona a página aos quatro segundos não gera amostra de LCP nenhuma, o que enviesa o conjunto de dados para os pacientes. Páginas sem tráfego não geram dados, então uma rota nova ou uma tela de administração pouco usada fica invisível até alguém usar.

Outras duas lacunas pesam na prática. Bloqueadores de conteúdo descartam parte das requisições de analytics, então a população coletada é um subconjunto da real. E o suporte às métricas varia por motor de navegador, então um público com muito Safari rende menos amostras para algumas vitals do que um público com muito Chrome.

Cubra as lacunas de propósito: rode checagens sintéticas nas rotas que ainda não têm tráfego, mantenha o endpoint de coleta em first-party, e leia o RUM ao lado do web analytics para ver se as sessões que sumiram do gráfico de performance também sumiram do funil.

Perguntas frequentes

Monitoramento de usuários reais é a mesma coisa que web analytics?

Não. Web analytics conta visitas, origens, funis e conversões para responder perguntas de negócio. O monitoramento de usuários reais mede com que velocidade e com que confiabilidade essas visitas renderizaram e responderam. Os dois compartilham um script e um identificador de sessão na maioria das ferramentas, e por isso um p75 de LCP lento e uma queda na conclusão do funil podem ser lidos na mesma linha do tempo.

Quanto tráfego o monitoramento de usuários reais precisa para ser útil?

Amostras suficientes para o percentil 75 ficar estável no segmento que você está lendo. Uma página com 40 visitas por semana produz um p75 que balança a cada dispositivo incomum, então agregue no nível do template ou amplie a janela antes de tirar conclusões. Cortes por segmento multiplicam a exigência: ler o p75 por país e por dispositivo ao mesmo tempo exige muito mais tráfego do que ler no nível do site.

O monitoramento de usuários reais deixa o site que ele mede mais lento?

Um script de RUM adiciona bytes e tempo de execução, então o tamanho do script decide a resposta. Carregá-lo de forma assíncrona, mantê-lo pequeno e enviar os beacons depois que a página renderizou impede que a medição altere o que está sendo medido. Um script de monitoramento pesado que bloqueia a renderização piora todas as métricas que ele reporta.

Por que os meus dados de RUM discordam do Lighthouse?

O Lighthouse é dado de laboratório de um dispositivo simulado em uma conexão limitada, e o RUM é dado de campo de uma distribuição de dispositivos reais. Um LCP de 1,8s no Lighthouse e um p75 de LCP de campo de 5,2s estão os dois certos: a rodada de laboratório descreve uma máquina que você configurou, o número de campo descreve o seu público. Corrija regressões no laboratório, julgue o sucesso no campo.

O monitoramento de usuários reais funciona sem cookies?

Sim. Beacons de desempenho carregam tempos, uma rota e atributos grosseiros de dispositivo, e nenhum deles exige identificador persistente. A Flowsery roda sem cookies e hospedada na UE por esse motivo, o que mantém o conjunto de dados de campo intacto em regiões onde banners de consentimento suprimiriam a coleta.

Devo alertar no p75 ou em sessões lentas individuais?

Alerte no p75 do site e das rotas de alto valor, porque esse é o número ligado ao veredito de Core Web Vitals. Sessões lentas individuais entram na triagem, não no alerta: um carregamento de 12 segundos em um celular dentro de um túnel não é regressão. Agrupe primeiro as sessões lentas por causa em comum e depois alerte quando o grupo crescer.

O monitoramento de usuários reais consegue mostrar se uma regressão afeta só um país?

O monitoramento de usuários reais registra um país, uma página e uma versão em cada amostra, o que permite filtrar exatamente por essa combinação. Verificar se um deploy de terça-feira deixou a página de preços mais lenta para usuários no Brasil é o tipo de pergunta que só dados de campo com esse contexto respondem, já que um agente sintético roda a partir de um local fixo.

O monitoramento de usuários reais conta um visitante que sai da página antes dela terminar de carregar?

Não, uma visita que é abandonada antes do beacon disparar não gera amostra nenhuma, nem rápida nem lenta. Isso enviesa o conjunto de dados coletado a favor dos visitantes com paciência para ficar, então a experiência real dos impacientes nunca chega ao relatório.

Por que sites com muito tráfego de Safari mostram menos amostras de RUM?

Os motores de navegador diferem nas APIs de Core Web Vitals que expõem, então o suporte a cada métrica não é igual entre eles. Uma audiência com muito Safari gera menos amostras para algumas métricas do que uma com muito Chrome no mesmo volume de tráfego, o que é uma lacuna de cobertura e não um sinal de desempenho melhor.

Qual é o tamanho do script de monitoramento de usuários reais da Flowsery?

A Flowsery entrega um único script com menos de 10 KB, sem cookies e hospedado na UE. Ele não aplica amostragem de dados, então o p75 reportado é calculado a partir de cada sessão, não de um subconjunto, e o tamanho reduzido evita que a medição deixe mais lenta a própria página medida.