Свежий магазин после запуска летает: страницы открываются мгновенно, метрики зелёные, все довольны. Проходит год — добавили чат, три пикселя аналитики, слайдер на главной, пару тяжёлых компонентов в карточку, — и вот каталог грузится три секунды, а никто не может назвать момент, когда именно всё сломалось. Производительность деградирует не разом, а по чуть-чуть, и без явных пределов эту деградацию невозможно заметить вовремя.
Бюджет производительности — это инструмент, который делает скорость управляемой величиной. В статье разберём, что включить в такой бюджет для интернет-магазина на 1С-Битрикс, как задать реалистичные пределы и, главное, как удержать их годами через композит, кэш и автоматический контроль. Системно скорость мы поднимаем в рамках аудита и оптимизации.
Коротко
- Бюджет производительности — это конкретные пределы на метрики: вес страницы, LCP/INP/CLS, число запросов к базе.
- Строят бюджет на ключевых страницах: каталог, карточка товара, корзина.
- Держать бюджет помогают композитный сайт, кэширование и контроль числа запросов к базе.
- Без автоматической проверки в CI/CD бюджет живёт пару месяцев, потом сайт снова деградирует.
Зачем магазину бюджет производительности
Скорость сайта — это деньги: она напрямую влияет на конверсию, поведенческие факторы и позиции в поиске через Core Web Vitals. Но «сайт должен быть быстрым» — не задача, а пожелание, которое невозможно ни проверить, ни защитить. Как только на витрину начинают добавлять новые функции, скорость становится разменной монетой: каждый согласен «немного» замедлить сайт ради своей фичи, и в сумме это убивает производительность.
Бюджет производительности переводит скорость на язык цифр и правил. Он говорит: страница каталога не тяжелее такого-то веса, LCP не хуже такого-то значения, запросов к базе не больше стольких. Теперь у скорости есть владелец-цифра, а любое ухудшение — это не «показалось», а измеримая регрессия, которую видно и можно откатить.
Что такое performance budget
Performance budget — это набор количественных пределов на характеристики сайта, за которые нельзя выходить. По аналогии с финансовым бюджетом: у вас есть «лимит трат» на вес страницы, время загрузки и нагрузку на сервер, и всё, что сверх лимита, требует либо оптимизации, либо осознанного решения.
Бюджеты бывают трёх типов, и хороший магазин использует все:
- Бюджеты по метрикам скорости. LCP, INP, CLS, TTFB — что чувствует пользователь.
- Бюджеты по объёму. Вес страницы, размер JS и CSS, число запросов, вес изображений.
- Бюджеты по правилам. Например, «не подключать блокирующий сторонний скрипт», «изображения только в WebP».
Смысл не в том, чтобы иметь красивую таблицу, а в том, чтобы эти пределы автоматически проверялись и защищали сайт от постепенного «ожирения».
Какие метрики включить
Для интернет-магазина базовый набор метрик выглядит так. Он покрывает и то, что видит пользователь, и то, что происходит на сервере.
| Метрика | Что показывает | Ориентир |
|---|---|---|
| LCP | Отрисовка основного контента | Хорошо — до 2,5 с |
| INP | Отзывчивость на действия | Хорошо — до 200 мс |
| CLS | Стабильность вёрстки | Хорошо — до 0,1 |
| TTFB | Время ответа сервера | Чем ниже, тем лучше |
| Вес JS | Объём скриптов страницы | Жёсткий предел на страницу |
| Запросы к БД | Нагрузка на базу | Предел на тип страницы |
Значения-ориентиры для Core Web Vitals общеизвестны, а вот пределы по весу и числу запросов к базе задают под конкретный проект. Внутренние метрики Битрикса (число запросов, время выполнения, попадания в кэш) видны в панели производительности и логах — именно на них удобно строить серверную часть бюджета.
Как задать реалистичные пределы
Бюджет, взятый с потолка, либо не выполняется, либо не защищает. Реалистичные пределы задают от текущего состояния и целей.
- Измерьте текущее. Снимите метрики ключевых страниц на реальных данных и устройствах.
- Определите цель. Куда хотите прийти — например, зелёные Core Web Vitals на каталоге.
- Задайте предел чуть жёстче текущего. Бюджет должен не давать ухудшаться и подталкивать к улучшению.
- Разбейте по типам страниц. У каталога, карточки и корзины разные бюджеты — не усредняйте.
- Согласуйте с командой. Бюджет работает, только если его приняли разработка, бизнес и SEO.
Ключевые страницы: каталог, карточка, корзина
Бюджет не нужно вешать на каждую страницу сайта — достаточно тех, что определяют деньги и трафик. В магазине это три типа.
- Список каталога. Самая посещаемая и самая тяжёлая страница: много карточек, изображений, фильтр. Здесь бюджет строже всего.
- Карточка товара. Точка принятия решения о покупке; тяжелеет из-за галерей, отзывов, блоков «с этим покупают».
- Корзина и оформление. Динамические, критичные для конверсии страницы, где важна отзывчивость (INP).
Для каждого типа задают свой набор пределов. Карточке простительно чуть больше веса из-за галереи, каталогу — нет из-за множества элементов. Такой сфокусированный подход даёт максимум эффекта при минимуме усилий.
Композитный сайт и кэширование
Главный инструмент удержания бюджета по скорости в 1С-Битрикс — композитный сайт. Он разделяет страницу на статическую часть, которая отдаётся мгновенно из готового кэша, и динамические блоки (корзина, цена клиента, наличие), которые догружаются отдельно. Пользователь получает почти готовый HTML сразу, что резко улучшает LCP и TTFB.
Композит работает в связке с многоуровневым кэшированием Битрикса: кэш компонентов, HTML-кэш, управляемый кэш данных. Правильно настроенный кэш снимает с базы основную нагрузку и держит серверную часть бюджета. Тонкая настройка кэша и композита тесно связана с инфраструктурой — этой теме посвящена статья про хостинг и инфраструктуру на BitrixVM, где отдача статики и кэш выходят на первый план.
Запросы к базе и серверное время
Пользователь видит скорость, но её корни часто на сервере. Одна из самых частых причин медленного каталога — избыточные запросы к базе: компонент в цикле дёргает базу на каждый товар, свойства подгружаются по одному, отсутствует кэширование выборок. На большом каталоге это превращается в сотни запросов на одну страницу.
Поэтому в серверную часть бюджета включают предел на число запросов к базе на тип страницы и время их выполнения. Держать этот предел помогает грамотная работа со слоем данных: батчевые выборки вместо запросов в цикле, кэширование результатов, использование современного ORM. Подробно правильный доступ к данным мы разбираем в статье про D7 ORM в Битрикс — именно на этом уровне чаще всего и проседает или, наоборот, держится бюджет.
Вес фронтенда: JS, CSS, изображения
Фронтенд — вторая половина бюджета и обычно самый быстрорастущий его расход. Каждая маркетинговая интеграция, каждый новый скрипт и виджет добавляют вес, и без явного лимита фронтенд «толстеет» незаметно.
- JavaScript. Самый дорогой ресурс: его надо не только скачать, но и распарсить и выполнить. Предел на вес JS — обязательная часть бюджета.
- CSS. Критичный CSS инлайнят, остальное грузят отложенно, чтобы не блокировать отрисовку.
- Изображения. Главный вес каталога; их держат в узде через ресайз, WebP и ленивую загрузку.
- Сторонние скрипты. Аналитика, чаты, пиксели — источник неконтролируемого роста, их подключают асинхронно и ревизуют.
Отдельное правило бюджета — контроль сторонних скриптов: любой новый внешний код проходит проверку на влияние на метрики, иначе именно он незаметно съедает весь запас скорости.
Контроль бюджета в CI/CD
Бюджет, который никто не проверяет автоматически, живёт пару месяцев после запуска, а потом умирает под напором новых фич. Единственный способ удержать его годами — встроить проверку в конвейер разработки, чтобы регрессию ловили до релиза, а не по жалобам пользователей.
На практике это выглядит так: при сборке прогоняются автоматические замеры ключевых страниц, и если новый код пробил предел по весу или скорости, сборка помечается как проблемная. Разработчик видит, что именно его изменение замедлило сайт, ещё до выкатки. Такой контроль естественно живёт в пайплайне — как это устроено, мы разбираем в статье про CI/CD и деплой в Битрикс.
Мониторинг в проде и алерты
Проверки в CI ловят регрессии кода, но реальную скорость определяют ещё и данные, нагрузка и поведение пользователей. Поэтому бюджет дополняют мониторингом в продакшене.
- Полевые метрики (RUM). Реальные Core Web Vitals пользователей, а не только лабораторные замеры.
- Мониторинг сервера. Время ответа, нагрузка на базу, попадания в кэш под реальным трафиком.
- Алерты на выход за бюджет. Если метрика в проде вышла за предел, команда узнаёт об этом сразу.
- Регулярный ревью. Периодический разбор трендов, чтобы поймать медленную деградацию.
Связка «проверка в CI + мониторинг в проде» закрывает обе стороны: код не приносит регрессий, а реальные проблемы под нагрузкой не остаются незамеченными.
Частые ошибки
- Бюджет только на словах. «Сайт должен быть быстрым» без цифр — не бюджет, а пожелание.
- Нет автоматической проверки. Бюджет держат в голове, и после запуска он забывается.
- Усреднение по всему сайту. Один бюджет на все страницы вместо отдельных для каталога, карточки, корзины.
- Игнор серверной части. Следят за фронтом, а сотни запросов к базе на каталоге остаются незамеченными.
- Бесконтрольные сторонние скрипты. Каждая интеграция добавляет вес без ревизии влияния на метрики.
- Нереалистичные пределы. Слишком жёсткий бюджет все игнорируют, слишком мягкий не защищает.
- Нет мониторинга в проде. Лабораторные замеры зелёные, а реальные пользователи страдают под нагрузкой.
Чек-лист внедрения
- Метрики выбраны. В бюджет включены Core Web Vitals, вес фронтенда и число запросов к базе.
- Пределы заданы. Для каталога, карточки и корзины — свои реалистичные лимиты от текущего состояния.
- Композит и кэш настроены. Статика отдаётся мгновенно, динамика догружается, база разгружена кэшем.
- Запросы к базе под контролем. Нет выборок в цикле, тяжёлые данные кэшируются.
- Фронтенд оптимизирован. JS и CSS в пределах, изображения в WebP с ленивой загрузкой.
- Контроль в CI/CD. Сборка проверяет бюджет и сигнализирует о регрессиях до релиза.
- Мониторинг в проде. Полевые метрики и серверные показатели с алертами на выход за бюджет.
Вывод
Производительность интернет-магазина деградирует незаметно, и единственная защита от этого — превратить скорость в управляемую величину с конкретными пределами. Бюджет производительности задаёт эти пределы на ключевых страницах, а композит, кэш и контроль запросов к базе помогают их держать на стороне 1С-Битрикс.
Но главное — не сам бюджет, а его автоматический контроль. Встройте проверку в CI/CD и дополните мониторингом в проде, чтобы каждая регрессия всплывала до релиза, а не через год медленной работы. Тогда магазин останется быстрым не только на старте, но и через сотни релизов.
