Performance-бюджеты для SaaS-дашбордов: что измерять и как держать

На большинстве SaaS-дашбордов производительность деградирует постепенно. Никто не выпускает «давайте сделаем медленнее в полтора раза», но через год именно это и получается. Бюджеты - единственный способ это остановить. Расскажем, как мы их вводим.

Что измеряем

• LCP (Largest Contentful Paint) - целимся в <2.5s на p75.
• INP (Interaction to Next Paint) - заменил FID как core-метрику в 2024-м, целимся в <200 мс.
• CLS (Cumulative Layout Shift) - <0.1 на p75.
• TTI (Time to Interactive) - особенно важен для дашбордов с тяжёлой клиентской логикой.
• Кастомные: время до отрисовки первого графика, время до открытия модалки, время до отправки формы.

Бюджеты, которые мы ставим

• JavaScript bundle на главную: 250 КБ gzipped (старт), 350 КБ (потолок).
• CSS: 50 КБ gzipped.
• Картинки на первый экран: суммарно 200 КБ.
• Шрифты: один основной + один моно = 80 КБ.
• Третьесторонние скрипты: жёсткий лимит, перечень утверждается.

Где собираем метрики

Synthetic

Lighthouse CI на каждом PR против основных страниц. Падающий бюджет - красный билд. Это ловит регрессии до прода.

Real User Monitoring

Web Vitals из window.performance, отправка в Sentry или собственный сборщик. Это даёт реальную картину по сегментам пользователей (география, устройство, тарифный план).

Процесс на проекте

1. В первый месяц - измеряем без бюджета, собираем baseline.
2. Ставим бюджет на p75 текущих значений + 10%.
3. Раз в две недели проверяем тренд. Если ушли вверх на 5% - разбираем причину.
4. Раз в квартал - пересмотр: бюджет либо ужесточаем, либо честно расширяем (если фича оправдывает).

Что обычно ломает бюджет

• Новая аналитика/маркетинг-скрипт. Каждый из них - 30–80 КБ JS.
• Глобальная библиотека типа moment.js (используйте date-fns или native).
• Большие иконсеты, импортированные целиком вместо нужных файлов.
• Шрифты с несколькими начертаниями без subset.
• Регрессии в Tree-shaking после обновления тяжёлой UI-библиотеки.