С помощью инструментов профилирования Node.js разработчики в Яндекс Практикуме "положили" графики времени ответа сервера. Оказалось, проблема в коде, который ничего не делал, а каждый запрос исполнялся сотни миллисекунд. Расскажу, как победили эту и другие проблемы и в результате в несколько раз ускорили Практикум.

В докладе:
* ускорение загрузки страниц и времени ответа API в Практикуме;
* проблемы в производительности BFF Практикума;
* профилирование проблем с производительностью в Node.js;
* результаты профайлинга и найденные источники проблем;
* что помешало получить желаемый результат и как профилировать так, чтобы сразу получить честные данные;
* вывод, как не допускать деградации производительности BFF.

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

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

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

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

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

За свою карьеру я видел много метаморфоз разработчиков: одни уходили в DevOps, другие — в чистый бэкенд, и это нормально. Но иногда разработчик хочет и бэкенд, и девопс, да ещё чтобы всё это было связано с фронтендом. И тут на сцену выходит FrontOps. Разберём, что это за специалисты, какие задачи выполняют и зачем FrontOps нужен команде.

Производительность изменяется метриками, в этом докладе расскажу про основные и покажу, как правильно собирать их в единую картину и на них влиять:
* рассмотрим, как браузер отрисовывает страницу и что может ему мешать;
* на примере мобильной версии ВКонтакте пройдём путь от 8 секунд на отрисовку страницы до 2.5 секунд;
* разберём применяемые техники и их влияние на реальных графиках;
* обсудим принципиальную схему улучшения производительности сайта, которая применима абсолютно к любому проекту независимо от его сложности;
* посмотрим, как влияют оптимизации производительности на бизнес-метрики.

Вопрос безопасной разработки в последнее время стал как никогда актуален. Поделюсь опытом, как в Samokat.tech решали вопросы с безопасностью разработки фронтенда:
* как раньше в Samokat.tech была устроена разработка и доставка;
* какие возникли риски, как их устраняли и на какие сервисы переезжали;
* как закрыли Nexus от интернета и придумали способ обновлять пакеты. Какие инструменты пришлось написать для этого;
* как встраивали в CI-процесс автообновления с проверкой безопасности;
* какие варианты для целевого решения рассмотрели;
* почему выбрали Dependency Track;
* как внедряли Dependency Track, какие были трудности;
* какие результаты получили.

На старте у нас был монорепозиторий, 6 команд в нем, попытки релизов раз в 2 недели и постоянные блокеры.

Расскажу, как мы начали релизить эту монорепу минимум 1 раз в день, какие пути решения пытались использовать, с какими проблемами мы столкнулись при внедрении TBD и как масштабировали этот подход на остальные команды.

Представим обычное среднее по масштабу приложение. Тестировщики проверяют его каждый релиз. Функциональности становится больше и тестирование дорожает. Постепенно тестировщиков может стать даже больше, чем разработчиков. Кажется, что решение простое: давайте не тестировать то, что не меняется. Идея простая, но её реализация отстрелит вам оба колена. Чтобы этого не случилось, разберём на примере реального проекта, почему простые подходы не работают, как придумать сложный и причём тут архитектура.