Почему данные CrUX отличаются от моих данных RUM?

Узнайте о причинах, по которым данные RUM могут показывать разные показатели Core Web Vitals от CrUX.

Барри Поллард
Барри Поллард

Отчет об опыте пользователей Chrome (CrUX) предоставляет показатели пользовательского опыта, показывающие, как реальные пользователи Chrome взаимодействуют с популярными сайтами в Интернете. Эти данные автоматически собираются Chrome от пользователей, которые дали свое согласие, и предоставляются на основании критериев приемлемости CrUX .

Таким образом, данные CruX доступны для миллионов веб-сайтов. Многие владельцы сайтов раньше не имели доступа к полевым данным, и CrUX позволил многим сайтам впервые увидеть ценность этого. Будучи общедоступным набором данных, CrUX также может использоваться для конкурентного анализа и сравнительного анализа показателей пользовательского опыта.

Мониторинг реальных пользователей (RUM) аналогичен CrUX, но вместо того, чтобы Chrome автоматически собирал показатели пользовательского опыта, на веб-сайты включается код, который выполняет этот сбор и передает его поставщику RUM или аналитическому решению для дальнейшего анализа.

Поскольку оба решения измеряют показатели пользовательского опыта, естественно предположить, что они должны быть эквивалентными. Когда мы видим различия, это может сбивать с толку. В этом руководстве объясняется, почему это может произойти, и предлагаются советы, что делать, если цифры не совпадают.

Преимущества дополнения CrUX решением RUM

CrUX — отличный инструмент для единообразного просмотра всех сайтов, и, поскольку это официальный набор данных для программы Core Web Vitals , сайты, скорее всего, захотят следить за тем, что он показывает. Цель CrUX — предоставить статистически значимый обзор миллионов веб-сайтов для перекрестного сравнения.

Однако для более глубокого изучения того, почему данные показывают такие цифры, инвестиции в полное решение RUM в дополнение к CrUX могут дать вам доступ к более подробной информации, чем можно сделать доступной в общедоступном наборе данных. Это может помочь вам объяснить и улучшить ваши показатели разными способами.

Более глубокий анализ для изучения проблем

CrUX часто можно использовать, чтобы указать, есть ли у вас проблемы на вашем сайте, но не обязательно, где именно на вашем сайте возникла проблема и почему. Решения RUM — будь то отечественные разработки , подобные библиотеке веб-виталей или некоторые из многих коммерческих продуктов — могут помочь преодолеть этот разрыв.

Использование решения RUM дает вам доступ к гораздо более подробным данным для всех ваших страниц и во всех браузерах. Это также позволяет вам разбивать эти данные на части так, как этого не делает CrUX, что позволяет вам детализировать и исследовать проблемные области сайта. Затрагивают ли они определенный сегмент пользователей? Или пользователи, которые совершают определенные действия? Когда именно началась проблема? Это вопросы, на которые гораздо легче ответить, имея дополнительные данные, которые может предоставить инструмент RUM.

Корреляция с другими бизнес-показателями

RUM также позволяет вам напрямую сравнивать показатели производительности вашего веб-сайта с любыми бизнес-показателями, показывая ценность инвестиций в производительность и то, какие другие показатели производительности следует расставить по приоритетам. У нас есть множество тематических исследований компаний, проводящих такую ​​корреляцию, например Farfetch или The Economic Times .

Сбор других данных о производительности

Решение RUM позволяет собирать другие пользовательские показатели, напрямую связанные с вашим конкретным бизнесом. Одним из наиболее известных примеров является показатель Twitter « Время первого твита ». Эти специфичные для сайта показатели затем можно сопоставить с улучшениями Core Web Vital и бизнес-показателями.

Различия между двумя наборами полевых данных

Человек с часами знает, который час. Человек с двумя часами никогда не уверен.

Закон Сигала

Всякий раз, когда у вас есть два источника данных, часто может возникнуть путаница и разочарование в том, почему они различаются. Точно так же, как важно понимать разницу между лабораторными и полевыми показателями , также могут быть различия между двумя источниками полевых данных. Хотя в идеальном мире данные были бы одинаковыми, существует множество причин, по которым они могут отличаться.

Лабораторные данные и полевые данные

Первое, что нужно проверить, — смотрите ли вы на лабораторные (синтетические) показатели или на полевые (RUM) показатели. Хотя естественно предположить, что продукты RUM анализируют только полевые данные, многие из них также предлагают лабораторный компонент.

Лабораторные данные невероятно полезны именно потому, что они измеряются в фиксированных условиях. Его можно использовать для мониторинга неожиданных изменений или регрессов в производственной среде без шума, связанного с изменением численности населения на полях. Однако лабораторные данные могут не отражать реальный пользовательский опыт, поэтому полевые показатели могут показывать совершенно другие результаты.

Население

Наборы данных, используемые решениями CrUX и RUM, могут различаться из-за различий в том, какие посещения страниц измеряются, в зависимости от того, какие браузеры, пользователи, сайты и устройства сравниваются.

Включенные браузеры

Отчет об опыте использования Chrome, как следует из названия, предназначен только для Chrome. Несмотря на то, что существует множество браузеров на базе Chromium (например, Edge, Opera и Brave), которые также поддерживают те же показатели, что и Chrome, учитывая общую базовую кодовую базу, только пользователи Chrome передают данные в CrUX. Это ограничение также означает, что пользователи Chrome на iOS не включены, поскольку он использует базовый движок браузера Webkit. Android WebViews также не считается «Chrome», поэтому данные этих пользователей не учитываются, хотя пользовательские вкладки Chrome включены.

Хотя Chrome является одним из самых популярных браузеров в мире и, следовательно, в большинстве случаев он, скорее всего, даст широкое представление о производительности вашего сайта, измерение только этого браузера ни в коем случае не является показателем всех ваших пользователей. Это может объяснить одно основное различие между RUM и CrUX. Это особенно актуально для методов повышения производительности, которые полагаются, например, на API или форматы изображений, доступные только в Chrome.

Отсутствие данных iOS также может привести к предвзятости. Например, поскольку пользователи iOS обычно используют более производительные устройства или посещают больше стран с лучшей сетевой инфраструктурой, их включение может привести к повышению общих показателей производительности. С другой стороны, их исключение — как это делает CrUX — может привести к тому, что данные будут перекошены в сторону нижней части посетителей сайта ( пример тематического исследования ). Пользователи Android обычно охватывают более широкий спектр устройств, возможностей устройств и рынков.

Решения RUM могут получать данные для браузеров, отличных от Chrome, и, в частности, из браузеров на базе Chromium, в которые часто встроены одни и те же показатели (например, Core Web Vitals). Браузеры, не основанные на Chromium, также измеряются с помощью решений RUM, но могут имеют более ограниченный набор показателей. Например, функции Largest Contentful Paint (LCP) и Cumulative Layout Shift (CLS) в настоящее время доступны только в браузерах на базе Chromium, а некоторые другие показатели можно измерять совершенно по-другому (см. ниже).

Подключившиеся пользователи

Помимо того, что CrUX ограничен только пользователями Chrome, он дополнительно ограничивается измерением только подмножества пользователей Chrome , которые согласились поделиться данными CrUX при установке браузера.

Поставщики RUM также смотрят только на подгруппу пользователей, обычно из-за подсказок баннера cookie, предлагающих пользователям согласиться на сбор данных RUM, или блокировщиков отслеживания. Это может отрицательно повлиять на загрузку некоторых начальных страниц, если подтверждение не будет предоставлено до второй или последующей страницы, когда некоторые ресурсы сайта уже были кэшированы с предыдущих страниц. Если это происходит часто, метрики в RUM могут оказаться более благоприятными, чем они есть на самом деле, если в достаточном количестве случаев исключить более медленную начальную загрузку страниц.

Включенные сайты

CrUX предназначен только для предоставления отчетов об общедоступных веб-сайтах, поэтому существуют другие критерии отбора , которые могут привести к тому, что данные не будут регистрироваться в CrUX. Наиболее примечательным из этих критериев является то, что веб-сайт должен быть общедоступным и достаточно популярным, чтобы обеспечить минимальный размер выборки, на основе которой можно сделать значимые выводы. В большинстве случаев это приведет к отсутствию данных в CrUX. Эта разница не так сбивает с толку по сравнению с доступными, но разными данными, но объясняет, почему это происходит.

Однако если определенные страницы сайта помечены как индексируемые, а другие нет, то в CrUX вы можете увидеть только подмножество URL-адресов. Если источник общедоступен, то все просмотры страниц в этом источнике будут включены в данные уровня источника, но данные уровня URL-адреса могут быть недоступны.

Устройства

CrUX сегментирует данные по мобильным устройствам, настольным компьютерам и планшетам, хотя многие инструменты концентрируются на первых двух и могут не раскрывать данные планшетов или могут включать их в мобильные или настольные устройства. Характеристики производительности мобильных устройств и настольных компьютеров могут сильно различаться — как с точки зрения доставляемого контента, так и с точки зрения возможностей устройств, просматривающих его.

Данные RUM позволяют аналогичным образом сегментировать трафик, но по умолчанию часто отображают консолидированные данные. RUM может позволить легко сегментировать только по типу устройства (например, мобильное) или браузеру (например, Chrome), но не по обоим этим параметрам, чтобы видеть только мобильный трафик Chrome. При сравнении с данными CrUX убедитесь, что вы сравниваете сопоставимые данные, отфильтровав их по типу устройства и браузеру Chrome.

Выборка

Решения RUM обычно позволяют регулировать частоту выборки согласившихся посетителей, где собираются данные. Это можно использовать для уменьшения объема данных, необходимых для анализа, а также для снижения затрат на коммерческие услуги RUM. Если размер выборки слишком мал и не репрезентативен для более широкой популяции, то результирующие показатели также будут искажены аналогичным образом. Обсудите со своим поставщиком RUM подходящий размер выборки для вашего сайта.

Агрегация данных

Полевые данные по своей природе будут включать в себя множество точек данных с одинаковыми показателями по сравнению с лабораторными данными, которые дают одно значение. Если эти данные для отчетности агрегируются по-разному, это может привести к другой причине различий между CrUX и RUM.

Промежуток времени

Данные CrUX основаны на 28-дневном скользящем окне трафика, и изменить этот временной интервал невозможно, хотя данные BigQuery сохраняются за каждый месяц, что позволяет вам видеть предыдущие месяцы.

Данные RUM обычно обеспечивают гораздо большую степень детализации, что позволяет гораздо раньше увидеть влияние изменений. Однако при выборе меньших периодов на данные RUM могут оказывать неоправданное влияние колебания трафика веб-сайта и посетителей. Сравнивая данные RUM с данными CrUX, всегда проверяйте производительность за 28 дней. Как только вы убедитесь, что данные аналогичны, вы можете просмотреть другие временные интервалы, чтобы детализировать данные RUM.

Агрегация статистики

Метрики CrUX измеряются на уровне 75-го процентиля, то есть исходя из значения, достигнутого 75% просмотров страниц. В полевых данных будут экстремальные значения, и если исключить 25% худших впечатлений, это призвано дать ценность, которую можно разумно ожидать от большинства посетителей.

Продукты RUM часто предоставляют более широкий выбор способов агрегирования показателей, включая 75-й процентиль, медиану и другие процентили. При сравнении значений RUM с данными CrUX необходимо убедиться, что вы просматриваете данные 75-го процентиля для сопоставимого сравнения.

Данные гистограммы в CrUX включают все доступные данные, а не только 75-й процентиль, и показывают количество просмотров страниц в каждом рейтинге, но совокупный балл будет основан на 75-м процентиле. Эти данные CrUX отображаются в таких инструментах, как PageSpeed ​​Insights :

Скриншот PageSpeed ​​Insights, на котором показаны гистограммы загрузки страниц рейтинга LCP.

Различия в метриках

Для измерения веб-производительности используется множество показателей, поэтому при сравнении двух разных наборов данных важно понимать, какие показатели измеряются и как эти показатели используются.

Измеренные показатели

Данные CrUX — это официальный набор данных инициативы Core Web Vitals , который в первую очередь измеряет эти три показателя ( LCP , FID и CLS ), а также несколько дополнительных показателей , дополняющих их.

Инструменты RUM обычно включают в себя эти основные веб-показатели, но часто также включают в себя множество других показателей. Некоторые поставщики RUM также измеряют пользовательский опыт, используя собственную комбинацию всех этих показателей, возможно, для определения индекса счастья или чего-то подобного. Сравнивая данные RUM с CrUX, убедитесь, что вы сравниваете аналогичные данные.

Инструменты, которые оценивают статус «пройден/не пройден» основных веб-показателей, должны учитывать прохождение страницы, если она соответствует рекомендуемым целевым показателям на уровне 75-го процентиля для всех основных веб-показателей. Если FID отсутствует для страниц без взаимодействий, то необходимо пройти только LCP и CLS.

Различия в показателях в разных браузерах

CrUX измеряет только в браузерах Chrome, и вы можете обратиться к журналу изменений Web Vitals , чтобы увидеть, как они меняются с каждой версией Chrome.

Однако решения RUM будут измеряться с помощью более широкого спектра браузеров. Браузеры на базе Chromium (Edge, Opera и т. д.), скорее всего, будут похожи на Chrome, если только Chrome не внедрит новые изменения, как указано в журнале изменений.

Для браузеров, отличных от Chromium, различия могут быть более заметными. Например, First Contentful Paint (FCP) доступен в Safari и Firefox, но измеряется другим способом . Это может привести к значительным отклонениям в отчетных сроках. Как указывалось ранее, если вы хотите сравнить RUM и CrUX, лучше всего отфильтровать только пользователей Chrome, чтобы обеспечить сопоставимое сравнение.

Тайминг метрик

Метрики Core Web Vitals предоставляются API-интерфейсами веб-браузера, но это не означает, что с их помощью не может быть различий в значениях. Точное время измерения показателей — при загрузке страницы или на протяжении всего ее жизненного цикла — может привести к различиям. Инструменты RUM не всегда могут измерять показатели одинаковым способом (даже если они используют одни и те же имена) и одни и те же API-интерфейсы браузера для получения данных, что может сбивать с толку.

Наибольшая отрисовка контента (LCP) — это показатель загрузки страницы. Веб-API может сообщить о ряде элементов LCP, если более крупные элементы загружаются позже после первоначальной отрисовки. Последний элемент LCP — это момент завершения загрузки страницы или взаимодействия пользователя со страницей. Поэтому различия могут возникнуть, если об элементе LCP сообщается раньше, чем об этих двух событиях.

Кроме того, в данных поля элемент LCP может отличаться в зависимости от того, как загружается страница. При загрузке страницы по умолчанию, показывающей верхнюю часть содержимого страницы, элемент LCP будет зависеть в первую очередь от размера экрана. Однако если страница открывается с помощью привязки дальше по документу или аналогичным образом открывается с помощью глубокой ссылки на одностраничное приложение (SPA) — подробнее об этом позже — тогда элемент LCP может быть другим.

Не предполагайте, что тайминги LCP, представленные в CrUX или RUM, основаны на том же элементе, что и лабораторные инструменты. Хотя CrUX предоставит вам общее значение LCP для каждой страницы или источника, RUM может сегментировать его дальше, чтобы идентифицировать отдельные сеансы проблем LCP.

Совокупный сдвиг макета (CLS) измеряется на протяжении всего срока существования страницы , поэтому CLS при начальной загрузке страницы может не отражать страницы, которые вызывают большие сдвиги позже, после загрузки страницы и взаимодействия с ней пользователя. Таким образом, получение значения CLS только после загрузки страницы — как это делают многие продукты RUM — даст другой результат, чем получение значения CLS после того, как пользователь завершит работу со страницей.

Первая задержка ввода (FID) требует измерения ввода, поэтому ее нельзя измерить при загрузке страницы. Но, как следует из названия, FID измеряет только первый входной сигнал . Новая метрика реакции взаимодействия с следующей отрисовкой (INP) измеряет все взаимодействия на протяжении всего времени существования страницы, аналогично CLS, поэтому сообщаемое значение INP может сильно отличаться, если измеряется после того, как пользователь совершил несколько взаимодействий. на странице.

CrUX будет следовать документации Core Web Vitals и измерять их на протяжении всего жизненного цикла страницы. Многие поставщики RUM вместо этого предпочитают измерять эти показатели либо после загрузки страницы, либо в какое-то другое время (например, при нажатии на ключевой призыв к действию) по разным причинам.

Если вы видите необъяснимые различия между двумя источниками данных, важно получить от вашего поставщика RUM информацию о том, когда измеряются основные веб-показатели.

Одностраничные приложения

Одностраничные приложения (SPA) работают, обновляя содержимое текущей страницы, а не выполняя традиционную навигацию по страницам на уровне браузера. Это означает, что браузер не воспринимает их как навигацию по страницам, несмотря на то, что пользователи воспринимают их как таковые. API-интерфейсы Core Web Vitals, предоставляемые браузером, не принимают их во внимание , и поэтому CrUX в настоящее время не поддерживает такую ​​навигацию по страницам. В настоящее время ведется работа над решением этой проблемы — дополнительную информацию см. в статье «Эксперименты с измерением программной навигации» .

Некоторые провайдеры RUM действительно пытаются обнаружить «мягкую навигацию» в SPA, но если они также приписывают метрики Core Web Vitals этим «мягким навигациям», это приведет к различиям с CrUX, поскольку базовые API не поддерживают это.

Различия между CruX и веб-API

Помимо различий в том , как и что измеряется, есть несколько других, более сложных сценариев, которые могут привести к различиям в данных CrUX и RUM. Некоторые из них связаны с ограничениями веб-API, используемых для измерения показателей, а некоторые связаны с тем, что результаты, возвращаемые API, необходимо обрабатывать по-разному для определенных сценариев. В документации Core Web Vitals перечислены эти различия для LCP , CLS и FID , но основные различия указаны ниже.

Назад/вперед кеш

CrUX рассматривает восстановление кэша «обратно/вперед» (или bfcache) как навигацию по страницам, даже если они не приводят к традиционной загрузке страницы. Поскольку веб-API не рассматривают это как загрузку страницы, решениям RUM необходимо предпринять дополнительные шаги для подсчета этих страниц, если они хотят соответствовать CrUX. Это значительно более быстрая загрузка страниц, которая может привести к повышению общей производительности сайта, поэтому их неучет может привести к ухудшению общих показателей производительности страницы. Обратитесь к своему решению RUM, чтобы понять, обрабатывают ли они восстановленные страницы bfcache.

Iframes

По соображениям безопасности и конфиденциальности страницы верхнего уровня не имеют доступа к содержимому внутри iframe (даже к iframe того же происхождения). Это означает, что показатели производительности контента в них могут быть измерены только самим iframe, а не через веб-API на странице фрейма. Если содержимое iframe включает элемент LCP или контент, который влияет на CLS, FID или INP, с которыми сталкивается пользователь, он не будет доступен для решений RUM ( включая библиотеку JavaScript Google web-vitals ).

Однако CrUX, измеряемый самим браузером Chrome, а не страницей, не имеет этих ограничений, а также измеряет показатели внутри iframe при составлении отчетов об основных веб-показателях. Это более точно отражает то, что испытывает пользователь, но может быть еще одной причиной различий для сайтов, использующих iframe.

Одним конкретным примером того, как это может привести к различиям между данными LCP в CrUX и RUM, является встроенный <video> . Первый нарисованный кадр элемента <video> с автовоспроизведением может считаться кандидатом LCP, но при внедрении популярных сервисов потокового видео эти элементы могут помещаться в <iframe> . По состоянию на август 2023 года CrUX может это учитывать, поскольку он может получить доступ к содержимому <iframe> , но решения RUM не могут.

Ресурсы из разных источников

Носители LCP, обслуживаемые из других доменов, не предоставляют время рендеринга в PerformanceObserver API — если не предоставлен заголовок Timing-Allow-Origin (TAO) — из-за ограничений безопасности браузера, позволяющих уменьшить время атак. Это соответствует времени загрузки ресурса , но оно может сильно отличаться от того, когда контент был фактически нарисован.

Это может привести к, казалось бы, невозможной ситуации, когда веб-API сообщают о LCP раньше, чем о FCP. Это не так, но так кажется только из-за этого ограничения безопасности.

Опять же, CrUX сообщает данные о времени рендеринга для Core Web Vitals. Сайтам рекомендуется ограничивать контент из разных источников, который влияет на показатели Core Web Vitals, и включать TAO, где это возможно, если они хотят измерить это более точно. Другие ресурсы перекрестного происхождения могут подвергаться аналогичным ограничениям.

Фоновые вкладки и предварительный рендеринг

Когда страница не открывается на переднем плане (например, при открытии ее в фоновом режиме или если она использует параметры предварительной отрисовки (в настоящее время разрабатываются для Chrome)), они все равно будут отправлять метрики через веб-API. Однако CrUX не сообщает об этом, поскольку они указывают время, не соответствующее пользовательскому опыту. Решения RUM также должны игнорировать их или, по крайней мере, объяснять, как обрабатываются такие просмотры страниц.

Так что же мы можем с этим поделать?

Мы показали, почему между данными CrUX и RUM могут быть различия: либо из-за различий в методологии, которую каждый использует, либо из-за того, какие пользователи и просмотры страниц включены или исключены. В идеале оба набора данных по-прежнему будут отражать производительность вашего сайта и быть полезными, но в этой статье должно быть объяснено, почему маловероятно получить одинаковые цифры в каждом.

Если различия незначительны (например, сообщение о LCP 2,0 секунды против 2,2 секунды), оба набора данных будут полезны и обычно могут считаться примерно синхронизированными.

Когда явные различия заставляют вас усомниться в точности данных, вам следует попытаться понять эти различия. Можно ли отфильтровать данные RUM, чтобы они были более тесно связаны с CrUX (рассматривая только пользователей Chrome, для настольных компьютеров или мобильных устройств, со значениями 75-го процентиля за 28 дней), чтобы уменьшить эти различия?

Если да – и вы можете добиться более точного соответствия данных – тогда вам все равно следует спросить, почему вы видите эти различия в общих данных и что это означает. Пользователи, не использующие Chrome, искажают ваши показатели в положительную или отрицательную сторону? Дает ли это вам больше информации о проблемах с производительностью, которые вы можете расставить по приоритетам?

Если ваши пользователи, не использующие Chrome, получают разные результаты, вы можете использовать эту ценную информацию, которую RUM дал вам, для другой оптимизации. Например, некоторые API-интерфейсы недоступны в определенных браузерах, но вы можете рассмотреть альтернативы для неподдерживаемых браузеров, чтобы улучшить их работу. Или вы можете предоставить другой, но более эффективный опыт пользователям на ограниченных устройствах или в сетях. CrUX ограничен данными Chrome, но вам следует учитывать все впечатления посетителей вашего сайта, чтобы определить приоритетность улучшений. Данные RUM могут восполнить этот пробел.

Как только вы поймете причины любых различий, оба инструмента могут быть невероятно полезны для понимания пользовательского опыта вашего веб-сайта и улучшения его, даже если цифры не идентичны. Используйте свои данные RUM, чтобы дополнить данные CrUX и позволить вам углубиться в то, что CrUX говорит вам на высоком уровне, сегментируя ваш трафик, чтобы помочь вам определить, требуют ли внимания определенные области вашего сайта или пользовательской базы.

Анализ тенденций, чтобы увидеть, что ваши улучшения оказывают ожидаемое положительное воздействие, зачастую более важен, чем точное совпадение чисел в двух источниках данных. Как упоминалось выше, RUM позволяет вам просматривать разные временные интервалы, чтобы заранее узнать, какими будут ваши 28-дневные показатели CrUX, хотя просмотр слишком коротких временных интервалов может привести к зашумленным данным, поэтому CrUX использует 28 дней.

Часто в этих различных показателях нет «правильного» или «неправильного» ответа — они просто смотрят на ваших пользователей по-разному и на то, как они воспринимают ваш сайт. Если вы понимаете, почему возникают эти различия и как это может влиять на принятие вами решений, именно это становится более важным для лучшего обслуживания посетителей вашего сайта.

Благодарности

Изображение героя Стивена Лелхэма на Unsplash