Как оценивать и улучшать веб-жизненные показатели с помощью реальных пользовательских метрик

Эта статья была любезно поддержана нашими дорогими друзьями из Raygun, которые помогают разработчикам выявлять проблемы до того, как они повлияют на их клиентов, обеспечивая стандарт опыта, которого ожидают и заслуживают пользователи. Спасибо!

Как бы вы измеряли производительность? Иногда это время, которое требуется приложению от первоначального запроса до полного рендеринга. В других случаях речь идет о том, насколько быстро выполняется задача. Это также может быть время, необходимое пользователю, чтобы получить отзыв о действии. Будьте уверены, все эти определения (и другие) будут правильными при условии правильного контекста.

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

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

Производительность против воспринимаемой производительности

Возьмите этот фрагмент в качестве примера:

 const sum = new Array(1000) .fill(0) .map((el, idx) => el + idx) .reduce((sum, el) => sum + el, 0) console.log(sum)

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

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

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

Примечание . Если вы хотите узнать больше о Web-Workers и React, не стесняйтесь изучить мое доказательство концепции react-web-workers на GitHub.

Веб-виталы

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

• Первая содержательная краска (FCP)
  Время от начала загрузки до отображения содержимого на экране.
• Самая большая содержательная краска (LCP)
  Время рендеринга самого большого изображения или текстового блока видно в окне просмотра. Хороший показатель составляет менее 2,5 с для 75% загрузок страниц.
• Задержка первого ввода (FID)
  Время от момента, когда пользователь взаимодействует со страницей, до момента, когда браузер может обработать запрос.
  Хороший показатель составляет менее 100 мс для 75% загрузок страниц.
• Совокупный сдвиг макета (CLS)
  Общая сумма всех индивидуальных сдвигов макета для каждого неожиданного изменения, которое происходит в течение жизни страницы. Хороший показатель — 0,1 при 75% загрузок страниц.
• Время до интерактивности (TTI)
  Время от начала загрузки страницы до загрузки ее основных подресурсов.
• Общее время блокировки (TBT)
  Время между First Contentful Paint и Time to Interactive, когда основной поток был заблокирован (отсутствие реакции на действия пользователя).

Какой из них самый важный?

Core Web Vitals — это подмножество Web Vitals, которое, по мнению Google, оказывает наибольшее влияние на взаимодействие с конечным пользователем. По состоянию на 2022 год существует три основных веб-жизненных показателя: самая большая содержательная отрисовка (скорость), совокупное смещение макета (стабильность) и первая задержка ввода (интерактивность).

Рекомендуемая литература : Руководство разработчика по Core Web Vitals

Отчет о пользовательском опыте Chrome и реальные пользовательские показатели

Существует несколько способов тестирования Web Vitals в вашем приложении. Самый простой — открыть Chrome Devtools, перейти на вкладку Lighthouse, проверить свои настройки и создать отчет. Это называется отчетом об опыте использования Chrome (CrUX) и основан на 28-дневном среднем количестве образцов от пользователей Chrome, отвечающих определенным требованиям:

• синхронизация истории просмотров;
• нет настройки пароля синхронизации;
• включены статистические отчеты об использовании.

Но довольно сложно определить, насколько репрезентативен отчет Chrome UX о ваших собственных пользователях. Отчет служит ориентиром и может предложить хороший показатель того, что нужно улучшить на разовой основе. Вот почему очень полезно использовать инструмент Real User Monitoring (RUM), такой как Raygun. Это позволит сообщать о людях, которые фактически взаимодействовали с вашим приложением во всех браузерах в течение выделенного периода времени.

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

Мониторинг приложений

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

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

Отслеживайте тенденции и избегайте регрессий

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

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

Углубитесь и примите меры

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

Выделите необычные события

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

Подведение итогов

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

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