Каталог на десять товаров летает у кого угодно. Проблемы начинаются, когда позиций становятся тысячи: раздел открывается на несколько секунд, фильтр «задумывается» после каждого клика, а на мобильном пользователь успевает уйти раньше, чем прогрузятся картинки. И почти всегда владелец делает неверный вывод — «Битрикс тяжёлый». На деле медленный каталог — это почти всегда отсутствие кэширования и неоптимальные запросы, а не вина платформы.
Разберём по шагам, как ускорить большой каталог на 1С-Битрикс: с чего начать диагностику, как настроить кэш компонентов и композитный сайт, что делать с умным фильтром, запросами, пагинацией и изображениями. Всё — на штатных механизмах платформы, а системную оптимизацию закрывает услуга аудита и оптимизации 1С.
Коротко
- Медленный каталог — это чаще всего отсутствие кэша и тяжёлые запросы, а не «тяжёлая платформа».
- База ускорения — кэш компонентов и композитный сайт: страница отдаётся почти мгновенно.
- Умный фильтр ускоряется фасетным индексом и кэшированием, база — правильными индексами.
- Начинайте с диагностики монитором производительности, а не с внедрения «всех советов сразу».
Почему тормозит большой каталог
Чтобы ускорять осознанно, надо понимать, куда уходит время при открытии раздела. Каждый заход без кэша запускает цепочку тяжёлой работы:
- Выборка товаров. Список позиций раздела запрашивается из базы с фильтрами и сортировкой.
- Цены и наличие. Для каждого товара считаются цена по группе клиента и остаток из торгового каталога.
- Умный фильтр. Считаются доступные значения свойств и количество товаров под каждым.
- Отрисовка. Десятки карточек с изображениями рендерятся в браузере.
Если всё это выполняется заново при каждом заходе, база и PHP работают на пределе, а пользователь ждёт. Ускорение — это, по сути, «не делать заново то, что можно взять готовым».
Сначала диагностика, потом лечение
Главная ошибка при ускорении — хвататься за все советы разом, не понимая, что именно тормозит. У одного проекта узкое место — фильтр, у другого — картинки, у третьего — база или хостинг. Поэтому начинают с измерения.
После диагностики становится ясен порядок действий: обычно сначала кэш и композит, затем фильтр и запросы, потом изображения и инфраструктура. Дальше разберём каждый уровень.
Кэширование компонентов каталога
Кэширование — фундамент скорости в 1С-Битрикс. Компоненты каталога (список раздела, фильтр, меню) умеют кэшировать результат своей работы: собранный список товаров сохраняется и при следующих заходах отдаётся из кэша, а не пересчитывается.
Ключевой момент — тегированный кэш. Он сбрасывается не по таймеру, а при изменении конкретных товаров: обновился товар обменом из 1С — сбросился только кэш, где он участвует. Это даёт и скорость, и актуальность: страницы отдаются из кэша, но данные не устаревают. Для большого каталога кэширование компонентов часто даёт самый заметный прирост при минимуме усилий.
Композитный сайт для раздела
Композитный сайт — следующий уровень ускорения. Он делит страницу на две части: статическую (карточки товаров, фильтр, разметка), которая кэшируется целиком и отдаётся почти мгновенно, и динамическую (корзина, цена авторизованного клиента), которая догружается отдельным AJAX-запросом.
Для каталога это означает, что пользователь видит товары практически сразу, а персональные данные подтягиваются следом, не задерживая отрисовку. Как устроен композит и на чём он работает, мы подробнее разбираем в контексте общей архитектуры — вместе с хостингом и инфраструктурой для 1С-Битрикс, потому что скорость каталога держится и на серверной базе.
Умный фильтр и фасетный индекс
Умный фильтр (catalog.smart.filter) — одно из самых тяжёлых мест большого каталога. При каждом запросе он считает, какие значения свойств доступны и сколько товаров под каждым, чтобы показывать корректные счётчики и отсекать пустые варианты. На каталоге с тысячами товаров и десятками свойств это дорого.
Решение — фасетный индекс: специальная таблица, где заранее посчитаны связки «свойство — значение — товары». Фильтр берёт готовые данные из индекса вместо запросов к каталогу на лету. Плюс кэширование самого компонента фильтра. Вместе это превращает «задумчивый» фильтр в мгновенный.
- Включите фасетный индекс для свойств, участвующих в фильтре.
- Кэшируйте компонент фильтра с тегированием.
- Не выводите в фильтр лишние свойства — каждое добавляет нагрузку.
Оптимизация запросов и индексы базы
Когда кэш и фильтр настроены, следующий уровень — сама база. Медленные запросы к каталогу часто упираются в отсутствие индексов на полях, по которым идёт выборка и сортировка, или в неоптимальную работу со свойствами инфоблоков.
Здесь помогает современный подход к данным: ядро D7 и ORM позволяют строить эффективные запросы с явными связями и выборкой только нужных полей вместо тяжёлых универсальных методов. Подробно об этом — в статье про D7 и ORM в 1С-Битрикс. Если каталог использует свои таблицы и логику, её выносят в отдельный модуль — как в материале про разработку своего модуля для 1С-Битрикс.
Пагинация и подгрузка товаров
Сколько товаров показывать на странице раздела — вопрос и удобства, и скорости. Вывод сотен позиций разом замедляет всё: генерацию на сервере, передачу, отрисовку в браузере и загрузку изображений. Разумный размер страницы — 24–48 товаров.
| Способ | Плюсы | Когда использовать |
|---|---|---|
| Классическая пагинация | Предсказуемо, дружит с SEO | Каталоги, где важна индексация страниц |
| Кнопка «Показать ещё» | Меньше кликов, контроль пользователя | Средние разделы |
| Бесконечная прокрутка | Плавный просмотр | Мобильные витрины, но осторожно с SEO |
Для больших каталогов чаще выбирают пагинацию или «Показать ещё»: они дружат с индексацией и не заставляют браузер держать в памяти тысячи карточек одновременно.
Изображения: WebP и ленивая загрузка
В разделе каталога десятки изображений товаров, и они часто — главный тормоз фронтенда, особенно на мобильном. Оптимизация картинок нередко даёт больше видимого ускорения, чем правки на сервере.
- Формат WebP. Заметно легче JPEG при том же качестве.
- Превью нужного размера. Генерируйте миниатюры под сетку каталога, а не отдавайте полноразмерные фото.
- Ленивая загрузка. loading="lazy" грузит картинки по мере прокрутки, а не все сразу.
- Адаптивные размеры. Разные изображения под десктоп и мобильный через srcset.
Наличие и цены без потери скорости
Наличие и цена по группе клиента — динамические данные, и их легко превратить в тормоз, если считать для каждого товара при каждом заходе. Но именно они должны быть актуальными, поэтому баланс важен.
Решение — вынести персональные данные в динамическую часть композита: статический список товаров отдаётся из кэша, а цена клиента и актуальный остаток подгружаются отдельным запросом. Остатки приходят из 1С обменом, поэтому их корректность и своевременность зависят от автоматизации продаж и склада на 1С. Так каталог остаётся и быстрым, и правдивым по наличию.
Инфраструктура и кэш-хранилища
Когда приложение оптимизировано, дальнейший потолок скорости задаёт инфраструктура. Для большого каталога важны быстрые кэш-хранилища и адекватные ресурсы сервера.
- Кэш в памяти. Хранение кэша в быстром хранилище (например, в оперативной памяти через соответствующий бэкенд) вместо файлов на диске.
- Настроенное веб-окружение. Актуальные версии PHP и настройки под нагрузку.
- Ресурсы под пики. Достаточно памяти и процессора, а при большой нагрузке — масштабирование.
Инфраструктурную сторону мы подробно разбираем в статье про хостинг и инфраструктуру для 1С-Битрикс: без адекватного сервера даже идеально оптимизированный каталог упрётся в потолок.
Частые ошибки
- Кэш выключен «чтобы данные были свежими». Тегированный кэш даёт и скорость, и актуальность — отключать его не нужно.
- Фильтр без фасетного индекса. Каждый клик по фильтру нагружает базу тяжёлыми запросами.
- Сотни товаров на странице. Раздел долго генерируется и отрисовывается.
- Тяжёлые изображения. Полноразмерные JPEG без WebP и ленивой загрузки.
- Цены и наличие в статике. Персональные данные пересчитываются на каждом заходе и ломают кэш.
- Оптимизация без диагностики. Внедряют всё подряд, не зная реального узкого места.
- Слабая инфраструктура. Оптимизированный каталог упирается в медленный диск и мало памяти.
Чек-лист ускорения
- Диагностика. Монитор производительности и профилирование выявили узкое место.
- Кэш компонентов. Список раздела и фильтр кэшируются с тегированием.
- Композитный сайт. Статика отдаётся из кэша, персональные данные догружаются.
- Фасетный индекс. Умный фильтр работает через индекс, а не запросы на лету.
- Запросы и индексы. Выборки оптимизированы, нужные поля проиндексированы.
- Пагинация. На страницу 24–48 товаров, остальное — постранично.
- Изображения. WebP, превью, ленивая загрузка, адаптивные размеры.
- Инфраструктура. Быстрый кэш-бэкенд и достаточные ресурсы сервера.
Вывод
Медленный каталог с тысячами товаров — почти всегда решаемая задача, и почти никогда причина не в «тяжёлом Битриксе». Скорость складывается из нескольких уровней: кэш компонентов и композитный сайт снимают основную нагрузку, фасетный индекс ускоряет фильтр, оптимизация запросов и индексов разгружает базу, а WebP и ленивая загрузка чинят фронтенд.
Ключ — действовать по данным: сначала измерить узкое место, потом устранять его в правильном порядке. Тогда каталог открывается за доли секунды, фильтр отвечает мгновенно, а наличие и цены остаются актуальными за счёт связки с 1С. Это и есть быстрый каталог, который не теряет покупателя на загрузке.
