Привет! Меня зовут Ксения Беленя, я занимаюсь аналитикой производительности приложений и веб-страниц в Авито. Моя команда следит за перформансом приложений и не допускает раскатки 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 перцентиля. 

В скоре мы используем 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 помогает находить экраны, ускорением которых следует заняться в первую очередь.

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