Saiba por que os dados de RUM podem mostrar números de Core Web Vitals diferentes do CrUX.
Publicado em: 15 de agosto de 2022, última atualização: 17 de dezembro de 2025
O Chrome User Experience Report (CrUX) exibe métricas sobre a experiência de usuários reais do Chrome com sites muito acessados. Esses dados são coletados automaticamente pelo Chrome de usuários que aceitaram participar e são disponibilizados com base nos critérios de qualificação do CrUX.
Portanto, os dados do CrUX estão disponíveis para milhões de sites. Muitos proprietários de sites não tinham acesso aos dados de campo antes, e o CrUX permitiu que muitos sites vissem o valor disso pela primeira vez. Como um conjunto de dados público, o CrUX também pode ser usado para análise competitiva e comparativo de mercado de métricas de experiência do usuário.
O Real User Monitoring (RUM) é semelhante ao CrUX, mas, em vez de o Chrome coletar automaticamente as métricas de experiência do usuário, o código é incluído nos sites para fazer essa coleta e enviá-la a um provedor de RUM ou solução de análise para uma análise mais detalhada.
Como as duas soluções medem métricas de experiência do usuário, é natural supor que elas sejam equivalentes. Pode ser confuso quando vemos diferenças. Este guia explica por que isso pode acontecer e oferece sugestões sobre o que fazer quando os números não estão alinhados.
Benefícios de complementar o CrUX com uma solução de RUM
O CrUX é uma ótima ferramenta para uma visualização consistente em vários sites e, como o conjunto de dados do Google para o programa Core Web Vitals, os sites provavelmente vão querer ficar de olho no que ele está mostrando. O objetivo do CrUX é fornecer uma visão geral estatisticamente relevante de milhões de sites para comparação cruzada.
No entanto, para uma investigação mais profunda sobre por que os dados estão mostrando esses números, investir em uma solução completa de RUM para complementar o CrUX pode dar acesso a informações mais detalhadas do que as disponíveis em um conjunto de dados que pode ser consultado publicamente. Isso pode ajudar você a explicar e melhorar suas métricas de várias maneiras.
Análise mais detalhada para investigar problemas
O CrUX geralmente pode ser usado para indicar se você tem um problema no site, mas não necessariamente onde ele está ou por quê. As soluções de RUM, sejam elas criadas internamente com recursos como a biblioteca web-vitals ou com alguns dos muitos produtos comerciais, podem ajudar a preencher essa lacuna.
O uso de uma solução de RUM dá acesso a dados muito mais detalhados para todas as suas páginas e em todos os navegadores. Ele também permite segmentar e analisar esses dados de maneiras que o CrUX não faz, permitindo que você se aprofunde e investigue as áreas problemáticas do site. Eles são afetados por um segmento específico de usuários? Ou usuários que realizam determinadas ações? Quando exatamente o problema começou? Essas são perguntas muito mais fáceis de responder com os dados adicionais que uma ferramenta de RUM pode fornecer.
Correlação com outras métricas de negócios
O RUM também permite comparar suas métricas de performance na Web diretamente com qualquer métrica de negócios, mostrando o valor de investir em performance e quais outros trabalhos de performance priorizar. Temos vários estudos de caso com empresas que fazem essa correlação, como a Farfetch ou o The Economic Times.
Coletar outros dados de performance
Uma solução de RUM permite coletar outras métricas personalizadas, vinculadas diretamente à sua empresa. Um dos exemplos mais conhecidos é a métrica "Tempo até o primeiro tweet" do Twitter. Essas medidas específicas do site podem ser correlacionadas com as melhorias nas Core Web Vitals e as métricas de negócios.
Diferenças entre dois conjuntos de dados de campo
Um homem com um relógio sabe que horas são. Um homem com dois relógios nunca tem certeza.
Lei de Segal
Quando você tem duas fontes de dados, pode ser confuso e frustrante entender por que elas são diferentes. Assim como é importante entender a diferença entre as métricas de laboratório e de campo, também pode haver diferenças entre duas fontes de dados de campo. Em um mundo ideal, os dados seriam os mesmos, mas há muitos motivos para que eles sejam diferentes.
Dados de laboratório x dados de campo
A primeira coisa a verificar é se você está analisando métricas de laboratório (sintéticas) ou de campo (RUM). Embora seja natural presumir que os produtos de RUM analisam apenas dados de campo, muitos também oferecem um componente de laboratório.
Os dados de laboratório são incrivelmente úteis justamente por causa das condições fixas em que são medidos. Ele pode ser usado para monitorar mudanças ou regressões inesperadas em um ambiente de produção sem o ruído de uma população de campo em mudança. No entanto, os dados de laboratório podem não ser representativos da experiência real do usuário. Por isso, as métricas de campo podem mostrar resultados bem diferentes.
Populações
Os conjuntos de dados usados pelas soluções do CrUX e do RUM podem ser diferentes devido às diferenças nas visitas às páginas que estão sendo medidas, dependendo dos navegadores, usuários, sites e dispositivos que estão sendo comparados.
Navegadores incluídos
O Chrome User Experience Report, como o nome sugere, é exclusivo do Chrome. Embora existam muitos navegadores baseados no Chromium (Edge, Opera e Brave, para citar alguns) que compartilham grande parte da base de código do Chrome, apenas os usuários do Chrome alimentam dados no CrUX. Essa restrição também significa que os usuários do Chrome no iOS não estão incluídos, já que ele usa o mecanismo de navegador Webkit. Os WebViews do Android também não são considerados "Chrome". Portanto, os dados desses usuários não são incluídos, mas as guias personalizadas do Chrome são.
Embora o Chrome seja um dos navegadores mais usados do mundo e, portanto, provavelmente forneça uma representação ampla do desempenho do seu site na maioria dos casos, medir apenas esse navegador não é uma medida de todos os seus usuários. Isso pode explicar uma das principais diferenças entre o RUM e o CrUX. Isso é especialmente verdadeiro para técnicas de desempenho que dependem de APIs ou formatos da imagem disponíveis apenas no Chrome, por exemplo.
A falta de dados do iOS também pode levar a vieses. Por exemplo, como os usuários do iOS geralmente usam dispositivos com melhor desempenho ou acessam de países com melhor infraestrutura de rede, incluí-los pode levar a métricas de performance geral mais altas. Por outro lado, excluí-los, como o CrUX faz, pode levar a dados distorcidos para o limite inferior de visitantes do site (exemplo de estudo de caso). Os usuários do Android geralmente abrangem uma variedade maior de dispositivos, recursos e mercados.
As soluções de RUM podem receber dados de navegadores que não são o Chrome e, em especial, de navegadores baseados no Chromium que geralmente têm as mesmas métricas (como as Core Web Vitals) integradas. Os navegadores que não são baseados no Chromium também são medidos por soluções de RUM, mas podem ter um conjunto de métricas mais limitado. Por exemplo, a Cumulative Layout Shift (CLS) só está disponível em navegadores baseados no Chromium. Algumas outras métricas baseadas em pintura, como LCP, INP e até mesmo First Contentful Paint (FCP), podem ser medidas de maneira bem diferente (veja mais adiante).
Usuários que aceitaram
Além de ser limitado aos usuários do Chrome, o CrUX é ainda mais restrito por medir apenas um subconjunto de usuários do Chrome que optaram por compartilhar dados do CrUX quando o navegador foi instalado.
Os provedores de RUM também analisam apenas um subconjunto de usuários, geralmente devido a solicitações de banner de cookie (pedindo que os usuários aceitem a coleta de dados de RUM) ou bloqueadores de rastreamento. Isso pode afetar negativamente alguns carregamentos iniciais de páginas se a confirmação não for dada até a segunda página ou as seguintes, quando alguns dos recursos do site já tiverem sido armazenados em cache de páginas anteriores. Se isso acontecer com frequência, as métricas podem parecer mais favoráveis no RUM do que realmente são se os carregamentos iniciais de página mais lentos forem excluídos em um número suficiente de casos.
Sites incluídos
O CrUX serve apenas para informar sobre sites públicos. Por isso, há outros critérios de qualificação que podem impedir o registro de dados no CrUX. O mais importante desses critérios é que o site precisa ser detectável publicamente e ter popularidade suficiente para garantir um tamanho mínimo de amostra que permita tirar conclusões significativas. Na maioria dos casos, isso resulta em nenhum dado disponível no CrUX. Essa é uma diferença menos confusa em comparação com os dados disponíveis, mas diferentes, mas explica por que isso acontece.
No entanto, se páginas específicas de um site estiverem marcadas como indexáveis, mas outras não, talvez você veja apenas um subconjunto de URLs no CrUX. Se a origem for detectável publicamente, todas as visualizações de página nela serão incluídas nos dados do nível de origem, mas os dados do nível de URL talvez não estejam disponíveis.
Dispositivos
O CrUX segmenta os dados por dispositivo móvel, computador e tablet, embora muitas ferramentas se concentrem nos dois primeiros e não mostrem dados de tablets ou os incluam nos dados de dispositivos móveis ou computadores. As características de desempenho em dispositivos móveis e computadores podem ser bem diferentes, tanto em termos do envio de conteúdo quanto dos recursos dos dispositivos que o mostram.
Os dados de RUM permitem segmentar o tráfego de forma semelhante, mas geralmente mostram dados consolidados por padrão. O RUM pode permitir apenas a segmentação por tipo de dispositivo (por exemplo, dispositivo móvel) ou navegador (por exemplo, Chrome), mas não ambos para ver apenas o tráfego do Chrome em dispositivos móveis. Ao comparar com os dados do CrUX, verifique se você está comparando dados semelhantes, filtrando por tipo de dispositivo e pelo navegador Chrome.
Amostragem
As soluções de RUM geralmente permitem ajustar a taxa de amostragem dos visitantes que aceitaram a coleta de dados. Isso pode ser usado para reduzir o volume de dados que precisam ser analisados e os custos dos serviços comerciais de RUM. Se o tamanho da amostra for muito pequeno e não representar a população em geral, as métricas resultantes também serão distorcidas. Discuta com seu provedor de RUM o tamanho de amostragem apropriado para seu site.
Agregação de dados
Por natureza, os dados de campo incluem muitos pontos de dados das mesmas métricas em comparação com os dados de laboratório, que fornecem um único valor. Se esses dados forem agregados de forma diferente para os relatórios, isso pode ser outro motivo para as diferenças entre o CrUX e o RUM.
Período
Os dados do CrUX são baseados em uma janela deslizante de 28 dias de tráfego, e não é possível mudar esse período. No entanto, os dados do CrUX no BigQuery são armazenados para cada mês, permitindo que você veja os meses anteriores, e a API CrUX History também fornece dados históricos de um período semanal. Ambos ainda fornecem dados com base na janela deslizante de 28 dias.
Os dados de RUM geralmente permitem uma granularidade muito maior para que o impacto das mudanças seja visto muito antes. No entanto, ao escolher períodos menores, os dados do RUM podem ser afetados indevidamente por flutuações no tráfego e nos visitantes do site. Ao comparar dados de RUM com dados do CrUX, sempre verifique se você está analisando o desempenho em 28 dias. Quando você tiver certeza de que os dados são semelhantes, poderá analisar outros períodos para detalhar os dados de RUM.
Agregação de estatísticas
As métricas do CrUX são medidas no 75º percentil, ou seja, analisando o valor que 75% das visualizações de página alcançaram. Há extremos nos dados de campo, e a remoção das piores 25% das experiências tem como objetivo fornecer um valor que a maioria dos visitantes possa alcançar.
Os produtos de RUM geralmente oferecem um número maior de opções para agregar as métricas, incluindo o 75º percentil, a mediana e outros percentis. Ao comparar os valores de RUM com os dados do CrUX, é necessário garantir que você esteja analisando os dados do 75º percentil para fazer uma comparação justa.
Os dados do histograma no CrUX incluem todos os dados disponíveis, não apenas o 75º percentil, e mostram o número de visualizações de página em cada classificação, mas a pontuação agregada será baseada no 75º percentil. Esses dados do CrUX são mostrados em ferramentas como o PageSpeed Insights:
Diferenças nas métricas
Há muitas métricas usadas para medir o desempenho na Web. Portanto, ao comparar dois conjuntos de dados diferentes, é importante entender quais métricas estão sendo medidas e como elas estão sendo usadas.
Métricas medidas
Os dados do CrUX são o conjunto de dados do Google da iniciativa Core Web Vitals e medem principalmente essas métricas (LCP, CLS e INP), com algumas métricas adicionais para complementá-las.
As ferramentas de RUM geralmente incluem esses Core Web Vitals, mas também costumam incluir muitas outras métricas. Alguns provedores de RUM também medem a experiência do usuário usando uma combinação própria de todas essas métricas, talvez para fornecer um "índice de satisfação" ou algo parecido. Ao comparar os dados do RUM com o CrUX, verifique se você está comparando dados semelhantes.
As ferramentas que avaliam o status de aprovação ou reprovação das Core Web Vitals devem considerar uma página aprovada se ela atingir as metas recomendadas no 75º percentil para todas as Core Web Vitals. Se a INP não estiver presente em páginas sem interações, apenas a LCP e a CLS precisam ser aprovadas.
Diferenças de métricas entre navegadores
O CrUX só faz medições em navegadores Chrome. Consulte os registros de alterações do Web Vitals para saber como eles mudam em cada versão do Chrome.
No entanto, as soluções de RUM medem uma variedade maior de navegadores. Os navegadores baseados no Chromium (Edge, Opera etc.) provavelmente serão semelhantes ao Chrome, a menos que o Chrome esteja implementando novas mudanças, conforme observado no registro de alterações.
Para navegadores que não são do Chromium, as diferenças podem ser mais pronunciadas. Métricas baseadas em pintura, como LCP, INP e FCP, por exemplo, estão disponíveis no Safari e no Firefox, mas são medidas de uma maneira diferente. Isso pode levar a variações significativas nos tempos informados. Como já dissemos, se você quiser comparar o RUM com o CrUX, é melhor filtrar apenas os usuários do Chrome para fazer uma comparação justa.
Tempo das métricas
As métricas das Core Web Vitals são fornecidas por APIs de navegadores da Web, mas isso não significa que não haja potencial para diferenças de valores informados usando essas APIs. O momento exato em que a medição da métrica é feita (no carregamento de página ou durante todo o ciclo de vida dela) pode levar a diferenças. As ferramentas de RUM nem sempre medem as métricas da mesma forma, mesmo que usem os mesmos nomes e as mesmas APIs do navegador para receber os dados, o que pode ser confuso.
A Largest Contentful Paint (LCP) é uma métrica de carregamento de página. Vários elementos da LCP podem ser informados pela API Web se elementos maiores forem carregados depois da renderização inicial. O elemento final da LCP é quando a página termina de carregar ou o usuário interage com ela. Portanto, podem surgir diferenças se o elemento LCP for informado antes desses dois eventos.
Além disso, nos dados de campo, o elemento LCP pode ser diferente dependendo de como a página é carregada. Para um carregamento de página padrão que mostra o topo do conteúdo da página, o elemento LCP vai depender principalmente do tamanho da tela. No entanto, se a página for aberta com um link fixo mais abaixo no documento ou com um link direto para um app de página única (SPA, na sigla em inglês), o elemento LCP pode ser diferente.
Não presuma que os tempos de LCP fornecidos no CrUX ou no RUM são baseados no mesmo elemento que as ferramentas de laboratório. Enquanto o CrUX fornece o valor geral da LCP por página ou origem, o RUM pode segmentar ainda mais para identificar sessões individuais com problemas de LCP.
A Cumulative Layout Shift (CLS) é medida durante toda a vida útil da página. Portanto, a CLS inicial do carregamento de página pode não ser representativa de páginas que causam mudanças maiores depois que a página é carregada e o usuário interage com ela. Portanto, considerar o valor da CLS apenas após o carregamento de página, como muitos produtos de RUM fazem, vai gerar um resultado diferente de considerar o valor da CLS depois que o usuário terminar de usar a página.
A métrica de capacidade de resposta Interaction to Next Paint (INP) exige que uma entrada seja medida e observa todas as interações de clique, toque e teclado durante a vida útil da página, de maneira semelhante à CLS. Portanto, o valor informado da INP pode ser muito diferente se medido depois que o usuário fizer várias interações na página.
O CrUX vai seguir a documentação das Core Web Vitals e medir esses dados durante todo o ciclo de vida da página. Muitos provedores de RUM optam por medir essas métricas após o carregamento de página ou em outro momento (por exemplo, quando uma call-to-action importante é clicada) por vários motivos.
Para entender as variações inexplicáveis entre as duas fontes de dados, é importante saber quando as Core Web Vitals são medidas pelo seu provedor de RUM.
Aplicativos de página única
Os aplicativos de página única (SPA, na sigla em inglês) funcionam atualizando o conteúdo da página atual, em vez de realizar navegações nas páginas reais no navegador. Isso significa que o navegador não as vê como navegações nas páginas, embora os usuários as experimentem como tal. As APIs Core Web Vitals fornecidas pelo navegador não levam isso em consideração. Portanto, o CrUX não oferece suporte a essas navegações nas páginas. Estamos trabalhando para resolver esse problema. Consulte a postagem Como medir navegações suaves para mais informações.
Alguns provedores de RUM tentam detectar "navegações suaves" em SPAs, mas, se eles também atribuírem métricas das Core Web Vitals a essas "navegações suaves", isso vai levar a diferenças com o CrUX, já que as APIs subjacentes não oferecem suporte a isso para muitas das métricas.
Diferenças entre o CrUX e a API Web
Além das diferenças em quais visualizações de página são medidas e o que é medido, há alguns outros cenários mais complicados que podem levar a diferenças nos dados do CrUX e do RUM. Algumas delas se devem a limitações das APIs da Web usadas para medir as métricas, e outras são casos em que os resultados retornados pela API precisam ser tratados de forma diferente em determinados cenários. A documentação das Core Web Vitals lista essas diferenças para LCP e CLS, mas as principais diferenças também são observadas nas seções a seguir.
Cache de avanço e retorno
O CrUX considera as restaurações do cache de avanço e retorno (ou bfcache) como navegações nas páginas, mesmo que elas não resultem em um carregamento de página convencional. Como as APIs da Web não tratam isso como um carregamento de página, as soluções de RUM precisam seguir etapas extras para que essas páginas sejam contabilizadas se quiserem corresponder ao CrUX. Esses carregamentos de página são consideravelmente mais rápidos e podem resultar em uma performance geral melhor para um site. Portanto, não incluí-los pode resultar em métricas de performance geral da página piores. Consulte sua solução de RUM para entender se ela lida com páginas restauradas do bfcache.
Iframes
Por motivos de segurança e privacidade, as páginas de nível superior não têm acesso ao conteúdo em iframes (nem mesmo em iframes de mesma origem). Isso significa que as métricas de performance do conteúdo neles só podem ser medidas pelo próprio iframe, e não pelas APIs da Web na página de framing. Se o conteúdo do iframe incluir o elemento LCP ou conteúdo que afete a CLS ou a INP do usuário, ele não estará disponível para soluções de RUM (incluindo a biblioteca JavaScript web-vitals do Google).
No entanto, o CrUX, sendo medido pelo próprio navegador Chrome em vez do JavaScript na página, não tem essas limitações e, portanto, mede métricas em iframes ao informar as Core Web Vitals. Isso reflete com mais precisão o que o usuário vê, mas pode ser outro motivo para diferenças em sites que usam iframes.
Um exemplo concreto de como isso pode levar a diferenças entre os dados de LCP no CrUX e no RUM são os <video> incorporados. O primeiro frame pintado de um elemento <video> de reprodução automática inline pode ser considerado um candidato à LCP, mas as incorporações de serviços de streaming de vídeo conhecidos podem colocar esses elementos em um <iframe>. O CrUX pode considerar isso, já que pode acessar o conteúdo de <iframe>, mas as soluções de RUM não.
Recursos entre origens
A mídia LCP veiculada de outros domínios pode não fornecer o tempo de renderização na API PerformanceObserver, a menos que o cabeçalho Timing-Allow-Origin (TAO) seja fornecido, devido a restrições de segurança do navegador para reduzir ataques de tempo. Isso volta para o tempo de carregamento do recurso, mas pode ser bem diferente de quando o conteúdo foi realmente renderizado.
Isso pode levar à situação aparentemente impossível em que a LCP é informada pelas APIs da Web como anterior à FCP. Isso não é verdade, mas parece ser devido a essa restrição de segurança.
Isso foi resolvido no final de 2024, e um tempo de renderização um pouco mais aproximado está disponível no Chrome 133, mesmo quando Timing-Allow-Origin não é fornecido.
O CrUX informa os dados de tempo de renderização para as Core Web Vitals. Recomendamos que os sites limitem o conteúdo entre origens que afeta as métricas das Core Web Vitals e ativem o TAO sempre que possível para medir isso com mais precisão. Outros recursos entre origens podem estar sujeitos a restrições semelhantes.
Guias em segundo plano
Quando uma página não é aberta em uma guia em segundo plano, ela ainda emite métricas usando APIs da Web. No entanto, eles não são informados pelo CrUX porque fornecem tempos inconsistentes com a experiência do usuário. As soluções de RUM também devem considerar ignorar essas visualizações ou, pelo menos, explicar como elas são tratadas.
Então, o que podemos fazer?
Mostramos por que pode haver diferenças entre os dados do CrUX e do RUM, seja devido a diferenças na metodologia que cada um usa ou devido a quais usuários e visualizações de página são incluídos ou excluídos. O ideal é que os dois conjuntos de dados ainda sejam representativos da performance do site para serem úteis, mas os motivos apresentados devem explicar por que é muito improvável que os números sejam exatamente iguais em cada um.
Quando as diferenças são pequenas (por exemplo, relatar uma LCP de 2 segundos em vez de 2,2 segundos), os dois conjuntos de dados são úteis e geralmente podem ser considerados sincronizados.
Quando diferenças acentuadas fizerem você questionar a precisão dos dados, tente entender essas diferenças. Os dados do RUM podem ser filtrados para se alinharem melhor ao CrUX (analisando apenas os usuários do Chrome, para computadores ou dispositivos móveis, com valores do 75º percentil em 28 dias) para reduzir essas diferenças?
Se for o caso, e você conseguir que os dados fiquem mais próximos, ainda assim é importante entender por que essas diferenças estão aparecendo nos dados gerais e o que isso significa. Os usuários que não usam o Chrome estão distorcendo suas métricas de forma positiva ou negativa? Isso ajuda você a entender melhor onde estão os problemas de desempenho que podem ser priorizados?
Se os usuários que não usam o Chrome estiverem recebendo resultados diferentes, use esse insight valioso do RUM para otimizar de outra forma. Por exemplo, algumas APIs não estão disponíveis em determinados navegadores, mas você pode considerar alternativas para navegadores sem suporte para melhorar as experiências deles. Ou você pode oferecer uma experiência diferente, mas com melhor desempenho, para usuários em dispositivos ou redes limitados. O CrUX é limitado aos dados do Chrome, mas você deve considerar as experiências de todos os visitantes do site para priorizar as melhorias. Os dados de RUM podem preencher essa lacuna.
Depois de entender os motivos das diferenças, as duas ferramentas podem ser muito úteis para entender as experiências do usuário no seu site e ajudar a melhorá-las, mesmo que os números não sejam idênticos. Use os dados de RUM para complementar os dados do CrUX e analisar o que o CrUX está informando em um nível geral, segmentando o tráfego para identificar se há áreas específicas do site ou da base de usuários que requerem atenção.
Analisar as tendências para ver se as melhorias estão tendo os impactos positivos esperados geralmente é mais importante do que fazer com que cada número corresponda exatamente entre as duas fontes de dados. Como mencionado anteriormente, o RUM permite que você analise diferentes períodos para ter uma prévia de quais serão suas pontuações do CrUX de 28 dias. No entanto, analisar períodos muito curtos pode levar a dados com ruído, por isso o CrUX usa 28 dias.
Muitas vezes, não há uma resposta "certa" ou "errada" nessas métricas. Elas são apenas uma perspectiva diferente sobre os usuários e como eles estão usando seu site. O mais importante para atender melhor os visitantes do seu site é entender por que essas diferenças acontecem e como elas podem influenciar suas decisões.