Метрики производительности

Обсудите это с бизнесом: какие метрики важны для клиентов

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

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

Вот общие советы, которые помогут вам сориентироваться:

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

Существует множество различных метрик, отражающих производительность вашего приложения. Вам просто нужно выбрать наиболее важные из них. Google в 2020 году предложил новую инициативу, называемую WebVitals. Это общие гайдлайны по улучшению качества сайта для ваших пользователей. Core WebVitals — подмножество WebVitals. Набор критичных по мнению Google метрик. Google учитывает эти метрики при поисковой индексации страниц. Так как инициатива относительно новая, эти метрики могут изменяться со временем. Сейчас они такие:
Точка, в которой макет стабилизировался, ключевые веб-шрифты видны и основной поток доступен для обработки пользовательского ввода. В основном это отметка времени, когда пользователь может взаимодействовать с  интерфейсом. Ключевые метрики для понимания того, сколько времени придется ждать пользователю, чтобы использовать сайт без задержек.

  • Отрисовка самого крупного элемента — (LCP).
Время отрисовки самого большого изображения или текста, видимого в текущем вьюпорте. Эта метрика показывает,  как ваши пользователи ощущают скорость загрузки страницы.

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

Показывает как часто пользователи сталкиваются с неожиданными сдвигами на странице. Отражает визуальную стабильность страницы. Меньше — лучше.
Кроме Core WebVitals есть еще несколько полезных метрик:
Показатель неинтерактивности страницы до того, как она станет интерактивной. В основном потоке не должно быть никаких задач, выполняемых более 50 мс (длинные задачи) в отрезке минимум 5 сек. Метрика измеряет общее количество времени между первой отрисовкой и временем до взаимодействия (TTI), когда основной поток был заблокирован на достаточно долгое время, чтобы предотвратить отклик на ввод. Таким образом, низкий показатель TBT — хороший показатель для производительности.

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

  • Затраченное время процессора.
Показывает, как часто и как долго основной поток блокируется, работая с отрисовкой, рендерингом, написанием сценариев и загрузкой. Если загрузка ЦП высокая, пользователь заметит задержку между своим действием и ответом. Это плохо для UX. С помощью WebPageTest вы можете выбрать «Захват временной шкалы инструментов разработчика на вкладке «Chrome», чтобы увидеть разбивку основного потока, выполняемого на любом устройстве с помощью WebPageTest.

Как и в случае с затраченным временем ЦП, этот показатель, предложенный Стояном Стефановым, исследует влияние JavaScript на ЦП. Идея в том, чтобы использовать ограниченное количество инструкций процессора для каждого компонента и понять его влияние на общий UX. Может быть реализовано с помощью Puppeteer и Chrome.

  • FrustrationIndex
Многие показатели, представленные выше, показывают, когда происходит конкретное событие. FrustrationIndex Тима Верике показывает разницу между показателями, вместо того, чтобы рассматривать их по отдельности. Он смотрит на ключевые этапы, воспринимаемые конечным пользователем (заголовок виден, первый контент виден, страница выглядит готовой) и вычисляет уровень фрустрации пользователя при загрузке страницы. Чем больше разрыв, тем больше вероятность не оправдать ожидания пользователя. Потенциально хороший KPI для пользовательского опыта. Тим опубликовал подробный пост о FrustrationIndex и о том, как это работает.

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

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

Пользовательские метрики выбираются исходя из потребностей вашего бизнеса. Это может быть идентификация пикселей, критически важные скрипты, необходимые элементы CSS и т.д. Здесь необходимо измерять, насколько быстро такие элементы доставляются пользователю. Для этого вы можете отслеживать время рендеринга героев или использовать Performance API, отмечая определенные временные метки для важных событий. Кроме того, вы можете собирать пользовательские метрики с помощью WebPagetest, выполняя произвольный JavaScript в конце теста.
В зависимости от того, как пользуются вашим приложением, приоритетные показатели могут отличаться: например, для пользовательского интерфейса Netflix TV более важны скорость реакции на ввод клавиш, использование памяти и TTI, а для Википедии более важны первые/последние визуальные изменения и показатели затраченного времени ЦП.

Будьте на 20% быстрее самого быстрого конкурента

Это значение было выявлено в ходе психофизиологических исследований Вебера и Фехнера ещё в первой половине 19 века. Эрнст Вебер выяснил и доказал, что ощущения от нового раздражителя будут отличаться от «старых» ощущений только в том случае, если интенсивность нового раздражителя будет отличаться от предыдущего не в арифметической, а в геометрической прогрессии. То есть разница должна быть не Х единиц, а 1/30 или 1/100.

Многие учёные до сих пор считают этот закон верным. Его действие распространяется и на ощущение времени. Исследования показали, что в среднем люди различают что быстрее, а что медленнее, если разница промежутков времени колеблется от 7% до 18%. Но это верно для тайминга до 30 секунд. Поэтому, чтобы не ошибиться на более длинном тайминге, лучше взять за основу правило 20% Вебера-Фехнера.

Бывают ситуации, когда разница в скорости работы приложения ощутима для пользователя, но не влияет на его предпочтения. В этом случае можно не тратить силы на то, чтобы полностью «победить» конкурента. Достаточно нейтрализовать эту разницу.

Предположим, что ваш сервис выдаёт ответ на поисковый запрос за 5 секунд, а сервис нового конкурента очень похож на ваш, обращён к той же аудитории, но ответ выдаёт за 2 секунды. В этом случае не стоит применять правило 20%.

Согласно исследованиям 2006 года, для сглаживания разницы в ощущениях между старым и новым можно использовать среднее геометрическое значение между двумя показателями (не арифметическое!). Среднее геометрическое рассчитывается по формуле √(A × B). Для значений 2 секунды и 5 секунд: √(2 × 5) ≈ 3,2

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

Изучите конкурентов. Инструменты мониторинга

Перед тем, как мониторить конкурентов, нужно изучить пользователей вашего сервиса через аналитику. Для тестирования имитируйте опыт 90-го процентиля ваших пользователей.

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

Мониторить конкурентов помогут вот эти инструменты:
Используя Page Speed ​​Insights или Page Speed ​​Insights API, можно получать данные о производительности CrUX для определенных страниц. Эти данные полезны для установки целевых показателей эффективности определённой страницы или списка товаров.

В UX Speed Calculator есть инструмент, позволяющий смоделировать и визуализировать данные. Он поможет вам показать на сколько снижается конверсия или увеличивается показатель отказов при низкой производительности.

Составьте бюджет производительности

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

Полезные материалы о бюджете производительности от smashingmagazine.com и Виталия Фридмана.
  • Start Performance Budgeting. Статья о том, как начать составление бюджета производительности, как количественно оценить влияние новых функций и с чего начать, когда вы превышаете бюджет.
  • Approach New Designs with a Performance Budget. Глава из книги «Designing for Performance. Weighing Aesthetics and Speed», L.C. Hogan. Полезные советы для дизайнеров. Автор рассказывает, как подходить к дизайну при ограниченном бюджете производительности.
  • Identifying, Auditing, and Discussing Third Parties. Руководство по настройке google-таблиц для отображения влияния сторонних скриптов на производительность с помощью карты запросов.
Калькуляторы для бюджета производительности:
Чтобы следить за текущим состоянием производительности, настройте панели мониторинга с графиками, отображающими размеры сборки. Для этого используйте панель управления SiteSpeed.io, SpeedCurve и Caliber. Еще больше инструментов можно найти на perf.rocks.

Поделитесь своими данными с коллегами

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