Контроль бюджетов производительности

Что это за сервис

Монитор бюджетов производительности для платформенной команды, фронтенд- и бэкенд-разработчиков и продакт-менеджеров. Бюджет — заявленный предел: вес бандла страницы, задержка P95 эндпоинта, показатель Core Web Vitals. Сервис хранит бюджеты, сравнивает с ними результаты проверок и показывает, какой релиз вывел показатель за предел.

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

Что он делает

Хранит бюджеты в одной таблице. Каждый бюджет связывает страницу или эндпоинт, тип показателя и допустимое значение, у бюджета есть владелец и история изменений.
Проверяет каждый деплой. Результаты Lighthouse CI, нагрузочных тестов или выборки из системы наблюдаемости записываются как проверки и сравниваются с бюджетом.
Различает предупреждение и нарушение. Приближение к пределу подсвечивается, уведомление уходит только при выходе за бюджет.
Связывает нарушение с релизом. У каждой проверки есть деплой, поэтому видно, после какой выкатки показатель ухудшился.
Даёт одну недельную сводку. Фронтенд и бэкенд в одном отчёте, продукт видит статус «в бюджете» или «нарушен» по разделам.

Нюансы и особенности

Монитор работает поверх наблюдаемости. Сбор метрик остаётся за Grafana, Datadog, Sentry Performance или Lighthouse CI. Если бюджеты проверяет сам CI и блокирует сборку, а команда одна, отдельное приложение не нужно. Панель на Filament полезна, когда бюджетов много, проверки идут из разных инструментов и нужны владельцы, история решений и сводка для продукта.
Одна модель для всех показателей. Задержку, вес и Web Vitals хранят в одной таблице с типом показателя и единицей измерения. Разные таблицы для фронтенда и бэкенда возвращают разрозненную картину.
Шум убивает доверие. Предупреждение — в пределах, например, 10% до бюджета, нарушение — выше бюджета; уведомляют только о нарушении. Шумные показатели сглаживают по нескольким замерам, а не реагируют на один выброс.
Проверки только автоматически. Ручная проверка перед релизом забывается. Результаты присылает шаг пайплайна или вебхук CI, повторная доставка не создаёт дубль.
Бюджеты пересматривают. Раз в квартал владелец подтверждает или меняет бюджет; изменение записывается с причиной. Иначе бюджеты либо устаревают, либо тихо ослабляются после каждого нарушения.
Нет данных — отдельный статус. Страница без проверок за последний период показывается как «Нет данных», а не как «в бюджете».
Продукту — без инфраструктуры. Продакт-менеджер видит статус по разделам продукта, а не показатели отдельных подов или контейнеров. Ограничение ролей действует на сервере.

Как сгенерировать через ИИ-агентов

Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному и проверяйте результат перед следующим шагом.

1. Данные и модели

Создай модели и миграции для бюджетов производительности: Target
(страница или эндпоинт, раздел продукта, сервис), Budget (цель, тип
показателя: вес бандла, P95, LCP, INP, CLS; единица, предел, доля для
предупреждения, владелец, дата следующего пересмотра), BudgetCheck
(бюджет, деплой, значение, результат: в бюджете, предупреждение,
нарушение; время), BudgetRevision (бюджет, старый и новый предел,
причина, автор). Добавь фабрики.

2. Таблица бюджетов

Сгенерируй Filament-ресурс для Budget. В таблице покажи цель, тип,
предел, последнее значение, результат цветным значком, возраст последней
проверки и владельца; фильтры по разделу, типу и результату. В карточке
выведи график проверок и историю пересмотров. Изменение предела требует
причину и пишет BudgetRevision.

Проверьте, что бюджет без проверок за неделю показан как «Нет данных».

3. Приём результатов из CI

Добавь эндпоинт для вебхука CI с проверкой подписи: он принимает
результаты Lighthouse CI или нагрузочных тестов с идентификатором деплоя,
сопоставляет их с бюджетами и сохраняет проверки идемпотентно. Результат
вычисляй по пределу и доле для предупреждения.

Отправьте один и тот же результат дважды и убедитесь, что проверка одна, а результат совпадает с ручным расчётом.

4. Уведомления и пересмотр

При результате «нарушение» отправляй уведомление владельцу бюджета
и автору деплоя со ссылкой на проверку. Сделай задачу по расписанию,
которая напоминает владельцам о бюджетах, у которых наступила дата
пересмотра.

5. Роли и сводка

Настрой роли: владельцы бюджетов и платформенная команда меняют бюджеты,
разработчики видят всё, продакт-менеджер видит только сводку по разделам
продукта. Добавь страницу недельной сводки: нарушения по разделам,
последние ухудшения с деплоями и экспорт за период.