Saiba por que os dados RUM podem mostrar números diferentes das Core Web Vitals no CrUX.
O Chrome User Experience Report (CrUX, na sigla em inglês) mostra métricas de experiência do usuário que mostram como usuários reais do Chrome acessam destinos populares na Web. Esses dados são coletados automaticamente pelo Chrome em relação aos usuários que ativaram o recurso 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 nunca tiveram 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 monitoramento real de usuários (RUM, na sigla em inglês) é 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 alimentá-lo a um provedor de RUM ou uma solução de análise para análise posterior.
Como ambas as soluções medem as métricas de experiência do usuário, é natural presumir que devem ser equivalentes. Pode ser confuso quando vemos diferenças. Este guia explica por que isso pode acontecer e oferece sugestões do que fazer quando os números não estão alinhados.
Benefícios de complementar o CrUX com uma solução RUM
O CrUX é uma ótima ferramenta para ter uma visão consistente em todos os sites e, como o conjunto de dados oficial do programa Core Web Vitals, é provável que os sites queiram ficar de olho no que está sendo mostrado. O objetivo do CrUX é oferecer uma visão geral estatisticamente relevante de milhões de sites para comparação.
No entanto, para se aprofundar na investigação por que os dados estão mostrando os números reais, investir em uma solução RUM completa para complementar o CrUX pode dar acesso a informações mais detalhadas do que podem ser disponibilizadas em um conjunto de dados de consulta pública. Isso pode ajudar você a explicar e melhorar suas métricas de várias maneiras.
Análises mais profundas para investigar problemas
O CrUX muitas vezes pode ser usado para indicar se você tem um problema em seu site, mas não necessariamente em que parte do site o problema está ou o motivo. Soluções RUM, sejam elas cultivadas internamente pela biblioteca web-vitals ou alguns dos muitos produtos comerciais, podem ajudar a preencher essa lacuna.
Usar uma solução RUM dá acesso a dados muito mais refinados para todas as suas páginas e em todos os navegadores. Ele também permite segmentar e analisar esses dados de maneira que o CrUX não faz, permitindo detalhar e investigar á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? Exatamente quando o problema começou? Essas perguntas são muito mais fáceis de responder com os dados adicionais que uma ferramenta RUM pode fornecer.
Correlacionar-se a outras métricas de negócios
O RUM também permite comparar suas métricas de desempenho da Web diretamente com qualquer métrica de negócios, mostrando o valor do investimento em desempenho e quais outros desempenhos precisam ser priorizados. Temos vários estudos de caso com empresas que fazem essa correlação, como a Farfetch ou o The Economic Times.
Colete outros dados de desempenho
Com uma solução RUM, é possível coletar outras métricas personalizadas diretamente relacionadas à sua empresa. Um dos exemplos mais conhecidos é o "Time to first Tweet" do Twitter métrica. Essas medidas específicas do site podem ser correlacionadas com as melhorias das 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 não tem certeza.
Lei de Segal
Sempre que você tem duas fontes de dados, pode ser confuso e frustrante saber por que elas diferem. 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. Os dados seriam os mesmos em um mundo ideal, mas há muitas razões pelas quais eles podem ser diferentes.
Dados de laboratório versus dados de campo
A primeira coisa a verificar é se você está analisando métricas (sintéticas) de laboratório ou métricas de campo (RUM). Embora seja natural presumir que os produtos RUM só analisam dados de campo, muitos também oferecem um componente de laboratório.
Os dados de laboratório são incrivelmente úteis precisamente 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 constante mudança. No entanto, como os dados do laboratório podem não representar a experiência real do usuário, as métricas de campo podem mostrar resultados bem diferentes.
Populações
Os conjuntos de dados usados pelas soluções CrUX e RUM podem ser diferentes devido às diferenças na medição das visitas à página, dependendo de quais navegadores, usuários, sites e dispositivos estão sendo comparados.
Navegadores incluídos
O Chrome User Experience Report, como o nome sugere, é exclusivo do Chrome. Embora vários navegadores baseados no Chromium (Edge, Opera e Brave, entre outros) também ofereçam suporte às mesmas métricas do Chrome, considerando a base de código principal compartilhada, apenas os usuários do Chrome inserem dados no CrUX. Essa restrição também significa que os usuários do Chrome no iOS não serão incluídos, já que ele usa o mecanismo do navegador Webkit. Os WebViews do Android também não contam como "Chrome", então os dados desses usuários não são incluídos, embora as guias personalizadas do Chrome estejam incluídas.
Embora o Chrome seja um dos navegadores mais populares do mundo (e, portanto, provavelmente ofereceria uma ampla representação do desempenho do seu site na maioria dos casos), ele não é uma medida de todos os seus usuários. Isso pode explicar uma diferença principal entre RUM e CrUX. Isso é particularmente verdadeiro para técnicas de desempenho que dependem de APIs ou formatos de imagem disponíveis apenas no Chrome, por exemplo.
A falta de dados do iOS também pode levar a um viés. Por exemplo, já que os usuários do iOS geralmente usam dispositivos com melhor desempenho ou visitam mais países com melhor infraestrutura de rede, a inclusão desses usuários pode levar a altas métricas de desempenho geral. Por outro lado, excluir esses usuários, como no CrUX, pode levar a dados distorcidos para os poucos visitantes do site (exemplo de estudo de caso). Os usuários do Android geralmente abrangem uma variedade maior de dispositivos, recursos de dispositivos e mercados.
As soluções RUM podem coletar dados de navegadores que não sejam o Chrome, especialmente de navegadores baseados no Chromium, que geralmente têm as mesmas métricas integradas (como as Core Web Vitals). Os navegadores que não são baseados no Chromium também são medidos por soluções RUM, mas podem ter um conjunto mais limitado de métricas. Por exemplo, Cumulative Layout Shift (CLS) e Interação com a próxima exibição (INP, na sigla em inglês) estão disponíveis apenas em navegadores baseados no Chromium. Algumas outras métricas, como a First Contentful Paint (FCP, na sigla em inglês), podem ser medidas de maneira bem diferente (veja mais adiante).
Usuários que ativaram o recurso
Além de ser limitado aos usuários do Chrome, o CrUX é ainda mais restrito, medindo apenas um subconjunto de usuários do Chrome que aceitou compartilhar dados do CrUX quando o navegador foi instalado.
Os provedores de RUM também consideram apenas um subconjunto de usuários, geralmente devido aos banners de cookies, que solicitam que os usuários aceitem a coleta de dados RUM, ou aos bloqueadores de rastreamento. Isso poderá afetar negativamente alguns carregamentos de páginas iniciais se a confirmação não for dada até a segunda página ou a página seguinte, quando alguns dos recursos do site já tiverem sido armazenados em cache nas páginas anteriores. Se isso acontecer com frequência, talvez as métricas pareçam mais favoráveis no RUM do que realmente são se os carregamentos de página iniciais mais lentos forem excluídos em um número suficiente de casos.
Sites incluídos
Como o CrUX se destina apenas a relatórios em sites públicos, há outros critérios de qualificação que podem fazer com que os dados não sejam registrados no CrUX. O mais notável desses critérios é que o site deve ser publicamente descoberto e popular o suficiente para garantir um tamanho de amostra mínimo para tirar conclusões significativas. Na maioria dos casos, isso não disponibilizará os dados no CrUX. Essa é uma diferença menos confusa em comparação com os dados disponíveis, mas diferente, mas explica por que isso acontece.
No entanto, se páginas específicas de um site forem marcadas como indexáveis, mas outras não, talvez você veja apenas um subconjunto de URLs no CrUX. Se a origem for publicamente detectável, todas as visualizações de página dela serão incluídas nos dados no nível da origem, mas os dados no nível do URL podem não estar disponíveis.
Dispositivos
O CrUX segmenta dados por dispositivos móveis, computadores e tablets, embora muitas ferramentas se concentrem nas duas primeiras e não exponham os dados de tablets ou possam incluí-los em dispositivos móveis ou computadores. As características de desempenho em dispositivos móveis e computadores podem ser bastante diferentes, tanto em termos de conteúdo enviado quanto de recursos.
Os dados RUM permitirão segmentar o tráfego de maneira semelhante, mas geralmente mostram dados consolidados por padrão. O RUM só permite a segmentação por tipo de dispositivo (por exemplo, dispositivo móvel) ou navegador (por exemplo, Chrome), mas não para 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 parecidos filtrando por tipo de dispositivo e pelo navegador Chrome.
Amostragem
As soluções RUM normalmente permitem ajustar a taxa de amostragem dos visitantes que aceitaram participar quando os dados são coletados. Isso pode ser usado para reduzir o volume de dados que precisam ser analisados e para reduzir os custos de serviços comerciais de RUM. Se esse tamanho da amostra for muito pequeno e não for representativo da população mais ampla, as métricas resultantes também serão distorcidas de forma semelhante. Converse com seu fornecedor de RUM sobre o tamanho de amostragem apropriado para seu site.
Agregação de dados
Por sua natureza, os dados de campo incluirão muitos pontos de dados das mesmas métricas em comparação com os dados de laboratório, o que resultará em um único valor. Se esses dados forem agregados de maneira diferente para fins de relatório, talvez haja outro motivo para as diferenças entre o CrUX e o RUM.
Período
Os dados do CrUX são baseados em uma janela de tráfego deslizante de 28 dias, e não é possível alterar esse período. No entanto, os dados do CrUX do 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. Ambas ainda fornecem dados com base na janela deslizante de 28 dias.
Dados RUM normalmente permitem uma granularidade muito maior para permitir ver o impacto das alterações muito antes. No entanto, ao escolher períodos menores, os dados da RUM podem ser indevidamente afetados por flutuações no tráfego do site e nos visitantes. Ao comparar dados RUM com dados CrUX, sempre verifique o desempenho dos últimos 28 dias. Quando você achar que os dados estão semelhantes, poderá consultar outros períodos para analisar os dados de RUM.
Agregação de estatísticas
As métricas CrUX são medidas no 75o percentil, ou seja, observando o valor alcançado por 75% das visualizações de página. Haverá extremos nos dados de campo e a remoção dos piores 25% de experiências, o objetivo é fornecer um valor que possa ser alcançado pela maioria dos visitantes.
Os produtos RUM geralmente oferecem um número maior de opções de como agregar as métricas, incluindo o 75o percentil, a mediana e outros percentis. Ao comparar valores RUM com dados CrUX, é necessário garantir que você esteja analisando dados do 75o percentil para fazer comparações.
Os dados de histograma no CrUX incluem todos os dados disponíveis, não apenas o 75o percentil, e mostram o número de visualizações de página em cada classificação, mas a pontuação agregada terá como base o 75o percentil. Esses dados do CrUX são exibidos em ferramentas como o PageSpeed Insights:
Diferenças nas métricas
Existem muitas métricas usadas para medir o desempenho na Web. Por isso, ao comparar dois conjuntos diferentes de dados, é importante entender quais métricas estão sendo avaliadas e como estão sendo usadas.
Métricas avaliadas
Os dados do CrUX são o conjunto de dados oficial da iniciativa Core Web Vitals e medem principalmente essas métricas (LCP, CLS e INP), com algumas outras métricas para complementá-las.
As ferramentas RUM geralmente incluem essas 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 sua própria combinação de todas essas métricas, talvez para fornecer um "índice de felicidade" ou algo do tipo. Ao comparar dados RUM com o CrUX, verifique se você está comparando dados parecidos.
As ferramentas que avaliam o status de aprovação ou reprovação das Core Web Vitals devem considerar a passagem de página se ela atender aos objetivos recomendados no 75o percentil para todas as Core Web Vitals. Se o INP não estiver presente nas páginas sem interações, apenas a LCP e a CLS precisarão ser aprovadas.
Diferenças de métricas nos navegadores
O CrUX só mede em navegadores Chrome. Consulte os registros de alterações das Métricas da Web para saber como isso muda a cada versão do Chrome.
No entanto, as soluções RUM serão usadas em uma variedade maior de navegadores. Os navegadores baseados no Chromium (Edge, Opera e assim por diante) 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 acentuadas. A First Contentful Paint (FCP, na sigla em inglês), por exemplo, está disponível no Safari e no Firefox, mas é medida de maneira diferente. Isso pode causar variações significativas nos horários informados. Como mencionado anteriormente, se você quiser comparar o RUM com o CrUX, é melhor filtrar apenas os usuários do Chrome para permitir uma comparação justa.
Tempo das métricas
As Core Web Vitals são fornecidas pelas APIs de navegadores da Web, mas isso não significa que não podem existir diferenças nos valores informados ao usá-las. Exatamente quando a medição da métrica é realizada (no carregamento da página ou durante todo o ciclo de vida da página) pode levar a diferenças. As ferramentas RUM nem sempre medem as métricas da mesma forma, mesmo que usem os mesmos nomes, e as mesmas APIs do navegador para conseguir 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 quando o usuário interage com a página. Portanto, poderão ocorrer diferenças se o elemento da LCP for informado antes desses dois eventos.
Além disso, nos dados de campo, o elemento da LCP pode ser diferente, dependendo de como a página é carregada. Para um carregamento de página padrão que mostre a parte superior do conteúdo da página, o elemento da LCP dependerá principalmente do tamanho da tela. No entanto, se a página for aberta com um link âncora mais abaixo no documento ou aberta de forma semelhante com um link direto em um app de página única (SPA, na sigla em inglês), falaremos mais sobre isso posteriormente, o elemento da LCP poderá ser diferente.
Não presuma que os tempos de LCP fornecidos no CrUX e no RUM sejam baseados no mesmo elemento das ferramentas de laboratório. Embora o CrUX informe o valor geral da LCP por página ou origem, o RUM pode segmentar esse valor ainda mais para identificar sessões individuais com problemas de LCP.
A Cumulative Layout Shift (CLS, na sigla em inglês) é medida ao longo da vida útil da página, portanto, a CLS de carregamento de página inicial pode não representar páginas que causam mudanças maiores depois que a página é carregada e o usuário interage com ela. Pegar o valor de CLS somente após o carregamento da página (como muitos produtos RUM) gera, portanto, um resultado diferente de receber o valor de CLS depois que o usuário termina de acessar a página.
A métrica de resposta à Interação com a 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 de INP pode ser muito diferente se medido depois que o usuário tiver feito diversas interações na página.
O CrUX vai seguir a documentação das Core Web Vitals e medir essas métricas durante todo o ciclo de vida da página. Muitos provedores de RUM optam por medir essas métricas após o carregamento da página ou em algum outro momento (por exemplo, quando uma call-to-action importante é clicada) por vários motivos.
É importante compreender com seu provedor de RUM quando as Core Web Vitals são medidas ao ver variações inexplicáveis entre as duas fontes de dados.
Aplicativos de página única
Os aplicativos de página única (SPA) atualizam o conteúdo na página atual em vez de realizarem navegações de página real no navegador. Isso significa que o navegador não os vê como navegação nas páginas, apesar da experiência dos usuários. As APIs Core Web Vitals fornecidas pelo navegador não os consideram. Portanto, o CrUX não é compatível com essas navegações nas páginas. Estamos trabalhando para resolver esse problema. Consulte a postagem Experimentos com a medição de navegação simples para mais informações.
Alguns provedores de RUM tentam detectar "navegação simples" em SPAs, mas também atribuindo métricas das Core Web Vitals a essas "navegações suaves" Isso vai causar diferenças em relação ao CrUX, porque as APIs subjacentes não têm suporte para isso em muitas das métricas.
Diferenças entre o CrUX e a API da Web
Além das diferenças entre quais visualizações de página são medidas e o que é medido, há outros cenários mais complicados que podem gerar diferenças nos dados do CrUX e de RUM. Algumas delas se devem às limitações das APIs Web usadas para medir as métricas, e outras são quando os resultados retornados pela API precisam ser tratados de forma diferente para 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 na página, 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 RUM precisam tomar medidas extras para que essas páginas sejam contadas se quiserem corresponder ao CrUX. Esses carregamentos de página são consideravelmente mais rápidos e podem resultar em um melhor desempenho geral do site. Por isso, não incluí-los pode resultar em piores métricas de desempenho geral da página. Consulte sua solução RUM para entender se eles gerenciam 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 dentro de iframes (nem mesmo de iframes da mesma origem). Isso significa que as métricas de desempenho desses conteúdos só podem ser medidas pelo próprio iframe, e não pelas APIs da Web na página de enquadramento. Se o conteúdo do iframe incluir o elemento da LCP ou afetar o CLS ou o INP usado pelo usuário, isso não estará disponível para as soluções RUM (incluindo a biblioteca JavaScript do Google Web-vitals).
No entanto, o CrUX, sendo medido pelo próprio navegador Chrome em vez do JavaScript na página, não tem essas limitações. O mesmo acontece com as métricas dentro dos iframes ao gerar relatórios das Core Web Vitals. Isso reflete com mais precisão a experiência do usuário, mas pode ser outro motivo para as 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 é incorporado <video>. Um primeiro frame pintado de um elemento <video> de reprodução automática pode contar como um candidato à LCP, mas as incorporações de serviços de streaming de vídeo conhecidos podem colocar esses elementos em uma <iframe>. O CrUX pode considerar isso, já que pode acessar o conteúdo do <iframe>, mas as soluções RUM não.
Recursos de várias origens
A mídia LCP veiculada de outros domínios não fornece tempo de renderização na API PerformanceObserver, a menos que o cabeçalho Timing-Allow-Origin (TAO) seja fornecido, devido às restrições de segurança do navegador para reduzir os ataques de tempo. Isso retorna ao tempo de carregamento do recurso, mas pode ser muito diferente de quando o conteúdo foi realmente pintado.
Isso pode levar a uma situação aparentemente impossível, em que a LCP é informada pelas APIs da Web como anteriores à FCP. Esse não é o caso, apenas aparece devido a essa restrição de segurança.
Novamente, o CrUX informa os dados de tempo de renderização para as Core Web Vitals. Recomendamos que os sites limitem o conteúdo de origem cruzada que afete as métricas das Core Web Vitals e ativem o TAO sempre que possível, se quiserem medir isso com mais precisão. Outros recursos de origem cruzada podem estar sujeitos a restrições semelhantes.
Guias em segundo plano
Quando uma página não é aberta em uma guia em segundo plano, as métricas ainda são emitidas usando APIs da Web. No entanto, eles não são informados pelo CrUX porque mostram horários inconsistentes com a experiência do usuário. As soluções RUM também devem considerar ignorá-las ou pelo menos explicar como essas visualizações de página 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 por diferenças na metodologia usada em cada um deles ou por usuários e visualizações de página que são incluídos ou excluídos. Em condições ideais, ambos os conjuntos de dados ainda representam o desempenho de seu site para serem úteis, mas as razões apresentadas devem descrever por que é muito improvável que obter os mesmos números em cada um.
Quando as diferenças forem pequenas (por exemplo, relatando uma LCP de 2,0 segundos versus 2,2 segundos), ambos os conjuntos de dados serão úteis e geralmente poderão ser considerados quase sincronizados.
Quando diferenças acentuadas fazem você questionar a precisão dos dados, tente entender essas diferenças. É possível filtrar os dados RUM para que fiquem mais alinhados ao CrUX (considerando apenas os usuários do Chrome, em computadores ou dispositivos móveis, com valores de 75o percentil ao longo de 28 dias) a fim de reduzir essas diferenças?
Em caso afirmativo, e você conseguir fazer com que os dados correspondam de maneira mais próxima, você ainda deve perguntar por que está vendo essas diferenças nos dados gerais e o que isso significa. Usuários que não usam o Chrome estão distorcendo suas métricas de forma positiva ou negativa? Isso oferece mais insights sobre onde você tem problemas de desempenho que podem ser priorizados?
Se os usuários que não são do Chrome estão obtendo resultados diferentes, você pode usar esse insight valioso que o RUM forneceu para otimizar de forma diferente. Por exemplo, algumas APIs não estão disponíveis em determinados navegadores, mas você pode considerar alternativas para navegadores incompatíveis para melhorar a experiência. Também é possível oferecer uma experiência diferente, mas com melhor desempenho, aos usuários em redes ou dispositivos restritos. O CrUX está limitado aos dados do Chrome, mas considere todos os visitantes do site e experiências para ajudar a priorizar melhorias. Os dados RUM podem preencher essa lacuna.
Depois de entender os motivos das diferenças, ambas as ferramentas podem ser extremamente úteis para entender as experiências dos usuários no seu site e ajudar a melhorar isso, mesmo que os números não sejam idênticos. Use seus dados RUM para complementar os dados do CrUX e permitir que você se aprofunde no que o CrUX está dizendo de modo geral, segmentando seu tráfego para ajudar a identificar se são áreas específicas do seu site ou base de usuários que precisam de atenção.
Analisar as tendências para ver se suas melhorias estão tendo os impactos positivos esperados geralmente é mais importante do que ter cada número exatamente igual entre as duas fontes de dados. Como mencionado anteriormente, o RUM permite que você veja diferentes períodos para ter uma ideia das suas pontuações do CrUX de 28 dias. No entanto, períodos muito curtos pode gerar dados com ruído. Por isso, o CrUX usa 28 dias.
Muitas vezes, não há “certeza” ou "errado" nessas métricas diferentes, pois são apenas uma perspectiva diferente dos seus usuários e da experiência deles no seu site. Se você entender por que essas diferenças acontecem e o que isso pode fazer para tomar decisões, será mais importante atender melhor os visitantes do site.
Agradecimentos
Imagem de miniatura de Steven Lelham no Unsplash