Умный фильтр в Битрикс: четыре подхода и цена каждого

Знакомая картина: на тестовой базе из пары сотен товаров умный фильтр открывается мгновенно. После загрузки полного каталога раздел начинает думать, а в slow log MySQL появляются запросы к таблицам свойств инфоблока. Очевидное решение, увеличить кеш компонента, помогает только тем, кто выбирает одни и те же комбинации. Остальные каждый раз платят полную цену. Ниже четыре подхода к умному фильтру в «1С-Битрикс: Управление сайтом» и то, чем приходится расплачиваться за каждый.

Рамки и версии

Речь о компоненте bitrix:catalog.smart.filter в редакциях с актуальными модулями iblock и catalog. Номер версии модуля смотрите в разделе обновлений админки: от него зависят набор настроек индекса и названия пунктов меню. Фильтрацию по свойствам торговых предложений и вёрстку шаблона фильтра здесь не разбираем, это отдельные темы.

Подход 1. Стандартный компонент без фасетного индекса

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

<?php
// Шаблон раздела каталога: подключение умного фильтра.
$APPLICATION->IncludeComponent(
    'bitrix:catalog.smart.filter',
    '',
    [
        'IBLOCK_TYPE'     => 'catalog',
        'IBLOCK_ID'       => 2,            // замените на ID вашего инфоблока
        'SECTION_ID'      => $arResult['VARIABLES']['SECTION_ID'],
        'FILTER_NAME'     => 'arrFilter',  // то же имя укажите в списке товаров
        'PRICE_CODE'      => ['BASE'],
        'CACHE_TYPE'      => 'A',
        'CACHE_TIME'      => 36000000,
        'SAVE_IN_SESSION' => 'N',
        'INSTANT_RELOAD'  => 'N',
    ],
    $component
);

Список товаров, bitrix:catalog.section, должен получить такое же значение в параметре FILTER_NAME. Иначе фильтр нарисуется, но ничего не отфильтрует.

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

Подход 2. Тот же компонент с фасетным индексом

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

Фасетный индекс переносит работу с момента запроса на момент записи: вы платите при импорте и правке товаров, а не при каждом открытии раздела.

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

Цена такая:

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

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

Подход 3. Готовый модуль из Маркетплейса

Сторонние фильтры обещают ЧПУ, SEO-страницы под комбинации, быстрый AJAX, а многие строят собственный индекс. Выигрыш: меньше своей разработки, часть задач закрыта из коробки. Цена: зависимость от автора модуля, совместимость с обновлениями ядра и своя структура данных, из которой потом трудно вернуться на стандартный компонент. До покупки проверьте три вещи: как модуль ведёт себя при обмене с 1С, поддерживает ли ваши типы свойств и есть ли демо на каталоге вашего объёма.

Подход 4. Внешний поиск и свой компонент

Elasticsearch, OpenSearch или Manticore хранят товары как документы и считают фасеты на своей стороне. Битрикс остаётся витриной: движок возвращает список ID, а вы передаёте его в фильтр списка товаров.

<?php
// Схематично. $searchClient и findProductIds() - ваш код, в Битриксе их нет.
$productIds = $searchClient->findProductIds($sectionId, $selectedFacets);

// Поведение пустого массива в фильтре зависит от способа выборки,
// поэтому подставляем заведомо несуществующий ID.
$GLOBALS['arrFilter'] = ['ID' => $productIds ?: [0]];

Выигрыш: фасеты на очень больших каталогах, морфология, независимость от структуры таблиц Битрикса. Цена: ещё один сервис в проде, синхронизация индекса с инфоблоком (обработчики событий, переиндексация, обмен с 1С), свой код для ЧПУ, сортировки и пагинации. И ответственность за расхождения: товар уже скрыт в Битриксе, а в поисковом индексе ещё есть.

Сравнение

Цифр в таблице нет намеренно: скорость зависит от железа, числа свойств и объёма данных. Мерить нужно на копии своего проекта.

Когда что выбирать

• Каталог небольшой, свойств в фильтре немного, компонент не заметен в замерах: оставайтесь на подходе 1.
• Компонент фильтра занимает заметную долю времени генерации страницы или его запросы видны в slow log: включайте индекс. Это самый дешёвый шаг, начинайте с него.
• Нужны ЧПУ и посадочные под комбинации, а своих разработчиков нет: подход 3 после проверки на копии.
• Индекс включён, но фасеты всё равно упираются в базу, либо нужен поиск с морфологией вместе с фильтром: подход 4. Не раньше.

Что ломается

• Фильтр нарисован, товары не фильтруются: FILTER_NAME в фильтре и в списке разный.
• Свойство добавили в фильтр, значений нет: не пересоздан индекс или не сброшен кеш.
• Ползунок цены показывает не ту валюту: проверьте параметры конвертации валюты в компоненте.
• Страница фильтра с ЧПУ отдаёт 404: смотрите правила urlrewrite и конфигурацию веб-сервера.
• В поисковой выдаче тысячи страниц-комбинаций: заранее решите, что закрывать через canonical или noindex.
• Фильтр стал медленным после импорта: проверьте, не стал ли индекс недействительным.

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

1. На копии продакшена включите slow query log в MySQL или MariaDB и откройте самый крупный раздел каталога.
2. Снимите время выполнения страницы в разделе «Производительность» админки и запишите условия: железо, число элементов, число свойств в фильтре.
3. Включите фасетный индекс, дождитесь построения и повторите замер.
4. Прогоните обмен с 1С или типовой импорт и снова проверьте статус индекса и время ответа.
5. Если результат не устроил, переходите к подходам 3 и 4, имея на руках свои цифры, а не чужие обещания.