Почему интернет-магазин на Битрикс тормозит на каталоге

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

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

Сначала определите, что именно тормозит

Проверьте несколько сценариев отдельно:

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

Если медленно работает весь сайт, начинать нужно с PHP, базы, диска и общих обработчиков. Если задержка появляется только после включения фильтра, вероятнее проблема в свойствах, фасетном индексе или числе создаваемых комбинаций. Если сервер отвечает быстро, но страница долго отображается, проверьте JavaScript, изображения и размер DOM.

Какие показатели зафиксировать

• время ответа сервера до получения первого байта;
• полное время загрузки и объём страницы;
• число и длительность SQL-запросов;
• пиковое потребление памяти PHP;
• результат с холодным и прогретым кешем;
• нагрузку CPU, диска и базы во время запроса;
• количество товаров, SKU и доступных свойств в разделе.

Диагностику с подробным логированием безопаснее проводить на копии с близким к production объёмом данных. Включённый надолго SQL-debug сам способен создать дополнительную нагрузку.

Причина 1. Запросы выполняются внутри цикла

Типичная ошибка шаблона: для каждой карточки отдельно запрашиваются цена, остаток, изображение, раздел или пользовательское свойство. При выводе 40 товаров один дополнительный запрос превращается в 40, а несколько запросов — в сотни.

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

Причина 2. В выборку попадают все свойства

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

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

Причина 3. Перегружен умный фильтр

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

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

Причина 4. Торговые предложения спроектированы неправильно

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

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

Причина 5. Кеш настроен неправильно

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

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

Причина 6. Изображения обрабатываются при каждом открытии

Если миниатюры создаются синхронно во время запроса, после очистки кеша каталог может надолго зависнуть. Размеры изображений лучше подготовить заранее, результаты ресайза кешировать, а исходники ограничить по разрешению и весу. Для современных браузеров полезны WebP или AVIF, но обязательно с корректной генерацией и резервным форматом.

Причина 7. Сервер не соответствует нагрузке

Даже хороший код будет медленным при нехватке памяти, медленном диске, постоянном swap или неверных настройках PHP-FPM и базы. Но перенос на более мощный VPS без устранения запросов в цикле лишь временно отложит проблему.

Порядок диагностики каталога

1. зафиксировать время пяти типовых пользовательских сценариев;
2. разделить серверную и клиентскую задержку;
3. проверить SQL-запросы и данные, получаемые компонентом;
4. поочерёдно проверить свойства, фильтр, SKU, цены и остатки;
5. устранить запросы в цикле и лишние вычисления;
6. после этого настроить кеш и адресную инвалидацию;
7. повторить те же измерения до и после изменений.

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