Каталог и фильтрация на 1С-Битрикс

Почему каталог на инфоблоках — это и благо, и головная боль

Инфоблоки в Битрикс хранят товары в таблицах b_iblock_element и b_iblock_element_property. Когда в каталоге 5 000 SKU — всё летает. Когда 80 000 — bitrix:catalog.smart.filter начинает генерировать JOIN на 6-8 таблиц свойств, и MySQL уходит в full scan. Мы проектируем каталоги, которые держат полмиллиона позиций без деградации — за счёт фасетных индексов, правильной архитектуры свойств и гибридного хранения.

Умный фильтр: штатный компонент и его пределы

bitrix:catalog.smart.filter строит форму фильтрации автоматически по свойствам инфоблока. Из коробки есть чекбоксы, радиокнопки, ползунки (range), выпадающие списки, цветовые круги и кнопки с картинками.

Но вот что приходится допиливать почти на каждом проекте:

• Подсчёт количества товаров рядом с каждым значением — без этого покупатель кликает в пустоту
• Скрытие пустых значений — «кладбище» нулевых чекбоксов убивает UX
• Ajax-применение без кнопки «Показать» — пользователь ожидает мгновенной реакции
• Сброс отдельных параметров, а не всего фильтра разом
• Сворачиваемые группы с запоминанием состояния в localStorage

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

Фасетный индекс — самое важное, что нужно знать

Вот где зарыта основная производительность. Без фасетного индекса каждый клик по фильтру — это SQL-запрос с JOIN по b_iblock_element, b_iblock_element_property, b_catalog_price и ещё паре таблиц. На 100 000 товаров такой запрос выполняется 2-4 секунды. С фасетным индексом — 30-80 мс.

Как это работает: Битрикс создаёт таблицу b_catalog_smart_filter (фасетный индекс), куда складывает предрассчитанные комбинации «раздел + свойство + значение + количество товаров». При фильтрации движок лезет в эту плоскую таблицу вместо того, чтобы собирать данные из нормализованной структуры инфоблоков.

Грабли, на которые все наступают:

• Индекс нужно создавать для каждого раздела каталога отдельно — через админку «Товары → Фасетный индекс → Создать»
• При массовом импорте (обмен с 1С, CSV-загрузка) индекс инвалидируется. Если не настроить переиндексацию через агент CIBlockCatalog::ReindexFacet или cron-задачу — фильтр начнёт показывать неверные счётчики
• Не все свойства нужны в фасете. Свойство «Внутренний артикул», по которому никто не фильтрует, только раздувает индекс
• На каталогах 300 000+ таблица фасета весит гигабайты — мониторьте размер через SHOW TABLE STATUS LIKE 'b_catalog_smart_filter'

SEO-фильтры

Стандартный фильтр генерирует ?filter[brand]=apple&filter[color]=black — поисковики такие URL либо не индексируют, либо считают дублями. А запрос «ноутбуки apple чёрные» — это самый конверсионный низкочастотный трафик.

Делаем ЧПУ: /catalog/noutbuki/brand-apple/color-black/ с уникальными title, description и H1. Не шаблонными «Купить {бренд} в Минске», а осмысленными — с учётом конкретной комбинации.

Важные нюансы:

• Канонические URL — чтобы /brand-apple/color-black/ и /color-black/brand-apple/ не дублировались
• Контроль количества индексируемых комбинаций — 10 свойств по 20 значений дают миллионы страниц, Яндекс за такое бьёт фильтром
• Автоматическая sitemap для SEO-страниц фильтрации
• Административный интерфейс для менеджера — он сам решает, какие пересечения индексировать

Инфоблоки vs Highload-блоки

На практике лучшая архитектура — гибридная. Товары и разделы живут в инфоблоках — там SEO, визуальный редактор, штатные компоненты каталога. А вот справочные свойства (бренды, города, размерные сетки) с тысячами значений переносим в Highload-блоки. HLB работают с отдельными таблицами напрямую, без overhead b_iblock_element_property.

Когда точно пора на HLB: справочник «Города» перевалил за 5 000 значений, и выпадающий список в карточке товара грузится 8 секунд. Или свойство «Размер» для обувного каталога — 200 значений, которые дёргаются на каждой странице.

Пользовательские данные (избранное, просмотренные, сравнение) — тоже в Highload-блоки. Они быстро растут, и инфоблоки под это не заточены.

Мультикатегории

Товар в Битрикс может принадлежать нескольким разделам одновременно. Рюкзак — и в «Туристическом снаряжении», и в «Подарках для мужчин». Привязка через дополнительные разделы без физического дублирования элемента. Главное — настроить канонические URL, чтобы поисковик не воспринял один товар в трёх разделах как три дубля.

Быстрый просмотр и сортировки

Быстрый просмотр — AJAX-модалка с фото, ценой, наличием и кнопкой «В корзину». Предзагрузка при наведении курсора даёт ощущение мгновенного отклика. На мобильных — bottom sheet вместо попапа.

Сортировки из коробки: цена, популярность, рейтинг, новизна, название, наличие. Для акционных разделов добавляем сортировку по размеру скидки, для B2B-каталогов — табличный вид с техническими параметрами. Предпочтения сохраняем в cookie между сессиями.

Производительность

• Выборка только нужных полей через arSelect — никаких SELECT * по инфоблокам
• Управляемый кэш с тегами: добавили товар — кэш пересоздался автоматически
• Композитный кэш для анонимов — TTFB < 100 мс, HTML отдаётся без запуска PHP
• Индексы на свойствах, участвующих в фильтрации — без них MySQL сканирует b_iblock_element_property целиком
• Мониторинг TTFB: если каталог отвечает дольше 500 мс — лезем в slow query log

Сроки реализации

Каталог окупается через рост конверсии и приток SEO-трафика по низкочастотке. Но главное — покупатель находит товар за два клика, а не уходит после первого тычка в фильтр.