Все

Как отслеживать перформанс-метрики приложения и выкатывать только позитивные изменения

2025-01-03 18:18 Статьи analytics
Привет! Меня зовут Ксения Беленя, я занимаюсь аналитикой производительности приложений и веб-страниц в Авито. Моя команда следит за перформансом приложений и не допускает раскатки A/B-тестов, которые значительно просаживают перформанс-метрики.
В этой статье я рассказываю, почему перформанс приложений — это важно, на какие метрики мы смотрим в Авито, как оцениваем и проверяем уровень производительности в A/B-тестах. Статья может быть полезна тем, кто хочет следить за перформансом своего приложения или сайта, но не уверен, что это нужно, и не знает, с чего начать.
Дисклеймер
В статье буду говорить про перформанс приложений и веб-сайтов. Это показатель, который отражает скорость и качество работы. Его оценивают с помощью разных метрик, например, объёма памяти, которую потребляет приложение, или быстроты загрузки экранов и картинок.
То, о чём буду рассказывать в статье, не относится к перформанс-маркетингу.

Перформанс-метрики веб-версии сайта

Мы в Авито выделяем две группы метрик: перформанс-метрики веб-версии сайта (в том числе user-centric показатели) и метрики приложения. Расскажу подробнее, как мы измеряем каждый из типов, начну с веба.
Обработка запросов и загрузка страницы на вебе состоит из двух частей: бэкенд и фронтенд, каждая из них включает в себя ряд этапов. Вот схема обработки запросов и загрузки страницы на вебе:
Схема обработки запросов и загрузки страницы на вебе. Мы следим за всеми этапами.
Везде, где это возможно и необходимо, мы шлём события с временными метками. Большая часть метрик — разница между началом и окончанием этапов. Некоторые метрики могут включать в себя последовательность этапов.
Показателей много, мы не можем следить за всеми. Поэтому в первую очередь обращаем внимание на user-centric метрики.
User-centric метрики не считаются как разности временных меток начала и конца этапов, браузеры умеют замерять их сами. Вот за какими показателями мы следим:
First contentful paint (FCP) — время с момента начала загрузки страницы до того, как какая-либо часть содержимого страницы отобразится на экране. Это может быть текстовый блок или картинка:
Первыми обычно отображаются тексты и другие небольшие элементы страницы.
Подробнее про метрику – в этой статье: First contentful paint (FCP).
Largest contentful paint (LCP) — время отрисовки самого большого блока на экране. У нас это чаще всего картинка — фотография товара:
Весь контент, кроме картинки, пока не загрузился и отображается серыми блоками
Подробнее про метрику – в этой статье: Largest Contentful Paint (LCP).
Cumulative layout shift (CLS) — величина сдвигов видимых элементов страницы в процессе её отрисовки. Метрика характеризует возможность неожиданного для пользователя перемещения объектов на странице.
Например, на этой гифке цена поменяла своё расположение в процессе загрузки.
Подробнее про метрику – в этой статье: Cumulative layout shift (CLS).
Time to interactive (TTI) — показывает, сколько времени прошло от начала загрузки страницы до момента, когда она становится полностью интерактивной.
Total blocking time (TBT) — общее количество времени после первой отрисовки содержимого (FCP), когда основной поток был заблокирован более чем на 50 мс.
Interaction to next paint (INP) — максимальная задержка взаимодействия пользователя со страницей за всё время жизни страницы без учёта выбросов.
Подробнее про все user-centric метрики можно почитать в этой статье: User-centric performance metrics на сайте web.dev.

Перформанс-метрики приложений

Чтобы измерить их, мы тоже логируем время, которого требуют различные этапы. Смотрим на время загрузки и отрисовки картинок (image_draw) и длительность сессии отрисовки контента (draw_session). Внутри каждого показателя есть отдельные этапы:
Маленькие этапы мы используем для отладки.
Основная метрика, на которую смотрим — длительность сессии отрисовки контента (draw_session). Она измеряется от создания экрана до полной отрисовки контента на нём. Особенность этой метрики в том, что мы замеряем её отдельно для каждого блока контента на экране.
Например, на карточке объявления можем смотреть на скорость отрисовки самого объявления и отдельно оценивать скорость загрузки блока сопутствующих товаров.
Так выглядит блок сопутствующих товаров:
Ещё одна важная метрика — количество ошибок. Мы выделяем следующие типы ошибок в приложениях:
  • фатальные ошибки — когда приложение вылетает. Мы стараемся не допускать их вообще. Если в A/B-тесте растёт количество таких ошибок — мы запрещаем катить его в прод;
  • ошибки памяти — когда приложение получает уведомление о её нехватке. На них тоже обращаем особое внимание, потому что нехватка памяти — предвестник фатальных ошибок;
  • видимые для пользователей ошибки, например, экран с текстом «Что-то пошло не так»:
  • низкоуровневые ошибки. Пользователь не видит их в интерфейсе, но они связаны с видимыми ошибками, поэтому используются для отладки;
  • на вебе мы смотрим только количество ошибок 404.
Также смотрим на здоровье скролла. Его мы оцениваем с помощью метрики hitch time ratio (HTR). Она представляет собой долю времени подвисаний при скролле, измеряется в мс/с.

Почему перформанс приложения важен

Мы давно исследуем вопрос значимости перформанса: изучаем исторические данные и проводим ухудшающие A/B-тесты. И без тестов можно понять, что из-за плохого перформанса пользователи менее охотно приходят в приложение, но наша задача тут шире.
Мы изучаем, как низкие показатели перформанса влияют на продуктовые метрики и ищем диапазоны, за которые нельзя выходить. Например, исследовали, как скорость загрузки выдачи влияет на конверсию из поиска в просмотр объявления. Результат покажу на графике ниже.
По оси X — перформанс скор поисковой выдачи. О нём мы поговорим ниже, пока для простоты давайте считать так: чем лучше скор экрана, тем быстрее он грузится.
По оси Y — конверсия из выдачи в просмотр объявления.
В результате исследования узнали: чем выше Performance score, тем вероятнее, что пользователь посмотрит хотя бы один товар из выдачи.
Помимо исследований на исторических данных, мы проводили ряд ухудшающих A/B-тестов на небольшом проценте пользователей. Ухудшения проводили на экранах карточки объявления и поисковой выдачи, платформа — Android.
Размер просадки метрик перформанса изменяли итеративно — сначала ухудшали на небольшое значение, и, если всё ещё не был заметен значимый результат на продуктовых метриках, — увеличивали просадку.
Сначала увеличили время на инициализацию (init) и отрисовку экрана (draw) на 20%, а загрузку (load) — на 40%.
В результате:
  • количество контактов (contacts) уменьшилось на 1.3%. «Контактом» мы называем ряд действий пользователя, например, нажатие кнопок «Написать» или «Позвонить», добавление в избранное;
  • общее количество просмотров объявлений (iv) уменьшилось на 1.6%;
  • количество кликов по рекламе (ads_clicks) уменьшилось на 2%.
Результаты первого ухудшающего теста:
Затем замедлили скролл на 50%. Для каждого экрана, участвующего в АБ, мы вычисляли среднюю длительность биндинга вьюшки при скролле, и затем делали Thread.sleep на эту среднюю длительность, умноженную на 0.5.
В результате:
  • общее количество buyer target click (btc) уменьшилось на 1.2%;
  • общее количество просмотров объявлений (iv) уменьшилось на 2.4%;
  • количество кликов по рекламе (ads_clicks) уменьшилось на 1.9%.
Метрика buyer target click (на скрине выше) показывает разные взаимодействия пользователей с карточкой товара. Например: добавление в избранное, нажатие на кнопку «позвонить».
В результате исследований мы подтвердили гипотезу — пользователи склонны менее активно взаимодействовать с приложением при заметных ухудшениях. Важно следить за состоянием перформанса и не допускать критичных просадок. А также стоит внимательно относиться и к небольшим просадкам, поскольку несколько тестов вместе могут довольно сильно просадить перформанс.

Performance score в Авито

Выше я рассказывала, как мы проводили исследование зависимости продуктовых метрик от перформанс скора.
Performance score в Авито — это аналог Lighthouse score от компании Google. Своеобразная «царь-метрика», которая позволяет оценить производительность экрана или страницы, не анализируя все метрики. Performance score позволяет найти экраны, ускорением которых следует заняться в первую очередь.
О том, как вычисляется Lighthouse score, можно почитать в статье на странице Chrome for Developers: Lighthouse performance scoring.
Мы считаем Performance score по тому же принципу, который используется в Lighthouse score. Порядок действий такой:
1. Считаем 75-й перцентиль значений метрик производительности. Используем именно его, потому что это уже большое количество пользователей. При этом 75-й перцентиль всё ещё достаточно чувствителен к изменениям и его проще затронуть, чем, к примеру, 95-й.
Графики с динамикой значения метрик:
2. Рассчитываем Lighthouse score для каждой метрики. Делаем это по методологии, описанной на сайте desmos.
Методология расчёта — на сайте desmos.com.
3. Считаем общий Performance score экрана как средневзвешенное скоров метрик этого экрана.
График с динамикой скоринга экрана:
В Performance score мы используем метрики:
  • FCP, LCP, TBT, CLS и INP для веба. Веса метрик берём из рекомендаций от Google.
  • draw_session и HTR для мобильных приложений. Тут веса метрик динамические: чем чаще скроллится экран, тем больший вес имеет значение метрики HTR по сравнению с draw_session.
Подробнее про наши тестирования читайте в статье моего коллеги Данилы Ленькова: «Как устроено A/B-тестирование в Авито».

Перформанс-метрики в A/B-тестах

Все перечисленные выше метрики мы считаем в каждом A/B-тесте.
Типичное распределение метрики перформанса скошено вправо, имеет длинный хвост, мода находится приблизительно в районе 25 перцентиля.
Распределение метрики draw_session:
В скоре мы используем 75-й перцентиль. Но расчёт метрик в A/B имеет свою специфику, и на данный момент мы оперируем только средними значениями, не считаем фактические значения перцентилей в контрольной и тестовой группах. Поэтому для каждой метрики мы смотрим на:
  • duration — отрезаем 99-й перцентиль, считаем среднее;
  • percent_p25, percent_p50, percent_p75, percent_p95 — доля событий, которые уложились в трешхолд, представляющий собой n-й перцентиль, посчитанный по всем данным с этого экрана за прошлую неделю. Раз в неделю по каждому экрану и каждой метрике мы считаем значения соответствующих трешхолдов.
На изображении видим, что метрика draw_session:percent_p25 просела на 8.5%. Значит, в тестовой группе в 25-й перцентиль, посчитанный за прошлую неделю по всем данным, уложилось на 8.5% меньше событий, чем в контрольной
Также в A/B мы дополнительно смотрим на метрики пользователей, у которых медленный интернет или слабое устройство. Эти показатели оценивают длинный хвост распределения. Туда попадают пользователи с медленными телефонами или те, кто живёт в регионах с плохим интернетом.
Медленные пользователи находятся в хвосте распределения:
Мы стараемся заботиться о таких пользователях и не ухудшать их перформанс ещё больше. Для этого мы считаем в тестах количество пользователей, у которых случилась хотя бы одна сессия загрузки длительнее одной, двух или трёх секунд:
Если эти метрики растут в тесте — следует разобраться с причинами.

Как мы проверяем перформанс в A/B-тестах

А теперь расскажу, как выстроен процесс проверки перформанса в A/B.
Метрики перформанса считаются в каждом тесте, который мы проводим. Все метрики группируются по степени критичности. Если в группе прокрашивается минимум одна метрика с высокой критичностью — в тесте загорается специальная плашка, которая уведомляет разработчиков теста о проблемах с перформансом.
Также уведомление приходит в наш юнит, и мы решаем, что делать дальше с этим тестом.
Если прокрасы кажутся допустимыми при данных изменениях — даём апрув, если нет — инициируем разбор этого теста с целью оптимизировать изменения и уменьшить просадки, если это возможно. Вопрос о допустимости прокраса сложный и решается в каждом тесте индивидуально экспертным мнением.
После того как команда сделала доработки, разработчики перезапускают тест, и он проходит весь процесс снова.

Вся статья в четырех пунктах:

За метриками перформанса можно и нужно следить. Мы в Авито постоянно мониторим метрики веб-версии и перформанс-метрики приложений.
Метрики перформанса могут влиять и на продуктовые показатели. К такому выводу мы пришли после проведения ухудшающих тестов.
Перформанс редко просаживается сильно сразу, обычно в одном тесте просадки небольшие. Но следует помнить, что десять тестов с небольшой просадкой в сумме дают ощутимую просадку. В итоге это может повлиять на опыт и поведение пользователей.
Чтобы оценить состояние экрана в целом, можно использовать Performance score. Это своеобразная «царь-метрика», с помощью которой мы оцениваем производительность экрана или страницы, не анализируя все метрики.
Также Performance score помогает находить экраны, ускорением которых следует заняться в первую очередь.
Надеюсь, опыт нашей команды был вам полезен. Успехов! Не забывайте заботиться о перформансе вашего приложения. И поздравляю вас с наступившим Новым годом!