Оптимизация каталога в Битрикс: что проверять на ревью

Каталог на 1С-Битрикс может начать отдавать 502 уже после добавления фильтра, торговых предложений или сортировки по цене. На ревью проверяйте не отдельные вызовы, а цепочку целиком: запрос к инфоблоку, загрузку свойств, связь с SKU, построение фасетного фильтра, кеш и рендеринг. Ниже — разбор для актуальной ветки 1С-Битрикс: Управление сайтом 24.x; перед проверкой зафиксируйте версию ядра, PHP, СУБД и объём каталога.

Сначала зафиксируйте симптом и границы проверки

Ревью каталога без замеров быстро превращается в спор о стиле кода. Сначала запишите, где именно возникает задержка: открытие раздела, фильтр, сортировка, карточка товара, поиск или добавление в корзину.

• Снимите время ответа без кеша и с кешем.
• Укажите размер выборки: число товаров, торговых предложений и значений свойств.
• Зафиксируйте сценарий: URL, параметры фильтра, сортировка, пользовательская группа.
• Проверьте пиковый режим отдельно: параллельные запросы, очистка кеша, импорт остатков.
• Сохраните SQL-профиль и план выполнения для самых дорогих запросов.

Если проект использует PHP 8.1 или 8.2, это тоже должно попасть в отчёт: поведение расширений, драйвера базы и кеша нельзя оценивать по копии с другой конфигурацией.

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

Что проверять в цепочке запроса

1. Выборка товаров

Ищите запросы, которые получают товар без ограниченного списка полей. Для списка обычно не нужны полное описание, все изображения, SEO-поля и десятки свойств. Если они загружаются на каждом элементе, задержка растёт вместе с количеством товаров на странице.

Формулировка замечания на ревью должна быть конкретной: «В списке из 24 товаров загружаются свойства, которые не участвуют в шаблоне; оставить только поля, используемые для цены, ссылки, названия и изображения». Такую претензию можно проверить повторным профилированием.

Отдельно проверьте постраничную навигацию. Получение всех товаров с последующим разбиением в PHP опаснее, чем запрос с ограничением на стороне СУБД: память и время ответа начинают зависеть от всего раздела.

2. Свойства инфоблока

Свойства — частый источник скрытой стоимости. На одном экране могут одновременно использоваться характеристики, фильтры, сортировка, SEO-данные и служебные значения. Проверьте, какие из них действительно нужны в текущем сценарии и не запрашиваются ли они повторно.

Особенно внимательно смотрите на множественные свойства, файлы и привязки к элементам. Они могут приводить к дополнительным обращениям к базе или к загрузке больших наборов данных, хотя пользователь видит только одно значение.

Не принимайте решение «перенести всё в отдельную таблицу» без замера. Для Битрикс важны не только объём данных, но и используемый механизм выборки, индексы и совместимость с компонентами.

3. Торговые предложения и цены

В каталоге с SKU карточка товара и предложение — разные уровни данных. На ревью проверьте, не загружаются ли все предложения для каждого товара, когда странице нужен только один доступный вариант или минимальная цена.

Типичный дефект выглядит так: список из 30 товаров вызывает отдельную обработку предложений для каждого товара. Это классическая проблема N+1^[1]. В результате число обращений растёт вместе с количеством элементов, а не остаётся примерно постоянным.

Проверьте также:

• как выбирается активное предложение;
• не учитываются ли отключённые или недоступные SKU;
• не пересчитываются ли цены несколько раз в одном запросе страницы;
• не загружаются ли все типы цен, хотя покупателю нужен один;
• не вызывается ли проверка остатков отдельно для каждой карточки.

4. Фильтр и сортировка

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

Если на проекте включён фасетный индекс, выясните, какие свойства в него попадают и когда он обновляется. Фасетный индекс^[2] ускоряет подготовку фильтра, но не делает дешёвым любой произвольный запрос. Сортировка по полю, которого нет в подходящем индексе, всё равно может потребовать большой операции сортировки.

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

Сравнение подходов к ускорению

У каждого решения есть цена. Кеш может скрыть плохой запрос, денормализация усложняет импорт, а дополнительный индекс увеличивает стоимость записи. Выбирать подход нужно после профилирования.

Что ревьюить в коде и конфигурации

Запросы внутри циклов

Любой вызов к ORM, API инфоблоков, ценам, остаткам или файлам внутри цикла должен получить отдельное объяснение. Иногда он оправдан редким административным сценарием, но для каталога это красный флаг.

Замечание лучше писать с условием и способом проверки: «Проверить количество SQL-запросов при 24 товарах и при 48; если оно растёт пропорционально числу элементов, заменить поэлементную загрузку на пакетную». Не утверждайте, что конкретный метод всегда создаёт N+1: это зависит от версии ядра, обработчиков и вызываемого компонента.

События и обработчики

Каталог может тормозить не в шаблоне. Обработчики событий при сохранении товара, цены, свойства или остатка способны запускать пересчёты, очистку кеша и внешние запросы. На ревью найдите зарегистрированные обработчики и проверьте их время выполнения на импорте.

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

Кеш и персонализация

Проверьте, какие данные попадают в кеш компонента: группа пользователя, регион, склад, валюта, тип цены и наличие. Если ключ кеша не учитывает существенный параметр, один пользователь может получить данные другого сценария.

Обратная проблема — слишком дробный кеш. Когда в ключ попадает каждый параметр, количество вариантов растёт, попадания становятся редкими, а очистка занимает больше времени. Для цены и остатков нужно отдельно определить допустимую задержку обновления.

Импорт и фоновые задачи

Импорт из 1С или другого источника нельзя оценивать только по времени одной операции. Смотрите на пакетный размер, блокировки, количество обновляемых сущностей, очистку кеша и поведение сайта во время загрузки.

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

Что ломается первым под нагрузкой

Без собственных замеров нельзя честно назвать предел каталога. Вместо выдуманного числа зафиксируйте матрицу тестов: объём товаров, число SKU, доля товаров с заполненными свойствами, параллельность, состояние кеша и длительность сценария.

Проверяйте граничные случаи:

• раздел без товаров и раздел с максимальным количеством товаров;
• товар без SKU и товар с десятками предложений;
• пустое значение свойства, несколько значений и длинный список значений;
• фильтр с нулевым результатом;
• сортировка по цене при отсутствии цены или остатка;
• очистка кеша сразу после массового импорта.

Если после очистки кеша первые запросы заметно медленнее, измеряйте прогрев отдельно. Нельзя сравнивать прогретый кеш на тестовой машине с холодным кешем после импорта на продакшене.

Когда замечание действительно нужно исправлять

Не всякий тяжёлый запрос — дефект. Редкий административный отчёт может быть медленным, если он не влияет на покупателя и запускается асинхронно. Для пользовательского каталога приоритет выше, если проблема воспроизводится на чистом кеше, растёт вместе с числом товаров или блокирует импорт.

Выносите в обязательные исправления:

• запросы и сетевые вызовы внутри циклов каталога;
• выборку всех полей и свойств без необходимости;
• кеш, который смешивает цены, остатки или данные разных пользователей;
• фильтр, работающий только на маленькой копии базы;
• очистку всего кеша после изменения одного товара без измеренной причины.

В отдельный список улучшений можно отнести редизайн структуры инфоблоков и перенос редко используемых данных. Такие изменения затрагивают импорт, админку и интеграции, поэтому их нельзя обещать как быстрый фикс.

Что делать дальше

Соберите один воспроизводимый сценарий: раздел, фильтр, сортировка, число товаров и состояние кеша. Снимите SQL-профиль, план выполнения и количество обращений к внешним сервисам. После каждого изменения повторяйте тот же сценарий и записывайте не только среднее время, но и p95 — задержку, в которую укладываются 95% запросов.

Следующим этапом настройте наблюдение за временем ответа каталога, долей ошибок 5xx, количеством SQL-запросов на страницу, hit rate кеша и длительностью импорта. Инвалидация кеша и проектирование инфоблоков — отдельные темы; здесь важно сначала доказать, какой участок цепочки действительно ограничивает каталог.

^[1] N+1 — схема, при которой один запрос получает список товаров, а затем для каждого товара выполняется ещё один или несколько запросов.

^[2] Фасетный индекс — подготовленная структура данных для быстрого построения фильтров по значениям свойств инфоблока.