CI enforcement и RUM: делаем бюджеты рабочими

Команда тратит неделю, срезая homepage bundle с 900 КБ до 180 КБ. Три месяца спустя он снова 820 КБ. Никто не нарушил никакой политики. Каждый инженер делал разумно выглядящий импорт. Без CI-gate, fail’ящего PR, бюджет — аспирация — он размывается по одному PR за раз.

CI-gate: size-limit

size-limit — open-source инструмент, читающий per-route bundle targets из package.json или config-файла и fail’ящий build если любой лимит превышен. Запускается после сборки, читает gzip’d chunk sizes и завершается с не-нулевым кодом при превышении бюджета.

// package.json
"size-limit": [
  { "name": "Homepage JS", "path": ".next/static/**/_app-*.js", "limit": "100 KB" },
  { "name": "Dashboard JS", "path": ".next/static/**/dashboard-*.js", "limit": "250 KB" },
  { "name": "All pages total", "path": ".next/static/**/*.js", "limit": "500 KB" }
]

# .github/workflows/perf.yml
- name: Build
  run: bun run build
- name: Check bundle size
  run: npx size-limit
  # Fail'ит PR если любой лимит превышен

PR comment интеграция (size-limit-action) постит таблицу текущего vs бюджетного размера на каждый PR, делая эффект видимым перед мержем. Инженеры, добавляющие библиотеку, сразу видят дельту; либо обосновывают добавление (и команда явно поднимает бюджет), либо находят меньшую альтернативу.

Альтернативы: bundlewatch, Lighthouse CI

bundlewatch схож с size-limit с другим форматом конфига и GitHub check интеграцией. Lighthouse CI запускает полный Lighthouse audit на каждый PR — более комплексно, медленнее. Все три инструмента отвечают на один вопрос: «взрывает ли этот PR performance budget?»

Senior-команды используют size-limit для быстрой per-PR обратной связи (запускается за 5-10 с) и Lighthouse CI на merge в main для полного CWV snapshot.

Workflow с bundle analyzer

До того как CI может enforce бюджет, команда должна понять текущий bundle. Стандартный workflow:

1. Включить bundle analyzer: ANALYZE=true bun run build (Next.js: @next/bundle-analyzer; Vite: rollup-plugin-visualizer; Webpack: webpack-bundle-analyzer).
2. Отсортировать по размеру. Найти top 5-10 contributors.
3. Для каждого: нужен ли он на critical path этого route?
4. Типичные находки: moment.js (220 КБ, заменить на date-fns); полный lodash (80 КБ, cherry-pick); admin panel, импортированный глобально (170 КБ, lazy-load); все вариации иконок (110 КБ, cherry-pick).
5. Поставить initial budget at current size + 20% (место для роста, но не неограниченно).

RUM в production

CI ловит регрессии перед мержем. RUM ловит то, что CI пропустил в production: device-классы, работающие медленнее throttled теста, географии с медленными сетями, и медленные регрессии, накапливающиеся за многие маленькие PR, каждый в рамках бюджета.

Implementations: Web Vitals JS library (Google, бесплатно), Sentry Performance, Datadog RUM, New Relic Browser, Vercel Speed Insights, Cloudflare Web Analytics.

Senior RUM dashboard: P75 LCP per route, per device class (mobile vs desktop), per geography. Alert при P75 LCP для любого route деградирует более 20% за 24 часа.

Связывая RUM с bundle size: некоторые команды шлют gzip’d bundle size per route как custom RUM метрику рядом с LCP, так что при деградации LCP первый dashboard для проверки показывает bundle size дельту для того же деплоя. Делает корреляцию видимой без inference.

Протокол повышения бюджета

Когда PR легитимно нуждается в превышении бюджета: инженер открывает budget-raise PR. Требует sign-off от performance-owning team lead, документирует обоснование (новая фича, vendor requirement, ценность для юзера) и записывает старые и новые лимиты в perf-budgets.json. Без этого протокола бюджеты дрейфуют вверх по одному неявному approval за раз.