Покупатель приходит в каталог, выбирает «бренд + цвет + цену» — и ждёт. На сотне товаров это незаметно, а на каталоге в десятки тысяч позиций фильтр начинает думать по несколько секунд, посетители уходят, а вместе с ними и заказы. В 1С-Битрикс за фильтрацию отвечает умный фильтр — компонент catalog.smart.filter, который работает быстро только при одном условии: правильно построенном фасетном индексе.
Ниже — практическая настройка умного фильтра с нуля: какие свойства включать, как построить и обновлять фасетный индекс, как превратить фильтр в SEO-страницы и что делать, если он всё равно тормозит. Это выжимка из наших проектов по разработке интернет-магазинов на 1С-Битрикс — без теории ради теории.
Коротко
- Умный фильтр быстрый, потому что опирается на фасетный индекс — без него он считает всё «на лету» и тормозит.
- Фильтруемые свойства держите в типе «список» или «число», а не «строка».
- После большого обмена с 1С перестраивайте фасетный индекс — вручную или по расписанию.
- Включите кэширование компонента и популярные комбинации фильтра отдайте как ЧПУ-страницы под SEO.
Что такое умный фильтр и фасетный индекс
Умный фильтр — это штатный компонент bitrix:catalog.smart.filter, который строит панель фильтрации по свойствам инфоблока торгового каталога. Его ключевое отличие от «обычного» фильтра — поддержка фасетного индекса.
Фасетный индекс — это заранее просчитанная таблица соответствий «значение свойства → товары». Когда покупатель отмечает «синий», система не сканирует весь каталог, а берёт готовый список и тут же показывает, сколько товаров останется по каждому из оставшихся значений. Отсюда два эффекта: мгновенные счётчики у каждого пункта и отсутствие тяжёлых запросов к базе на каждый клик.
Чтобы понять, почему фасет так важен, стоит представить альтернативу. Без него каждый клик по фильтру превращается в запрос вида «выбери все товары, у которых свойство A равно X, свойство B равно Y, и заодно посчитай, сколько товаров останется по каждому из ещё не выбранных значений». На каталоге в пятьдесят тысяч позиций с десятком фильтруемых свойств это десятки тяжёлых соединений таблиц на одно нажатие. Фасетный индекс выносит всю эту арифметику в отдельную плоскую структуру, которую читать почти бесплатно.
Важно понимать, что умный фильтр — это не «волшебная кнопка ускорения», а связка из трёх вещей: правильно типизированных свойств каталога, построенного и поддерживаемого в актуальном состоянии фасетного индекса и включённого кэширования компонента. Если выпадает хотя бы одно звено, фильтр либо тормозит, либо показывает неверные счётчики, либо теряет SEO-потенциал. Дальше мы разберём каждое звено отдельно.
Архитектура умного фильтра: из чего он собран
Чтобы настраивать фильтр осознанно, полезно держать в голове его внутреннее устройство. Умный фильтр в 1С-Битрикс — это не один монолит, а несколько слоёв, каждый из которых отвечает за свою задачу.
- Свойства инфоблока. Источник данных для фильтра. Именно их типы и флаг «умной фильтрации» определяют, попадёт характеристика в фасет или нет.
- Фасетный индекс. Денормализованная таблица в базе данных, которая хранит соответствия «товар — значение свойства» в виде, удобном для быстрых пересечений.
- Компонент
catalog.smart.filter. Формирует панель фильтра, читает фасет, считает счётчики и собирает строку параметров для выборки товаров. - Компонент
catalog.section. Выводит сам список товаров по условиям, которые пришли из фильтра. - Слой кэширования. Управляемый кэш (managed cache) и тегированный кэш, которые не дают пересобирать панель и выборку на каждый запрос.
- SEO-слой. Правила ЧПУ и шаблоны метатегов, которые превращают комбинации фильтра в посадочные страницы.
Запрос покупателя проходит через эти слои по цепочке: браузер отправляет выбранные значения, компонент фильтра обращается к фасетному индексу, получает множество подходящих товаров и счётчики, передаёт условия в компонент списка, а результат кэшируется до следующего изменения данных. Понимание этой цепочки сразу подсказывает, где искать проблему: если тормозит панель фильтра — смотрим фасет и кэш фильтра, если медленно грузится список — смотрим выборку товаров и её кэш.
Фасетный индекс изнутри: как устроена таблица
Слово «индекс» здесь не про индекс СУБД в привычном смысле, а про отдельную служебную таблицу, которую Битрикс строит и поддерживает сам. Концептуально в ней для каждого товара хранятся все его значения умно-фильтруемых свойств в нормализованном виде — числовые идентификаторы значений списков, диапазоны для чисел, признаки наличия. Когда пользователь выбирает набор значений, система пересекает соответствующие множества товаров и получает результат без обращения к основным «тяжёлым» таблицам свойств.
Из устройства фасета вытекают практические следствия, о которых стоит помнить при проектировании каталога:
- Размер фасета зависит от числа свойств и значений. Чем больше умно-фильтруемых свойств и чем больше у каждого уникальных значений, тем объёмнее таблица и дольше её построение.
- Свойства-списки экономнее строк. Значение списка — это компактный идентификатор. Произвольная строка раздувает фасет и плохо группируется в счётчики.
- Цена и количество идут диапазонами. Числовые свойства фасет хранит так, чтобы быстро отвечать на запросы «от и до», поэтому бегунок цены работает мгновенно.
- Изменение товара триггерит точечное обновление. При правке одной позиции через интерфейс пересчитывается только её строка в фасете, а не весь индекс.
Главный риск фасета — рассинхронизация. Если данные меняются в обход событий ядра (прямые SQL-вставки, нестандартный импорт, агрессивная пакетная загрузка), индекс может не узнать об изменениях и начать показывать устаревшие счётчики. Именно поэтому после массовых операций фасет принято перестраивать целиком — об этом отдельный раздел ниже.
Типы свойств: какие включать в фасет
Половина проблем со скоростью фильтра решается на этапе типизации свойств. Битрикс умеет фильтровать по разным типам, но эффективность у них разная. Ориентируйтесь на таблицу:
| Тип свойства | В фасет | Когда уместно |
|---|---|---|
| Список | Да, идеально | Бренд, цвет, материал, тип — конечный набор значений |
| Число | Да, диапазоном | Цена, вес, мощность, диагональ — бегунок «от и до» |
| Привязка к справочнику (highload) | Да | Большие справочники характеристик, общие для многих товаров |
| Да/Нет (флаг) | Да | «В наличии», «со скидкой», «новинка» |
| Строка | Нежелательно | Произвольный текст плохо группируется и раздувает фасет |
| HTML/текст, файл | Нет смысла | Описания и медиа не предназначены для фильтрации |
Практическое правило: всё, по чему покупатель реально хочет отсеивать товары, должно быть «списком», «числом» или привязкой к highload-справочнику. Если характеристика сейчас лежит в строке (например, цвет введён вручную текстом «Синий», «синий», «СИНИЙ»), её нужно нормализовать и перевести в список перед тем, как включать в фасет. Иначе вы получите три «разных» значения вместо одного и распухший индекс.
Чем умный фильтр отличается от обычного — наглядно
| Критерий | Умный фильтр + фасет | Фильтр без фасетного индекса |
|---|---|---|
| Скорость на 50 000 товаров | Десятки миллисекунд | Секунды, растёт с каталогом |
| Счётчики «сколько останется» | Есть, считаются мгновенно | Дорого или отключены |
| Нагрузка на базу | Низкая (читает индекс) | Высокая (запрос на каждый клик) |
| SEO-страницы по фильтру | Поддерживаются штатно | Требуют доработки |
| Обновление после обмена с 1С | Нужна переиндексация | Не применимо |
Настройка умного фильтра пошагово
- Подготовьте свойства каталога. Откройте инфоблок каталога и переведите фильтруемые характеристики (бренд, цвет, размер, материал) в тип «Список» или «Число». Тип «Строка» в фасет индексируется плохо и замедляет фильтр.
- Включите «Участвует в умной фильтрации». В настройках каждого нужного свойства поставьте этот флажок и при необходимости задайте, как свойство показывать в фильтре (флажки, выпадающий список, бегунок цены).
- Постройте фасетный индекс. В разделе «Контент → Торговый каталог → Настройки фасетного индекса» (или на вкладке инфоблока) запустите построение индекса. На большом каталоге это занимает время — лучше делать в часы низкой нагрузки.
- Разместите компонент. Подключите
bitrix:catalog.smart.filterна странице раздела рядом со списком товаров (catalog.section) и укажите тот же инфоблок и набор свойств. - Включите кэширование. В параметрах компонента задайте тип кэша «Авто» (managed cache), чтобы панель фильтра не пересобиралась на каждый запрос.
- Проверьте на боевых данных. Прокликайте популярные комбинации, убедитесь, что счётчики совпадают с реальным числом товаров, и замерьте время отклика.
Как это выглядит в админке 1С-Битрикс
Настройки фасетного индекса и умной фильтрации живут в свойствах инфоблока и в разделе торгового каталога. Схематично интерфейс настройки свойства выглядит так:
Переиндексация и кэш: как держать фасет актуальным
Фасетный индекс — не статичная вещь, которую построили один раз и забыли. Он живёт вместе с каталогом, и от того, насколько грамотно настроено его обновление, зависит и скорость, и достоверность счётчиков. Различают два режима обновления.
- Инкрементальное (точечное). Срабатывает автоматически при изменении товара через интерфейс или штатные события ядра. Пересчитывается только затронутая позиция — быстро и незаметно.
- Полное перестроение. Перестраивает индекс целиком. Нужно после массовых операций: первичного импорта, большого обмена с 1С, изменения набора умно-фильтруемых свойств, исправления типов свойств.
Самая частая операционная проблема — рассинхрон после обмена с 1С. Обмен льёт в базу тысячи позиций пакетно, и если он идёт в обход событий, инкрементальное обновление их «не видит». Поэтому полное перестроение фасета имеет смысл повесить на агент по расписанию — например, ночью после планового обмена, в часы низкой нагрузки. Так каталог днём всегда работает на актуальном и тёплом индексе.
Кэширование — второй столп скорости. Оно работает на нескольких уровнях, и важно не путать их:
| Уровень кэша | Что кэширует | Когда сбрасывается |
|---|---|---|
| Кэш компонента фильтра | HTML панели фильтра и счётчики | При изменении товаров раздела |
| Управляемый кэш (managed) | Выборки по тегам инфоблока | Автоматически по тегам при правке данных |
| Композитный кэш | Статическую часть страницы | По TTL и тегам, динамика догружается |
Типичная ошибка — отключить кэш «на время отладки» и забыть включить обратно. Внешне сайт работает, но каждый клик по фильтру пересобирает панель заново, и под нагрузкой это выливается в просадку. Перед выкладкой всегда проверяйте, что тип кэша компонента стоит в значении «Авто», а не «Не кэшировать».
Агрегаты, highload-блоки и единичные SKU
На реальных каталогах характеристики редко лежат «плоско» в самом товаре. Чаще есть торговые предложения (SKU) — размеры и цвета у одной модели, и общие справочники характеристик. Умный фильтр это поддерживает, но есть нюансы, которые стоит учесть.
Свойства торговых предложений. Когда у модели много вариаций, фильтровать нужно по свойствам SKU (размер, цвет конкретной позиции), а карточку показывать на уровне товара. Умный фильтр умеет агрегировать свойства предложений к родительскому товару — главное включить умную фильтрацию именно на нужном уровне инфоблока (товаров или предложений) и не дублировать одно свойство в обоих.
Highload-блоки. Большие общие справочники характеристик (например, единый список брендов на десятки тысяч позиций) удобно хранить в highload-блоке и привязывать к товарам как свойство-справочник. Плюсы для фильтра: значения нормализованы, не дублируются, легко расширяются дополнительными полями (иконка бренда, синоним для поиска). В фасет такие привязки попадают корректно и работают так же быстро, как обычные списки.
Единичные и «висящие» значения. Свойства, у которых почти каждое значение уникально (артикул, серийный номер, точная масса с тремя знаками), в фасет включать не нужно — они не помогают сужать выбор, зато раздувают индекс. Для них лучше подходит обычный поиск по каталогу, а не фильтр.
ЧПУ и SEO-страницы из умного фильтра
Самая недооценённая возможность умного фильтра — превращать комбинации значений в отдельные посадочные страницы. Связка «бренд + категория» или «материал + цвет» становится страницей с человекопонятным URL (ЧПУ — человекопонятный URL), своими title, description и H1 по шаблону. Так каталог сам генерирует сотни целевых страниц под низкочастотные запросы.
Технически это работает через правила обработки URL и SEO-инструменты раздела каталога. Вместо адреса с длинной строкой GET-параметров (которую поисковики не любят) формируется чистый путь вида /catalog/smartfony/apple/ или /catalog/divany/uglovye-serye/. Для каждого такого шаблона задаётся свой набор метатегов с подстановкой значений: «Купить {бренд} {категория} — цены, характеристики, доставка».
При проектировании SEO-страниц фильтра придерживайтесь нескольких принципов:
- Открывайте только спрос. Страницу под комбинацию стоит создавать там, где есть поисковый спрос и достаточно товаров. «Бренд + цвет» с двумя позициями в выдаче — слабая посадочная.
- Один интент — один URL. Следите, чтобы разные пути не вели к одинаковому набору товаров. Это прямой путь к дублям.
- Уникальные метатеги. Шаблон с подстановкой значений должен давать осмысленные, не повторяющиеся
titleиdescription. - Связность. Перелинкуйте SEO-страницы между собой и с категориями, чтобы поисковик их находил и понимал структуру.
Подробно SEO-структуру каталога мы разбираем в материалах рубрики SEO и продвижение, а если нужна готовая SEO-структура каталога под ключ — это отдельная услуга по сайтам с SEO-структурой.
Склейка дублей и canonical
Обратная сторона мощного фильтра — риск засорить индекс поисковика мусорными страницами. Одни и те же товары можно получить разными путями: через разный порядок параметров, через бесконечные комбинации редких значений, через сортировки и постраничную навигацию. Если всё это открыто для индексации, поисковый робот тратит краулинговый бюджет на дубли, а ранжирование «размазывается» между почти одинаковыми URL.
Базовый набор мер против дублей:
- Канонические адреса. На страницах-вариациях (сортировка, пагинация, неприоритетные комбинации) указывайте
rel="canonical"на основную версию раздела или на «главную» SEO-комбинацию. - Управление индексацией. «Мусорные» комбинации и технические параметры закрывайте от индексации — через
robots, метатегnoindexили правила на уровне шаблона. - Чистые ЧПУ для спроса. Только осмысленные комбинации получают собственный индексируемый URL и метатеги; остальное живёт на GET-параметрах и канонизируется.
- Стабильный порядок параметров. Нормализуйте строку фильтра, чтобы «цвет+бренд» и «бренд+цвет» не порождали два разных адреса с одинаковым содержимым.
Грамотная склейка дублей — это ровно тот баланс, который отличает фильтр-генератор трафика от фильтра-генератора проблем с индексацией. Создавайте посадочные под реальный спрос и жёстко канонизируйте всё остальное.
Производительность и метрики
«Фильтр стал быстрее» — субъективное ощущение. Чтобы управлять скоростью, её нужно измерять. Вот ориентиры и метрики, на которые стоит смотреть на большом каталоге.
| Метрика | Что показывает | Ориентир |
|---|---|---|
| Время отклика панели фильтра | Скорость пересчёта счётчиков | Десятки мс на тёплом фасете |
| Время построения списка товаров | Скорость выборки по условиям | До нескольких сотен мс |
| Число SQL-запросов на клик | Опирается ли фильтр на фасет | Единицы, а не десятки |
| Время полного перестроения фасета | Стоимость переиндексации | Планировать на низкую нагрузку |
| LCP и INP страницы каталога | Воспринимаемую скорость для пользователя и Core Web Vitals | LCP до 2,5 с, INP до 200 мс |
Практический порядок диагностики: включите отладочную панель Битрикса или профилировщик и посмотрите на число и время SQL-запросов при клике по фильтру. Если запросов десятки и они тяжёлые — фасет не используется или не построен. Если запросов мало, но страница всё равно медленная — узкое место в выводе товаров, шаблоне или фронтенде, и тогда помогает композитный кэш и оптимизация вёрстки. Разделяйте «медленный бэкенд» и «медленный фронтенд»: лечатся они разными средствами.
Отдельно стоит держать в голове воспринимаемую скорость. Даже быстрый бэкенд не спасёт, если страница «прыгает» при загрузке фильтра. Композитный сайт отдаёт статическую часть мгновенно, а панель фильтра и список догружаются — пользователь видит каталог почти сразу, что прямо улучшает метрики LCP и INP.
Если умный фильтр тормозит — что проверить
Скорость фильтра почти всегда упирается в одно из нескольких мест. Пройдитесь по списку сверху вниз:
- Фасетный индекс не построен или устарел. Самая частая причина после обмена с 1С. Перестройте индекс.
- Свойства типа «строка». Переведите фильтруемые свойства в «список» или «число».
- Нет кэша компонента. Включите managed cache и кэш умного фильтра.
- Слишком много значений в фильтре. Сворачивайте редкие значения и длинные списки под «показать ещё».
- Сайт не композитный. Композитный сайт отдаёт статическую часть страницы мгновенно, а фильтр догружает динамику — это заметно улучшает воспринимаемую скорость и Core Web Vitals.
Частые ошибки при настройке
- Забыли перестроить фасетный индекс после массового импорта — счётчики врут, выдача расходится с остатками.
- Фильтруют по свойству «строка» с произвольными значениями — фасет распухает, скорость падает.
- Открыли для индексации все комбинации фильтра — поисковик получает тысячи почти одинаковых страниц-дублей.
- Вывели в фильтр десятки свойств сразу — посетитель теряется, а компонент тяжелеет. Оставьте 5–8 значимых характеристик.
- Отключили кэш «на время отладки» и забыли вернуть — фильтр пересобирается на каждый запрос.
- Дублируют одно свойство на уровне товара и торгового предложения — счётчики начинают противоречить друг другу.
- Не нормализовали значения перед переводом в список — «Синий», «синий» и «СИНИЙ» становятся тремя разными пунктами фильтра.
- Строят фасет в часы пик — переиндексация большого каталога нагружает базу и тормозит сайт для живых посетителей.
Чек-лист внедрения
Сведём всё в практический список, по которому удобно принимать готовность фильтра перед запуском:
- Свойства типизированы. Все фильтруемые характеристики переведены в «список», «число» или привязку к highload-справочнику; строковых среди них нет.
- Значения нормализованы. Нет дублей-синонимов в списках, регистр и написание приведены к единому виду.
- Умная фильтрация включена. На нужных свойствах стоит флаг «Участвует в умной фильтрации», уровень (товар или предложение) выбран осознанно.
- Фасет построен. Полное перестроение выполнено, индекс актуален, счётчики совпадают с реальными остатками.
- Переиндексация автоматизирована. Агент перестраивает фасет после обмена с 1С в часы низкой нагрузки.
- Кэш включён. Тип кэша компонента — «Авто», управляемый кэш активен, композит настроен.
- SEO-страницы оформлены. Осмысленные комбинации отдаются как ЧПУ с уникальными метатегами; мусорные закрыты и канонизированы.
- Метрики замерены. Зафиксированы время отклика фильтра, число SQL-запросов на клик и LCP/INP каталога.
Вывод
Умный фильтр в 1С-Битрикс быстрый ровно настолько, насколько правильно подготовлен каталог: свойства в нужных типах, построенный фасетный индекс, включённый кэш и аккуратная связка с SEO. Сделайте эти четыре вещи — и фильтр перестанет быть узким местом даже на каталоге в десятки тысяч товаров.
