FrontendConf

Представим, что в вашей компании нет культуры работы над клиентским перформансом и о такой задаче не говорят на уровне C-level. Что нужно сделать, чтобы она появилась? — Замедлить сервис.

Допустим, теперь задача и команда появились, но как узнать что они должны делать? — Специально замедлить сервис.

А как замедлять? А насколько замедлять? А что замедлять? Тот же Web Vitals состоит из нескольких метрик, и целенаправленное ухудшение каждой из них — это отдельная техническая задача. Должно ли это быть смещение всего распределения на константу или новая случайная величина?

В своем докладе я дам ответы на эти вопросы и расскажу о других предпосылках для таких замедлений:
* оценка влияния скорости на продуктовые метрики;
* внедрение практик по недеградации пользовательской скорости, результаты которых выражаются продуктово;
* корректировка и валидация точности инструментов для обнаружения деградаций;
* тестирование метрик скорости при замедлении элемента, не влияющего на составляющие Web Vitals
(спойлер: деньги потеряем, а метрике будет хорошо).

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