![От метрик к оценкам: из Крайнестана
в Среднестан
18
› Значения метрик времени попадают в
интервал [0, ∞)
› Разные пользователи несопоставимы
друг с другом - их нельзя усреднять,
приходится переходить к персентилям,
что приводит к потере данных
› Разные метрики несопоставимы друг с
другом, их нельзя складывать
› Преобразование значений метрик в
оценку [0, 100] решает проблему
https://www.desmos.com/calculator/dufar5rf4g](https://image.slidesharecdn.com/mobilevelocityindexpodlodka-220217091416/85/Mobile-Velocity-Index-Data-driven-18-320.jpg)
"Mobile Velocity Index: Data-driven оптимизация времени старта" / Павел Воробкалов (Яндекс)
- 1. Павел Воробкалов Руководитель службы разработки iOS SuperApp, Яндекс Mobile Velocity Index: Data-driven оптимизация времени старта
- 2. 00 Метрики старта и с чем их едят? › Зачем оптимизировать время старта? › Как выглядит старт iOS приложения "Яндекс"? › Какие метрики старта бывают? › Способы сбора данных по метрикам старта 2
- 3. Зачем оптимизировать время старта? 3 ▎ Жалобы пользователей на загрузку приложения ▎ Все познается в сравнении (для нас - с Safari) ▎ Эксперимент с замедлением ▎ 10% ускорения старта дает ~1% Retention
- 4. Как выглядит старт iOS приложения "Яндекс" 4
- 5. Какие метрики старта бывают? 5 ▎ Time To Initial Display (TTID) › Время начальной отрисовки ▎ Time To Full Display (TTFD) › Время полной отрисовки ▎ Промежуточные стадии загрузки › Время инициализации AppDelegate › Время создания RootViewController › Время загрузки данных ▎ Метрики для различных сценариев › Cold/Warm старт › Старт по URL ▎ Пример метрик Chromium › Startup.ColdStartFromProcessCreationTime › Startup.TimeFromProcessCreationToLoad › Startup.TimeFromProcessCreationToMainCall › Startup.TimeFromProcessCreationToDidFinishLaunchingCall › Startup.TimeFromProcessCreationToSceneConnection › Startup.ColdStartWithoutExternalURLTime › Startup.ColdStartWithExternalURLTime ▎ MetricKit Framework: AppLaunchMetric › TimeToFirstDraw › ApplicationResumeTime User Gesture Launch Screen TTID TTFD Loading
- 6. Способы сбора данных по метрикам старта 6 ▎ Стендовое измерение метрик с помощью перф-тестов (XCTest + os_signpost) › Раннее обнаружение аномалий › Стабильность замеров • Необходима сборка перф-фермы • Не может охватить всех сценариев использования приложения • Результаты не всегда переносимы на реальных пользователей ▎ Сбор телеметрии от реальных пользователей (e.g. Firebase Performance Monitoring) › Полная репрезентативность › Возможность проведения A/B экспериментов • Необходимость специализированной системы аналитики • Задержка получения результатов • Сложность сравнения разных версий
- 7. 01 Основные способы оптимизации и их сайд-эффекты › Оптимизация восприятия скорости › Ленивая загрузка › Прогрессивная загрузка › Кэширование › Параллельная загрузка 7
- 9. Ленивая загрузка 9 ▎ Что можно не делать на старте - делаем когда понадобится › Обычно легко применить для изолированных компонент › Усложняется при росте количества взаимосвязей между компонентами › Может приводить к перераспределению времени между метриками ▎ Сайд-эффект › Замедляет первое использование зависимости ▎ Пример в приложении Яндекс › Ленивая загрузка WebView ускоряет старт, но замедляет открытие вкладки
- 10. Прогрессивная загрузка 10 ▎ Что-то можно не делать на старте - делаем в фоне после старта › Не замедляет первое использование зависимости › Требует управления фоновыми задачами ▎ Сайд-эффект › Деградации анимаций и скроллинга ▎ Пример в приложении Яндекс › Ядро Chromium загружается после старта в фоне
- 11. Кэширование 11 ▎ Необходимые для Full Display данные можно брать из кэша › Значительно ускоряет TTFD › Лучше использовать как fallback при медленной сети ▎ Сайд-эффект › Тяжелые IO операции на старте ▎ Пример в приложении Яндекс › Кэш карточек Дзена
- 12. Параллельная загрузка 12 ▎ Подготовка данных для Full Display в фоновых потоках › Позволяет разгрузить главный поток › Использует возможности современных процессоров › Требует управления приоритетами очередей ▎ Сайд-эффект › Возврат результата на загруженный поток может замедлить, а не ускорить ▎ Пример в приложении Яндекс › Парсинг карточек Дзена
- 13. 02 Как определить, что и когда улучшать? › Проблемы контроля метрик старта и анализа аномалий › Метрики загрузки страниц в Web › Чему мы можем научиться у Web- разработки? › От метрик к оценкам: из Крайнестана в Среднестан 13
- 14. Проблемы контроля метрик старта и анализа аномалий 14 ▎ Разнонаправленные прокрасы
- 15. Проблемы контроля метрик старта и анализа аномалий 15 ▎ Приборы как в кабине пилота
- 16. Метрики загрузки страниц в Web 16 ▎ Core Web Vitals – факторы оценки загрузки страницы, наиболее сильно влияющие на восприятие пользователя › Loading: Largest Contentful Paint › Interactivity: First Input Delay › Visual Stability: Cumulative Layout Shift ▎ Lighthouse Performance Score - инструмент стендового замера Web Vitals с возможностью вычисления интегральной оценки
- 17. Чему мы можем научиться у Web-разработки 17 ▎ Фокус на пользователя › Базовый принцип Web Vitals и Lighthouse Performance Score - рассматривать только метрики, влияющие на каждого пользователя ▎ Универсальность и измеримость › Способы измерения метрик Web Vitals стандартизованы и надежны ▎ Веса и шкалы метрик должны быть обоснованы › Метрики Web Vitals оцениваются по шкалам, основанным на UX исследованиях ▎ Возможность свертки в интегральную метрику › Метрикам сопоставлены веса, результат расчета Lighthouse Performance Score - итоговая оценка 0-100
- 18. От метрик к оценкам: из Крайнестана в Среднестан 18 › Значения метрик времени попадают в интервал [0, ∞) › Разные пользователи несопоставимы друг с другом - их нельзя усреднять, приходится переходить к персентилям, что приводит к потере данных › Разные метрики несопоставимы друг с другом, их нельзя складывать › Преобразование значений метрик в оценку [0, 100] решает проблему https://www.desmos.com/calculator/dufar5rf4g
- 19. 03 Mobile Velocity Index V1 › Метрики загрузки › Метрики интерактивности › Метрики визуальной стабильности › Расчет оценок › Практика применения MVI › С чего начать? 19
- 20. Метрики загрузки 20 › Метрики загрузки должны измеряться от наиболее близкой к инициирующему действию пользователя временной отсечки ▎ First Contentful Paint (вес 10% в Lighthouse Performance Score) › В качестве мобильного аналога FCP берется время первого отображение TTID. › Аналоги - TimeToFirstDraw в MetricKit, раздел Launch Time в XCode Organizer › Отправляем отсечку после создания RootViewController в обработчике viewDidAppear
- 21. Метрики загрузки 21 › Метрики загрузки должны измеряться от наиболее близкой к инициирующему действию пользователя временной отсечки ▎ Largest Contentful Paint (вес 25% в Lighthouse Performance Score) › В отличие от веба в мобильных нет задержки загрузки по сети, поэтому при измерении LCP аналогичным вебу способом значение метрики не будет отличаться от FCP. › Необходима ручная разметка события в приложении, когда на экране отображается наиболее важный с точки зрения UI элемент. › В приложении "Яндекс" эта точка - время отображения карточек Дзена
- 22. Метрики интерактивности 22 ▎ First Input Delay (вес 30% в proxy метрике Total Blocking Time в Lighthouse) › Total Blocking Time - аналог Hang Rate в XCode Organizer › Детектируем тап или свайп и замеряем время до следующего кадра через CADisplayLink
- 23. Метрики интерактивности 23 ▎ Time To Interactive (вес 10% в Lighthouse Performance Score) › Отслеживаем long-таски >50ms на цикле главного потока с помощью CFRunLoopObserver › Ждем достижения устойчивой интерактивности Time To Consistently Interactive, когда long-тасков на главном потоке нет в течении достаточного промежутка времени (3 секунды)
- 24. Метрики визуальной стабильности 24 ▎ Cumulative Layout Shift (вес 15% в Lighthouse Performance Score) › Метрика показывает, насколько смещаются уже показанные ранее элементы на экране, вклад элемента зависит от его размера и величины смещения › Необходимо отслеживать прямоугольники различных View в иерархии и их перемещение до первого взаимодействия с пользователем, но это может сильно ухудшить производительность › Целесообразность измерений в случае значительного влияния на производительность в мобильных приложениях под вопросом › Work In Progress
- 25. Расчет оценок 25 Mobile Velocity Index Значение в миллисекундах → балл Метрика Вес 100 95 85 70 50 25 0 Time To Initial Display 20% 0 500 1000 2000 3500 5000 10000 Time To Full Display 30% 0 500 1000 2000 3500 5000 10000 First Input Delay 30% 0 50 100 150 300 500 750 Time To Interactive 20% 0 333 900 2000 4800 14000 28000 ▎ Оценки выставляются по кусочно-линейной шкале › Основа шкалы - UX исследования восприятия времени загрузки и задержки реакции на действия
- 26. Расчет оценок 26 › value - значение метрики в миллисекундах › scoreIntervals - линейные отрезки
- 27. Практика применения MVI 27 › Среднее значение MVI позволяет учесть UX всех пользователей, а не только отдельной части аудитории при использовании персентилей › Приборные погрешности, вырождающиеся в инфиниты, дают нулевые оценки и их становится видно в оценке MVI, что позволяет раньше детектировать приборные проблемы › Изменение отдельной метрики на 10% дает изменение около 1 пункта MVI
- 28. С чего начать? 28 › Интегрируйте Analytics SDK, который позволяет собирать custom метрики › Подумайте над своими собственными Application-specific метриками › Принимайте решения в разработке на основе данных от пользователей › Попробуйте свести количество ключевых метрик к минимуму и использовать интегральные метрики a-la Mobile Velocity Index