Битрикс фильтр в каталоге - это первое место, где нагрузка на базу становится заметна, как только магазин вырастает из демо-данных. Пока в инфоблоке пара сотен товаров, стандартный умный фильтр отрабатывает быстро и его никто не замечает. Настоящая проверка начинается на каталогах в десятки тысяч позиций с живой посещаемостью, когда каждая новая комбинация свойств заставляет модуль каталога собирать выборку заново. Дальше разбираю, чем умный фильтр отличается от самописного решения, где он упирается в потолок и в какой момент имеет смысл переходить на свой модуль.
Как устроен умный фильтр в 1С-Битрикс
Умный фильтр (компонент bitrix:catalog.smart.filter) строится поверх свойств инфоблока, отмеченных флагом «используется в фильтре». При изменении товара, цены или значения свойства модуль обновляет индекс, а при массовых изменениях запускает пересчёт по инфоблоку целиком через отложенный агент. Именно этот индекс отвечает за то, что фильтр показывает только реально доступные значения свойств для текущей выборки, а не статичный список всех вариантов из справочника.
Сверху на индекс завязана ЧПУ-логика: каждая комбинация фильтров может формировать собственный URL, по которому Битрикс восстанавливает выбранные значения без GET-параметров. Это удобно для SEO, но добавляет модулю работы, потому что при каждом заходе на «фильтрованную» страницу нужно сначала разобрать URL, потом собрать актуальный набор доступных значений, потом отдать сам список товаров.
Что происходит с фильтром под нагрузкой
Пока в инфоблоке до нескольких тысяч товаров и десяток активных свойств, всё это укладывается в разумное время ответа. Проблемы начинаются по трём направлениям одновременно.
Во-первых, пересчёт индекса. При массовом обновлении цен из 1С или через торговый обмен агент по перестроению индекса фильтра может растянуться на десятки минут, и всё это время значения свойств в фильтре отстают от фактического наличия товаров. На каталоге в 50-80 тысяч позиций с несколькими торговыми предложениями на карточку я на практике видел пересчёт, который занимал больше времени, чем окно ночной синхронизации, и к утру индекс всё ещё донагонял изменения.
Во-вторых, сам запрос выборки. Каждая новая комбинация фильтра, которую раньше никто не открывал, это холодный SQL-запрос с несколькими JOIN по таблицам свойств. Composite-кеш и обычное кеширование компонента спасают только повторные заходы на одну и ту же комбинацию, а у интернет-магазина с десятками свойств уникальных сочетаний практически бесконечное количество, и часть из них будет холодной всегда.
В‑третьих, зависимые фильтры. Если в каталоге есть числовые диапазоны (цена, вес, объём) вместе с дискретными свойствами (бренд, цвет, размер), модуль на каждый чих должен пересчитывать доступные границы диапазонов с учётом уже выбранных значений. На небольшом каталоге это незаметно, на крупном превращается в заметную часть времени ответа.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Кастомный фильтр: когда стандартного решения не хватает
Свой фильтр - это не отказ от штатного механизма целиком, а замена узкого места. Обычно проект переходит на кастомную логику не потому, что умный фильтр «не работает», а потому что его архитектура заточена под универсальный случай, а у конкретного каталога есть специфика, которую проще закрыть отдельным модулем: денормализованная таблица под конкретный набор свойств, собственный кеш с точечной инвалидацией по разделу, а не по всему инфоблоку, или расчёт диапазонов заранее, а не на каждый запрос.
На практике это выглядит так: под самые нагруженные разделы каталога делается плоская таблица, где на одну строку приходится один товар со всеми значениями свойств, участвующих в фильтре, уже развёрнутыми в колонки или в отдельный индекс. Запрос по такой таблице с точечными индексами MySQL работает без JOIN по десятку таблиц свойств и быстрее реагирует на новую комбинацию, потому что не тянет за собой универсальную логику модуля каталога.
Здесь же решается вопрос инвалидации кеша. Штатный composite-кеш сбрасывается довольно грубо, а кастомная схема чистит кеш точечно, например только для раздела, где изменилась цена или остаток, а не для всего каталога. На магазине, где обновления из 1С идут несколько раз в день, это ощутимая разница в стабильности времени ответа в рабочие часы.
Если сомневаетесь, какой объём доработки нужен именно на вашем каталоге, я беру такие задачи как доработку 1С-Битрикс с почасовой оплатой, начиная с диагностики текущего индекса и профилирования конкретных страниц фильтра.
Умный фильтр против своего: сравнение по практике
| Критерий | Умный фильтр (штатный) | Кастомный фильтр |
|---|---|---|
| Запуск | Настройка через административный интерфейс, без разработки | Проектирование структуры данных и написание отдельного модуля |
| Комфортный объём каталога | До нескольких тысяч товаров с разумным набором свойств в фильтре | Рассчитан на каталоги, где штатный индекс уже не успевает за изменениями |
| Гибкость условий (зависимые диапазоны, кросс-фильтр по нескольким разделам) | Ограничена логикой модуля catalog, часть сценариев требует обхода через API | Логика пишется под конкретный сценарий с нуля |
| Инвалидация кеша | Грубая, чаще всего по инфоблоку или разделу целиком | Точечная, можно чистить кеш только для изменившихся позиций |
| Обновление ядра Битрикса | Обновляется вместе с модулем каталога, совместимость на стороне вендора | Совместимость с обновлениями ядра и модуля каталога проверяет и поддерживает разработчик |
Стоимость поддержки в таблицу не выношу отдельной колонкой, потому что она зависит не от типа фильтра, а от почасовой ставки разработчика и объёма изменений: и доработка штатного модуля, и сопровождение самописного решения у меня идут по общей ставке за час работы.
Кеширование и индексация: куда смотреть в первую очередь
Прежде чем переписывать фильтр целиком, обычно стоит проверить более дешёвые способы вытянуть производительность из штатного механизма.
- Composite-кеш для всего сайта или хотя бы для каталога, если он ещё не включён.
- Список свойств, реально используемых в фильтре: часто там годами висят свойства, которые в интерфейсе никто не выбирает, а индекс на них пересчитывается вместе со всеми остальными.
- Расписание пересчёта индекса относительно окна синхронизации с 1С, чтобы агент не запускался поверх ещё не завершившегося обмена.
- Отдельные MySQL-индексы на таблицах свойств, если сервер БД настраивался давно и не пересматривался под текущий объём каталога.
Часто этого хватает, чтобы отодвинуть момент, когда каталог реально упирается в потолок штатного фильтра, на месяцы вперёд. Кастомное решение имеет смысл проектировать, когда эти меры уже исчерпаны, а не как первый шаг.
Что выбрать для своего проекта
Для нового магазина или каталога до нескольких тысяч позиций умный фильтр почти всегда правильный выбор: он бесплатен в разработке, обновляется вместе с ядром и закрывает подавляющее большинство сценариев из коробки. Переход на свой фильтр окупается там, где уже есть конкретная боль: измеримое время ответа страниц фильтра под нагрузкой, растянутый пересчёт индекса, который не укладывается в окно синхронизации, или бизнес-логика фильтрации, которую штатный модуль не покрывает в принципе, например фильтр по остаткам сразу нескольких складов с разными правилами доступности.
Правильная последовательность действий: сначала профилирование конкретных медленных страниц и проверка индексации, потом точечная доработка штатного механизма, и только если этого не хватает, отдельный модуль под самые нагруженные разделы каталога. Переписывать фильтр целиком на старте проекта, ещё не зная реальной нагрузки, обычно лишняя работа.
1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Сколько товаров выдерживает умный фильтр без доработок?
Жёсткой цифры нет, всё зависит от количества свойств в фильтре и от того, включён ли composite-кеш. На практике каталоги в одну-две тысячи товаров с десятком свойств работают на штатном фильтре без заметных проблем годами. Ближе к десяткам тысяч позиций и множеству торговых предложений на карточку стоит уже профилировать конкретные страницы, а не ориентироваться на общее число товаров.
Можно ли ускорить умный фильтр, не переписывая его?
Да, обычно первым делом проверяю composite-кеш, список свойств, реально задействованных в фильтре, расписание пересчёта индекса относительно синхронизации с 1С и индексы на таблицах свойств в MySQL. Эти шаги часто снимают большую часть нагрузки без разработки отдельного модуля.
Стоит ли сразу делать свой фильтр для нового проекта?
Как правило нет. На старте нагрузка неизвестна, а штатный фильтр закрывает большинство сценариев без разработки. Свой модуль имеет смысл проектировать под уже измеренную проблему на конкретном каталоге, а не заранее на всякий случай.
Что будет с фильтром при обновлении Битрикса?
Штатный умный фильтр обновляется вместе с модулем каталога, и обратная совместимость на стороне вендора. Кастомный фильтр после крупных обновлений ядра или модуля каталога стоит проверять отдельно, особенно если он завязан на внутренние таблицы или недокументированные методы API.