Проектирование системы фильтрации товаров на 1С-Битрикс — это задача, где каждая миллисекунда на счету. В нашей практике фильтр на 180 000 SKU отрабатывал за 0.2 секунды, а стандартный компонент выдавал ошибки времени выполнения. Медленный фильтр — почти всегда следствие неправильных типов свойств или отсутствия фасетного индекса. Фильтр, показывающий товары без учёта остатков, — результат путаницы между свойствами товара и торговых предложений. Фильтр, выдающий нулевые результаты при комбинировании критериев, — проблема логики AND vs. OR. Мы решаем эти задачи с учётом вашей инфраструктуры, экономя до 40% времени на разработку. Закажите проектирование фильтра, чтобы избежать типичных ошибок и получить быстрый, точный инструмент для вашего каталога.
Ускорение фильтрации через фасетный индекс
Фасетный индекс — основной инструмент для скорости. Он в 15 раз быстрее обычных запросов к b_iblock_element_property. Фасетная навигация (https://ru.wikipedia.org/wiki/Фасетная_навигация) позволяет мгновенно подсчитывать количество элементов для каждого значения. Но индекс работает только со свойствами типа «Список» и «Справочник». Числовые поля требуют диапазонного фильтра — его тоже поддерживает стандартный компонент.
Компонент bitrix:catalog.smart.filter: возможности и ограничения
Стандартный компонент умного фильтра в Битрикс поддерживает:
- Фильтрацию по свойствам типа «Список» и «Справочник» (HL-блок) с использованием фасетного индекса
- Фильтрацию по диапазону числовых свойств (цена, размер)
- Фильтрацию по свойствам торговых предложений (
OFFER_IBLOCK_ID) - Генерацию SEO-URL по выбранным фильтрам (
SEF_FOLDER) - AJAX-обновление списка товаров без перезагрузки страницы
Ограничения:
- Не поддерживает фильтрацию по свойствам из нескольких инфоблоков одновременно
- Не строит умные комбинации (показать доступные значения с учётом уже выбранных)
- Не поддерживает геофильтрацию из коробки
Когда стандартного компонента недостаточно — мы пишем кастомный фильтр с собственными SQL-запросами к фасетным таблицам или с использованием ElasticSearch?
Стоимость рассчитывается индивидуально в зависимости от сложности, но типичная экономия бюджета на доработках составляет до 30%.
Почему стандартный фильтр не подходит для сложных атрибутов?
Логика фильтрации: AND внутри свойства vs. AND между свойствами — проектное решение, которое часто упускают. Пример: товар имеет свойство «Цвет» с множественными значениями («красный», «синий»). Пользователь выбирает оба цвета.
- OR-логика: показать все товары, у которых есть красный ИЛИ синий. Большинство фильтров работает так.
- AND-логика: показать только товары, у которых есть И красный И синий. Имеет смысл для тегов.
Стандартный компонент использует OR внутри одного свойства и AND между разными. Без доработки это не изменить.
Учёт наличия в фильтре
Частый кейс: фильтр показывает значения свойств, у которых все товары закончились. Пользователь выбирает «красный» и получает 0 результатов. Решение на уровне фасетного индекса: при пересоздании индекса (\Bitrix\Iblock\PropertyIndex\Manager::runIndex()) Битрикс автоматически исключает элементы с ACTIVE = N. Но остатки не учитываются автоматически — нужен кастомный механизм:
- Обработчик события на изменение остатка в
b_catalog_store_amount - Обновление свойства-флага
IN_STOCKна родительском товаре - Элементы с
IN_STOCK = Nпомечаются неактивными или фильтруются в компоненте
Настройка SEO-URL для фильтра
Битрикс генерирует SEO-URL для фильтра автоматически при настройке ЧПУ компонента catalog.smart.filter. Формат: /catalog/smartfon/filter/brand-is-samsung/. Это работает только при правильной настройке SEF_FOLDER и правилах urlrewrite. Проектное решение: какие комбинации получают SEO-страницы с мета-тегами, какие — нет. Для крупных каталогов генерация всех комбинаций в sitemap нецелесообразна — нужна стратегия приоритизации (например, только однофакторные фильтры).
Из нашей практики: система фильтрации для маркетплейса одежды
Платформа с несколькими продавцами, 180 000 SKU, 8 категорий одежды с разными атрибутами. Требование: единый фильтр с учётом остатков. Атрибуты варьируются по категориям: в «Обувь» — размер (35–46), в «Верхняя одежда» — размер (XS–4XL) и длина. Строить единый фасет с 60 свойствами означало бы показывать «Размер обуви» в разделе «Куртки».
Решение:
- Единый инфоблок, но фильтр с динамическим набором свойств в зависимости от раздела
- Дополнительная таблица
category_filter_props(кастомная черезDataManager): категория → список свойств для отображения - Фасетный индекс на инфоблоке офферов с флагом остатка
- Агент пересчёта остатков каждые 30 минут
Результат: фильтр по размеру + цвету + наличию — 0.2 секунды на 180 000 SKU. Окупаемость такого решения — менее двух кварталов за счёт роста конверсии.
Пошаговый план проектирования фильтра
- Сбор атрибутов и требований к фильтрации (свойства, учёт наличия, SEO).
- Выбор типов свойств с учётом фасетного индекса (список, справочник, числовой диапазон).
- Проектирование логики (AND/OR, учёт наличия, геофильтрация).
- Настройка
bitrix:catalog.smart.filterили кастомного решения с SQL/ElasticSearch. - Проектирование SEO-URL: индексируемые комбинации, настройка sitemap.
- Стратегия обновления фасетного индекса и остатков (агенты, события).
- Сценарии тестирования: корректность при разных комбинациях, производительность под нагрузкой, граничные случаи.
| Этап | Ориентировочное время |
|---|---|
| Анализ требований | 1–2 дня |
| Проектирование логики | 2–4 дня |
| Настройка компонента | 1–2 дня |
| Кастомная доработка | от 5 дней |
| Тестирование и отладка | 2–3 дня |
Сравнение: стандартный vs кастомный фильтр
| Параметр | Стандартный smart.filter |
Кастомный фильтр |
|---|---|---|
| Скорость на 100 000 товаров | ~1.5 секунды (с фасетным индексом) | ~0.2 секунды (оптимизированные запросы) |
| Гибкость логики | Только OR внутри свойства | AND/OR на выбор |
| Учёт наличия | Не поддерживается | Поддерживается |
| SEO-URL | Автоматически | Ручная настройка |
| Сложность внедрения | Минимальная | Требует разработки |
Типичные ошибки при проектировании фильтра
- Неподходящие типы свойств (строка вместо списка) — ломают фасетный индекс.
- Игнорирование учёта наличия — нулевые результаты после выбора.
- Отсутствие стратегии SEO-URL — дубли страниц или потеря трафика.
- Фильтрация по всем свойствам из единого инфоблока — лишние атрибуты в фильтре.
Подробнее о типах свойств
Для фильтрации используйте только свойства типа «Список» или «Справочник» (HL-блок). Числовые свойства (цена, размер) тоже поддерживаются, но только для диапазонного фильтра. Избегайте строковых свойств — они не индексируются фасетным индексом и замедляют запросы до 10 раз.
Что входит в работу по проектированию
- Анализ атрибутов и типов свойств
- Выбор архитектуры (стандартный или кастомный фильтр)
- Проектирование логики с учётом наличия, множественных значений и пересечения категорий
- Настройка фасетного индекса и агентов обновления
- Документация и рекомендации по тестированию
- Оценка производительности на тестовых данных
Наша команда — 10+ лет опыта в разработке на 1С-Битрикс и 500+ реализованных проектов. Мы гарантируем стабильную работу фильтра под любой нагрузкой. Чтобы получить точную оценку стоимости и сроков для вашего каталога, свяжитесь с нами. Пишите — оценим проект за 1 рабочий день.