Как держать производительность большого фронтенд-приложения под контролем?

Question

Accepted Answer

Производительность деградирует незаметно — по килобайту в каждом PR. Удержать её помогают бюджеты (размер JS на маршрут, LCP, INP) с проверкой в CI, которая блокирует превышение, мониторинг реальных пользователей (RUM) по маршрутам и устройствам с алертами, разделение кода по маршрутам и владельцы у ключевых страниц. Плюс правило: новая зависимость — с оценкой её веса. Измерять на слабых устройствах и медленной сети — там живут проблемы Отчёт о размере бандла в каждом PR (разница с main) Сторонние скрипты (аналитика, чаты, реклама) — главный источник регрессий Производительность — продуктовая метрика: связь скорости с конверсией убеждает бизнес лучше аргументов Инструменты: - бюджеты размера: size-limit, bundlesize, проверки сборщика; - лабораторные замеры: Lighthouse CI на ключевых страницах; - RUM: библиотека web-vitals с отправкой в свою аналитику или готовые сервисы, разрезы по странице, устройству, региону; - анализ бандла: визуализатор сборки, поиск дублей библиотек. Процесс: - бюджеты согласованы с продуктом и записаны; - CI сравнивает с main и блокирует превышение без обоснования; - еженедельный обзор полевых метрик, регрессии — задачи с владельцем; - сторонние скрипты — через ревью и асинхронную загрузку. Архитектурные меры: разделение по маршрутам, ленивая загрузка тяжёлых виджетов, серверный рендеринг важных страниц, контроль общих зависимостей.

Как держать производительность большого фронтенд-приложения под контролем?

Подробно

Что хотят услышать

Связанные вопросы

Подсказки на собеседовании — в реальном времени