Performance budget: как держать скорость сайта под контролем

Скорость сайта — не «однажды оптимизировать», а дисциплина на каждый коммит. Без лимитов сайт медленно «расползается»: картинки тяжелеют, скрипты плодятся, и через год вы снова в погоне за PageSpeed. Performance budget — это система ограничений, которая не даёт сайту деградировать. Разбираем, как её построить.

Что такое performance budget

Бюджет производительности — набор жёстких лимитов для страницы:

Тип бюджета	Пример лимита	Инструмент проверки
Вес страницы	Менее 1,5 МБ (десктоп), 1 МБ (мобайл)	Lighthouse, WebPageTest
Вес JavaScript	Менее 170 КБ gzip	BundlePhobia, Lighthouse
Вес изображений	Менее 200 КБ на LCP-картинку	DevTools Network
Число запросов	Менее 40–50	DevTools, Lighthouse
Время загрузки	LCP < 2,5 c, INP < 200 мс, CLS < 0,1	CrUX, PageSpeed Insights

Главное: бюджет должен быть измеримым и автоматическим. Если лимит не проверяется машиной — его никто не соблюдает.

Как установить стартовые лимиты

1. Измерьте текущие показатели: PageSpeed Insights (полевые данные CrUX) + DevTools.
2. Возьмите «плохой» рубеж как цель №1: если LCP 4,5 с — бюджет 2,5 с.
3. Выберите 3–5 метрик, которые реально влияют на ваш продукт (не гонитесь за всеми подряд).
4. Зафиксируйте бюджет в документе и в CI — точка старта может быть неидеальной, главное, чтобы дальше только улучшалось.

Пример стартового бюджета для типового лендинга: вес ≤ 1,5 МБ, JS ≤ 170 КБ, запросов ≤ 50, LCP ≤ 2,5 с.

Автоматизация: бюджет в CI

Бюджет работает, только когда он блокирует релиз. Два основных подхода:

// 1. Lighthouse CI: пайплайн сам проверяет страницу
// lighthouseci.config.js
module.exports = {
  ci: {
    collect: { url: ['https://mysite.ru/'], numberOfRuns: 3 },
    assert: {
      assertions: {
        'categories:performance': ['warn', { minScore: 0.9 }],
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'total-byte-weight': ['error', { maxNumericValue: 1500000 }]
      }
    }
  }
};

// 2. Webpack/Vite: size-limit прямо в сборке
// размер бандла проверяется на каждом билде
size-limit 170KB

Если PR превышает бюджет — CI красный, релиз не проходит. Это ловит «ещё одну библиотеку» в момент её подключения, а не через полгода.

Полевые и лабораторные данные

• Лабораторные (Lighthouse, WebPageTest) — повторяемые, ловят регрессии в CI.
• Полевые (CrUX, Метрика) — реальные пользователи: устройства, сети, регионы. Именно по ним ранжирует Google.

Бюджеты настраивайте по обоим типам: лабораторные — для CI, полевые — для ежемесячного аудита и целей. Помните: отличный лабораторный балл при плохих полевых данных означает, что сайт быстр в лаборатории и медлен у реальных пользователей.

Что делает бюджет ценным на практике

• Ловит регрессии сразу: новая картинка на 5 МБ или тяжёлый скрипт — релиз стоп.
• Делает скорость «обсуждаемой»: в спорах «давай добавим виджет» появляется критерий — «бюджет позволяет или нет».
• Оправдывает отказ от хлама: «нет, эта библиотека не влезает в 170 КБ» — спокойный и рациональный ответ.
• Держит цель: команда знает, что скорость — требование, а не пожелание.

Что делать, если бюджет уже превышен

1. Найдите топ-5 тяжёлых ресурсов (DevTools → Network, сортировка по размеру).
2. Оптимизируйте изображения (AVIF/WebP, ресайз) — обычно 50%+ веса страницы.
3. Удалите неиспользуемый JS и CSS (аудит сборки, code splitting).
4. Вынесите тяжёлое на CDN и добавьте кэширование.
5. Снизьте бюджет до достижимого и верните его в CI.

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

Сегодня: замерьте 4 метрики, поставьте лимиты, подключите Lighthouse CI к основному репозиторию. Через месяц посмотрите на историю — сайт стал только лучше.