Как измерить Web Vitals с помощью вашего текущего инструмента аналитики.
Возможность измерять и составлять отчеты о реальной производительности ваших страниц имеет решающее значение для диагностики и улучшения производительности с течением времени. Без полевых данных невозможно точно знать, действительно ли изменения, которые вы вносите на свой сайт, приводят к желаемым результатам.
Многие популярные поставщики аналитики Real User Monitoring (RUM) уже поддерживают метрики Core Web Vitals в своих инструментах (а также многие другие Web Vitals ). Если вы в настоящее время используете один из этих инструментов аналитики RUM, у вас есть все возможности оценить, насколько страницы вашего сайта соответствуют рекомендуемым пороговым значениям Core Web Vitals , и предотвратить регрессии в будущем.
Хотя мы рекомендуем использовать инструмент аналитики, который поддерживает метрики Core Web Vitals, если инструмент аналитики, который вы используете в настоящее время, не поддерживает их, вам не обязательно переключаться. Почти все аналитические инструменты предлагают способ определения и измерения пользовательских показателей или событий . Это означает, что вы, вероятно, можете использовать своего текущего поставщика аналитики для измерения показателей Core Web Vitals и добавления их в существующие аналитические отчеты и информационные панели.
В этом руководстве обсуждаются лучшие практики измерения показателей Core Web Vitals (или любых пользовательских показателей) с помощью стороннего или собственного инструмента аналитики. Он также может служить руководством для поставщиков аналитических услуг, желающих добавить поддержку Core Web Vitals в свои услуги.
Используйте специальные показатели или события
Как упоминалось выше, большинство инструментов аналитики позволяют измерять пользовательские данные. Если ваш инструмент аналитики поддерживает это, вы сможете измерить каждый из показателей Core Web Vitals с помощью этого механизма.
Измерение пользовательских показателей или событий с помощью аналитического инструмента обычно представляет собой трехэтапный процесс:
- Определите или зарегистрируйте специальную метрику в администраторе вашего инструмента (при необходимости). (Примечание: не все поставщики аналитики требуют предварительного определения специальных показателей.)
- Вычислите значение метрики в коде JavaScript внешнего интерфейса.
- Отправьте значение метрики на сервер аналитики, убедившись, что имя или идентификатор совпадают с тем, что было определено на шаге 1 (опять же, если необходимо) .
Инструкции по шагам 1 и 3 можно найти в документации вашего инструмента аналитики. На шаге 2 вы можете использовать библиотеку JavaScript web-vitals для вычисления значения каждой метрики Core Web Vitals.
В следующем примере кода показано, насколько легко можно отслеживать эти метрики в коде и отправлять их в службу аналитики.
import {onCLS, onFID, onLCP} from 'web-vitals';
function sendToAnalytics({name, value, id}) {
const body = JSON.stringify({name, value, id});
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onCLS(sendToAnalytics);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
Избегайте средних значений
Соблазнительно суммировать диапазон значений показателя производительности, вычислив среднее значение. На первый взгляд средние значения кажутся удобными, поскольку они представляют собой аккуратную сводку большого количества данных, но вам следует сопротивляться желанию полагаться на них для интерпретации производительности страницы.
Средние значения проблематичны , поскольку они не отражают сеанс какого-либо отдельного пользователя. Выбросы в любом диапазоне распределения могут искажать среднее значение таким образом, что это вводит в заблуждение.
Например, небольшая группа пользователей может работать в очень медленных сетях или на устройствах, значения которых приближаются к максимальному диапазону значений, но при этом не учитывается достаточное количество пользовательских сеансов, чтобы повлиять на среднее значение таким образом, чтобы предположить наличие проблемы.
По возможности полагайтесь на процентили, а не на средние значения. Процентили по распределению для данного показателя производительности лучше описывают весь спектр пользовательского опыта на вашем веб-сайте. Это позволяет вам сосредоточиться на подмножествах реального опыта, что даст вам больше понимания, чем когда-либо могло бы дать одно значение.
Убедитесь, что вы можете сообщить о распространении
После того как вы вычислили значения для каждой метрики Core Web Vitals и отправили их в свою службу аналитики с использованием настраиваемой метрики или события, следующим шагом будет создание отчета или информационной панели, отображающей собранные значения.
Чтобы убедиться, что вы соответствуете рекомендуемым пороговым значениям основных веб-показателей , вам необходимо, чтобы в отчете отображалось значение каждого показателя в 75-м процентиле.
Если ваш аналитический инструмент не предлагает квантильную отчетность в качестве встроенной функции, вы, вероятно, все равно можете получить эти данные вручную, создав отчет, в котором перечислены все значения показателей, отсортированные в порядке возрастания. После создания этого отчета результат, который составляет 75 % полного отсортированного списка всех значений в этом отчете, будет 75-м процентилем для этой метрики — и это будет так, независимо от того, как вы сегментируете свои данные ( по типу устройства, типу подключения, стране и т. д.).
Если ваш аналитический инструмент по умолчанию не обеспечивает детализацию отчетов на уровне показателей, вы, вероятно, сможете добиться того же результата, если ваш аналитический инструмент поддерживает специальные параметры . Установив уникальное значение специального параметра для каждого отдельного экземпляра отслеживаемой метрики, вы сможете создать отчет с разбивкой по отдельным экземплярам показателя, если вы включите специальный параметр в конфигурацию отчета. Поскольку каждый экземпляр будет иметь уникальное значение измерения, группировка не произойдет.
Отчет Web Vitals является примером этого метода, в котором используется Google Analytics. Код отчета имеет открытый исходный код, поэтому разработчики могут ссылаться на него как на пример методов, описанных в этом разделе.
Отправляйте свои данные в нужное время
Некоторые показатели производительности можно рассчитать после завершения загрузки страницы, тогда как другие (например, CLS) учитывают весь срок жизни страницы и становятся окончательными только после того, как страница начала выгружаться.
Однако это может быть проблематичным, поскольку события beforeunload и unload ненадежны (особенно на мобильных устройствах), и их использование не рекомендуется (поскольку они могут помешать странице получить доступ к обратному кэшу ).
Для метрик, которые отслеживают весь срок существования страницы, лучше всего отправлять текущее значение метрики во время события visibilitychange , когда состояние видимости страницы меняется на hidden . Это связано с тем, что как только состояние видимости страницы изменится на hidden , нет никакой гарантии, что какой-либо скрипт на этой странице сможет запуститься снова. Это особенно актуально для мобильных операционных систем, где само приложение браузера можно закрыть без запуска обратных вызовов страниц.
Обратите внимание, что мобильные операционные системы обычно вызывают событие visibilitychange при переключении вкладок, переключении приложений или закрытии самого приложения браузера. Они также вызывают событие visibilitychange при закрытии вкладки или переходе на новую страницу. Это делает событие visibilitychange гораздо более надежным, чем события unload или beforeunload .
Отслеживайте производительность с течением времени
После того как вы обновили свою реализацию аналитики, чтобы отслеживать и составлять отчеты по показателям Core Web Vitals, следующим шагом будет отслеживание того, как изменения на вашем сайте влияют на производительность с течением времени.
Версия ваших изменений
Наивный (и в конечном итоге ненадежный) подход к отслеживанию изменений — развернуть изменения в рабочей среде и затем предположить, что все метрики, полученные после даты развертывания, соответствуют новому сайту, а все метрики, полученные до даты развертывания, соответствуют старому сайту. Однако любое количество факторов (включая кеширование на уровне HTTP, Service Worker или CDN) может помешать этому работать.
Гораздо лучший подход — создать уникальную версию для каждого развернутого изменения, а затем отслеживать эту версию в своем инструменте аналитики. Большинство инструментов аналитики поддерживают установку версии. Если у вас нет, вы можете создать собственное измерение и установить для него развернутую версию.
Проводите эксперименты
Вы можете сделать еще один шаг вперед в управлении версиями, отслеживая несколько версий (или экспериментов) одновременно.
Если ваш инструмент аналитики позволяет определять группы экспериментов, используйте эту функцию. В противном случае вы можете использовать специальные параметры, чтобы каждое значение показателя можно было связать с определенной группой экспериментов в ваших отчетах.
Проведя эксперименты в своей аналитике, вы можете внедрить экспериментальное изменение для подмножества ваших пользователей и сравнить эффективность этого изменения с эффективностью пользователей в контрольной группе. Если вы уверены, что изменение действительно повышает производительность, вы можете распространить его на всех пользователей.
Убедитесь, что измерения не влияют на производительность
При измерении производительности реальных пользователей абсолютно важно, чтобы любой код измерения производительности, который вы используете, не влиял отрицательно на производительность вашей страницы. Если это так, то любые выводы, которые вы попытаетесь сделать о том, как ваша производительность влияет на ваш бизнес, будут ненадежными, поскольку вы никогда не узнаете, оказывает ли наличие самого аналитического кода наибольшее негативное влияние.
Всегда следуйте этим принципам при развертывании кода аналитики RUM на рабочем сайте:
Отложите свою аналитику
Код аналитики всегда следует загружать асинхронным, неблокирующим способом и, как правило, его следует загружать последним. Если вы загружаете свой аналитический код блокирующим способом, это может негативно повлиять на LCP.
Все API-интерфейсы, используемые для измерения показателей Core Web Vitals, были специально разработаны для поддержки асинхронной и отложенной загрузки сценариев (с помощью флага buffered ), поэтому нет необходимости спешить с ранней загрузкой сценариев.
Если вы измеряете метрику, которую невозможно вычислить позже на временной шкале загрузки страницы, вам следует встроить в <head> вашего документа только тот код, который необходимо запустить раньше (чтобы это не был запрос на блокировку рендеринга ). и отложить все остальное. Не загружайте всю аналитику заранее только потому, что этого требует одна метрика.
Не создавайте длинные задачи
Код аналитики часто запускается в ответ на ввод пользователя, но если ваш код аналитики выполняет множество измерений DOM или использует другие API-интерфейсы, интенсивно использующие процессор, сам код аналитики может привести к плохой реакции на ввод. Кроме того, если файл JavaScript, содержащий ваш аналитический код, имеет большой размер, выполнение этого файла может заблокировать основной поток и отрицательно повлиять на задержку первого ввода (FID) или взаимодействие со следующей отрисовкой (INP) .
Используйте неблокирующие API
Такие API, как sendBeacon() и requestIdleCallback() специально разработаны для выполнения некритических задач таким образом, чтобы не блокировать критически важные для пользователя задачи.
Эти API — отличные инструменты для использования в библиотеке аналитики RUM.
Как правило, все аналитические маяки должны отправляться с использованием API sendBeacon() (если он доступен), а весь код измерения пассивной аналитики должен запускаться в периоды простоя.
Не отслеживайте больше, чем вам нужно
Браузер предоставляет множество данных о производительности, но тот факт, что эти данные доступны, не обязательно означает, что вы должны записывать их и отправлять на свои аналитические серверы.
Например, API синхронизации ресурсов предоставляет подробные данные о времени для каждого отдельного ресурса, загруженного на вашу страницу. Однако маловероятно, что все эти данные будут обязательно или полезны для повышения производительности загрузки ресурсов.
Короче говоря, не отслеживайте данные просто потому, что они есть, убедитесь, что данные будут использоваться, прежде чем потреблять ресурсы для их отслеживания.