Мониторинг реальных пользователей: анализ скорости работы веб-сайта в реальных условиях и в лабораторных условиях

Реальные пользователи и лабораторные испытания

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

A Лабораторное испытание В отличие от этого, данная методика позволяет исследовать конкретный вызов в контролируемых условиях. Для проведения исследования можно зафиксировать тип устройства, сетевые условия и ход тестирования. Это упрощает повторное воспроизведение аномалии и проверку возможных изменений в сопоставимых условиях.

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

PageSpeed Insights объединяет обе точки зрения: он сопоставляет доступные полевые данные из отчета Chrome User Experience Report с результатами лабораторных диагностик на основе Lighthouse. Результаты не обязательно должны совпадать, поскольку реальные посещения включают в себя различные условия и сценарии использования, в то время как в лабораторных условиях рассматривается фиксированный тестовый сценарий.

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

Так получаются показания RUM

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

Для этого браузеры предоставляют различные интерфейсы для управления производительностью. Время навигации описывает временные моменты, связанные с переходом к документу, например, время ответа на запрос документа. Resource Timing предоставляет информацию о времени загрузки отдельных ресурсов, таких как изображения или скрипты. Это позволяет более точно определить отдельные этапы процесса загрузки.

A PerformanceObserver отслеживает записи о производительности, как только они становятся доступными. Для показателей Core Web Vitals библиотека может web-vitals осуществляют расчет и отчетность. Набор доступных записей и показателей зависит, в частности, от браузера; поэтому скрипт отслеживания не всегда автоматически фиксирует каждый визит в полном объеме.

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

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

Правильное толкование Core Web Vitals

Die Основные показатели Web описывают три различных аспекта пользовательского опыта. Показатель Largest Contentful Paint (LCP) измеряет, когда становится видимым самый большой значимый элемент контента. На странице продукта это может быть, например, большое изображение товара: если оно появляется с задержкой, то, несмотря на то что панель навигации стала видна раньше, страница может создавать впечатление, что ещё не загрузилась до конца.

Показатель «Interaction to Next Paint» (INP) отражает задержку между взаимодействием пользователя и следующим видимым обновлением. Если фильтр продукта реагирует на нажатие кнопки с заметной задержкой, показатель INP может указывать на эту проблему. Показатель Cumulative Layout Shift (CLS), напротив, описывает неожиданные сдвиги видимого контента, например, когда элемент, появившийся позже, смещает кнопку.

При оценке в PageSpeed Insights показатели LCP до 2,5 секунд включительно, INP до 200 миллисекунд включительно и CLS до 0,1 включительно считаются хорошими. CLS — это величина без единиц измерения. Эти пороговые значения относятся к конкретным показателям и не следует путать их с продолжительностью отдельного просмотра страницы.

Решающим фактором при оценке поля является 75-й процентиль (p75): По крайней мере, примерно 75 процентов учтенных данных не превышают соответствующее значение. В то же время хороший средний показатель сам по себе может скрыть тот факт, что значительная часть посещений происходит с низкой скоростью. Рассматривайте мобильные устройства и настольные компьютеры отдельно, чтобы различия между группами устройств оставались заметными.

Показатель «Время до первого байта» (TTFB) дополняет эти показатели при поиске причин медленного отклика документа. Однако это значение не отражает исключительно время обработки на сервере: на него также влияют сеть и другие узлы, проходящие по пути до поступления первого байта ответа. Показатели Navigation Timing и, при необходимости, предоставленные данные Server Timing помогают более точно проанализировать соответствующие участки.

CrUX, собственный RUM и лаборатория

Для начала тебе не обязательно сразу же запускать собственную систему мониторинга. PageSpeed Insights объединяет полевые данные из Отчет о пользовательском опыте в Chrome (CrUX) с помощью лабораторной диагностики Lighthouse. Эти два вида анализа дают ответы на разные вопросы: один описывает реальный пользовательский опыт, а другой — анализирует страницу в контролируемых условиях.

Данные CrUX в PageSpeed Insights охватывают период за последние 28 дней. Если данных по конкретному URL недостаточно, отчет может вместо этого отображать данные по источнику. Эти данные относятся к соответствующему источнику веб-сайта и не следует приравнивать их к пользовательскому опыту именно на введенной странице. Поэтому обращайте внимание на то, какой уровень фактически отражает отчет.

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

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

Поэтому при выборе следует ориентироваться на вопрос, на который вы хотите ответить: публичный отчет доступен быстро, а собственная система позволяет проводить более целенаправленный сбор данных. Сервис может взять на себя часть оперативной работы, в то время как лабораторные и синтетические испытания позволяют проводить контролируемые исследования. Однако даже при использовании сервиса требуется осознанный отбор данных и групп для анализа.

Как правильно подготовиться к проведению собственных измерений

Сначала сформулируйте конкретный вопрос, например, чаще ли страницы мобильных продуктов демонстрируют высокий показатель LCP по сравнению с другими типами страниц. Затем определите, какие страницы и классы устройств вы хотите различать, какие метрики для этого необходимы и как долго вы планируете собирать данные. Только после этого примите решение относительно скрипта отслеживания, получателя данных и метода анализа.

В качестве первого технического шага ты можешь использовать библиотеку web-vitals включить локально в проект браузера и просмотреть результат в инструментах разработчика. В приведённом ниже коде JavaScript используется опубликованная версия пакета 6.2.3. Предполагается, что эта версия установлена в проекте и сборка обрабатывает импорт модулей. В этом примере данные на сервер не отправляются, и отдельный мониторинг мягкой навигации не активируется.

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

Вывод в консоль — это способ проверить интеграцию, а не показатель скорости работы сайта для ваших посетителей. Откройте страницу проекта и, например, воспользуйтесь фильтром. Показатель INP зависит от соответствующего взаимодействия и не обязательно отображается сразу; без соответствующего взаимодействия он может вообще отсутствовать. На вывод данных также влияют поддержка браузера и жизненный цикл страницы.

Запланируйте для последующего анализа Жизненный цикл страницы Примечание: сообщения могут поступать несколько раз, например, если страница была скрыта, а затем снова отображена. Не следует автоматически учитывать такие сообщения как отдельные посещения. Библиотека предоставляет идентификаторы метрик, с помощью которых сообщения можно соотносить с одной и той же метрикой.

Восстановление из кэша «Back/Forward» также требует определённого подхода. Оно может вызвать появление нового сообщения о метрике, несмотря на то что документ возвращается из кэша. Определите, как вы будете отличать такие восстановления от обычных переходов в своём отчёте, и ознакомьтесь с конкретными рекомендациями по библиотекам, прежде чем настраивать сбор данных в производственной среде.

Анализ результатов измерений по сегментам

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

Для каждого сегмента это 75-й процентиль более информативный, чем просто среднее значение: он показывает значение, которое не превышают как минимум примерно 75 процентов учтенных случаев. Напротив, низкое среднее значение может скрыть тот факт, что какая-то значимая группа вынуждена долго ждать. Сравнивайте p75 только по одному и тому же показателю и с использованием соответствующих единиц измерения.

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

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

Объединяйте повторяющиеся сообщения по идентификатору метрики надлежащим образом, вместо того чтобы рассматривать каждое подтверждение как новое независимое наблюдение. Кроме того, задокументируйте, как подсчитываются восстановления из кэша Back/Forward. Это позволит отслеживать, какие наблюдения действительно входят в p75 и в указанное количество.

От полевой задачи к диагнозу

Если данные полевых испытаний указывают на медленную загрузку страниц товаров на мобильных устройствах, сначала сузьте круг поиска до соответствующего сегмента: касается ли низкий показатель LCP многих товаров или только одного типа страниц? Одновременно проверьте период времени и количество достоверных значений. Таким образом, вы получите отправную точку для исследования, но пока не будете иметь доказательств того, какой именно элемент вызывает задержку.

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

Если появятся сведения о передаче изображений, ты сможешь проанализировать размер файлов, форматы и способы предоставления. Один Сеть доставки контента является одной из возможных мер, но не гарантирует улучшения показателя LCP. Если же ответ документа указывает на наличие узкого места, то поможет дополнительная Бенчмарк сервера для рабочих нагрузок PHP, чтобы изучить работу приложения в определённых условиях.

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

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

Качество данных и защита данных в процессе работы

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

С Минимизация данных Стоит обратить внимание на поля диагностики: полные URL-адреса могут содержать конфиденциальную информацию в параметрах запроса; селекторы DOM также могут раскрывать детали о содержании страницы или вводимых данных. По возможности фиксируйте общий тип страницы и несколько тщательно выбранных атрибутов. Также проверьте, какие данные дополнительно собирает или сохраняет подключенный сервис.

Данные измерений не всегда доступны сразу. Библиотека web-vitals может выдавать отчеты несколько раз в течение жизненного цикла страницы; поэтому более позднее сообщение не всегда следует считать новым независимым посещением. Следует заранее спланировать, как будут обрабатываться связанные между собой сообщения и как будут обрабатываться восстановления из кэша «Назад/Вперед».

Для небольших диагностических пакетов передача данных может осуществляться через sendBeacon во время мероприятия visibilitychange быть подходящим. Это повышает вероятность передачи данных при скрытии страницы, но не гарантирует их доставку. Кроме того, получатель должен надежно принимать данные и обрабатывать их таким образом, чтобы повторные сообщения не искажали результаты анализа незаметно.

И, наконец, учти Пробелы в сборе данных: Заблокированные скрипты, отсутствие поддержки в браузере или потерянные данные о сеансах могут привести к тому, что некоторые посещения не будут учтены. Оцените примерный уровень потерь с учетом способа сбора данных. Оставшиеся показатели характеризуют наблюдаемую группу и не обязательно в равной степени отражают всех посетителей.

Проанализировать изменения и выбрать метод

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

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

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

В случае одностраничного приложения тебе следует определить, хочешь ли ты анализировать навигацию по документам или переходы по внутренним маршрутам. Для отдельного учета Мягкая навигация При наличии соответствующей поддержки в браузере, начиная с версии 6, поддерживает опцию reportSoftNavs: true. Её необходимо установить в соответствующих обратных вызовах метрик. В приведённом выше примере для консоли без этой опции отдельное измерение маршрута не активируется.

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

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