Как отслеживать перформанс-метрики приложения и выкатывать только позитивные изменения
Привет! Меня зовут Ксения Беленя, я занимаюсь аналитикой производительности приложений и веб-страниц в Авито. Моя команда следит за перформансом приложений и не допускает раскатки A/B-тестов, которые значительно просаживают перформанс-метрики.
В этой статье я рассказываю, почему перформанс приложений — это важно, на какие метрики мы смотрим в Авито, как оцениваем и проверяем уровень производительности в A/B-тестах. Статья может быть полезна тем, кто хочет следить за перформансом своего приложения или сайта, но не уверен, что это нужно, и не знает, с чего начать.
Перформанс-метрики веб-версии сайта
Перформанс-метрики приложений
Почему перформанс приложения важен
Performance score в Авито
Перформанс-метрики в 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 помогает находить экраны, ускорением которых следует заняться в первую очередь.
Надеюсь, опыт нашей команды был вам полезен. Успехов! Не забывайте заботиться о перформансе вашего приложения. И поздравляю вас с наступившим Новым годом!
