Оптимизация фильтра товаров на «1С-Битрикс»

Почему умный фильтр тормозит и что реально помогает его ускорить

Введение

Если каталог интернет-магазина на «1С-Битрикс» растёт, а фильтр по цвету, размеру или бренду начинает отвечать секунду и дольше, это не мелкая неприятность: медленный фильтр — прямая причина того, что посетитель уходит со страницы, не дождавшись результата. Материал написан для владельцев интернет-магазинов, руководителей интернет-проектов и разработчиков, которые столкнулись с тормозящим фильтром и хотят понять, что можно поправить своими силами, а где нужна помощь специалистов — и почему это происходит с технической точки зрения. Дальше разберём устройство умного фильтра, конкретные механизмы ускорения, российскую специфику и практические шаги внедрения.

Что такое умный фильтр и почему он тормозит

Как устроен умный фильтр

Умный фильтр — стандартный компонент каталога «1С-Битрикс», который позволяет посетителю сузить список товаров по свойствам: бренду, цвету, диапазону цен и так далее. Ключевая технология, на которой он держится, — фасетный индекс: отдельные таблицы базы данных, в которых заранее просчитано, какие значения свойств и типов цен встречаются в каждом разделе каталога. Вместо перебора всех товаров при каждом клике по фильтру система обращается к уже готовому набору значений [3][4]. В официальных учебных материалах разработчика платформы приводится пример, где включение фасетных индексов ускорило отклик фильтра примерно в 15 раз — потому что без индекса время ответа растёт пропорционально числу товаров и свойств, а с индексом эта зависимость практически исчезает [1].

Так было не всегда: в ранних версиях умного фильтра часть типов свойств, например справочники, вообще нельзя было использовать для отбора товаров — это ограничение сняли вместе с появлением фасетного индекса, после чего индексация стала происходить автоматически при добавлении новых товаров [6].

Типичные причины медленной работы

Медленный фильтр почти всегда связан с одной из нескольких причин.

Индекс не создан или устарел. Фасетный индекс нужно один раз построить вручную в административной панели, а дальше система сама подсказывает, когда он рассинхронизировался с текущим состоянием каталога [3]. Отдельная тонкость связана с обменом данными с 1С: если синхронизация деактивирует и снова активирует товары, индекс нужно перестраивать после каждого такого обмена, иначе фильтр будет какое-то время показывать устаревшие данные — фасетный индекс строится только по активным товарам, и без специального обработчика на событие завершения обмена автоматической переиндексации не произойдёт [7].

Компонент проверяет лишнее. В обсуждении на форуме разработчиков платформы разбирался характерный случай: запрос фильтрации, который дополнительно проверял активность и права доступа к каждому элементу, выполнялся около 4 секунд; после отключения этих проверок и добавления индекса по служебному полю фасета время сократилось примерно вдвое, до 2 секунд. Для обычного каталога товаров такие проверки часто избыточны, но заметно влияют на скорость отклика [2].

Каталог вырос за пределы стандартной конфигурации. По результатам нагрузочного тестирования на реальном стенде увеличение числа складов до полусотни почти не сказывается на страницах каталога и фильтрации, а вот рост числа свойств SKU заметно раздувает таблицы фасета и почти вдвое увеличивает время выполнения запросов на страницах списка товаров и фильтрации. Рост числа типов цен даёт более скромный эффект — умеренное увеличение числа запросов и времени их выполнения [8][9]. При этом сам фасетный индекс не работает одинаково хорошо при любом объёме данных: когда таблица фасета разрастается примерно до 10 млн записей и больше, начинают сказываться тяжёлые операции соединения таблиц, и индекс сам становится узким местом [8].

Как ускорить фильтр: практические механизмы

Фасетный индекс: создание и актуальность

Порядок работы простой: сначала настраивается отображение нужных свойств в компоненте умного фильтра, и только потом создаётся сам индекс, потому что любое изменение состава отображаемых свойств требует пересоздания индекса заново — иначе он продолжит соответствовать прежней конфигурации фильтра [5]. Для больших каталогов важно учитывать время построения: процесс индексации объёмного каталога с большим числом свойств и элементов может занять продолжительное время, поэтому его стоит запускать в часы наименьшей нагрузки на магазин [6].

Если каталог обновляется через обмен с 1С, автоматическое обновление индекса при добавлении единичного товара не покрывает случай массовой синхронизации. Здесь разумно на событие окончания обмена вешать отдельный обработчик, который деактивирует товары, не проходящие по бизнес-логике показа на сайте, и запускает перестроение индекса — это закрывает разрыв между тем, что реально в наличии по данным 1С, и тем, что видит фасетный индекс [7].

Настройки компонента и индексы MySQL

Часть проблем решается не архитектурой, а точечной настройкой. Отключение проверки активности и прав доступа там, где это не требуется бизнес-логике, вместе с добавлением недостающего индекса на уровне базы данных заметно ускоряет типовой запрос фильтрации [2]. В целом анализ и создание недостающих индексов — штатная процедура платформы, доступная в разделе «Настройки → Производительность → Индексы → Анализ индексов»: система сама анализирует текущие индексы базы данных и подсказывает, какие стоит добавить [14]. Перед такими изменениями стоит обязательно сделать резервную копию сайта.

Композитный сайт и кэширование

Композитное кэширование решает другую задачу — не саму фильтрацию, а общую скорость отдачи страницы каталога. Технология разделяет страницу на статическую HTML-оболочку, которая отдаётся из кэша почти мгновенно, и динамические зоны — корзину, персональные скидки, — которые дозагружаются AJAX-запросом уже после того, как страница отрисовалась в браузере. За счёт этого заметно улучшаются такие показатели, как время до первого байта и метрики Core Web Vitals [12]. На практике включение композита требует аккуратной настройки: рекомендуется включать автоматический режим композита, выбирать стандартный (а не «маскирующий») режим перезаписи кеша и заранее делать резервную копию перед обновлением платформы — упрощённые режимы перезаписи кеша удобны, но скрывают некорректную работу композита и мешают её диагностировать [13].

Инфоблоки 2.0: смена архитектуры хранения данных

Если стандартный фасетный индекс и настройка компонента уже исчерпаны, а каталог продолжает расти, следующий шаг — переход на инфоблоки 2.0. Эта архитектура иначе организует таблицы свойств и фасета: число присоединяемых таблиц при фильтрации по свойствам перестаёт расти с добавлением каждого нового свойства, а выборка значений множественных свойств больше не создаёт декартова произведения вариантов, поскольку значения передаются массивом [11]. Дополнительно инфоблоки 2.0 позволяют вручную создавать составные индексы базы данных под конкретные комбинации фильтров, что ускоряет выборку по нескольким единичным свойствам одновременно [10]. Практическое подтверждение эффекта даёт нагрузочное тестирование: переход на инфоблоки 2.0 снижает число обрабатываемых строк в таблицах свойств и фасетов и частично компенсирует накладные расходы самого фасетного индекса, но требует корректной настройки MySQL-индексов для новых колонок [8]. Есть и обратная сторона: у инфоблоков 2.0 нет «сквозной» выборки элементов по символьному коду свойства без указания конкретного идентификатора инфоблока — это иногда требует правок в уже написанном коде компонентов.

Для каталогов на грани десятков миллионов записей в фасете одной настройкой не обойтись — здесь помогает вынос части свойств в отдельные структуры данных и точечная доработка компонентов под конкретный объём каталога. Так, по опыту сопровождения одного из проектов с каталогом на несколько миллионов SKU, стабильная работа достигалась именно за счёт сочетания глубокой оптимизации запросов, продуманного кэширования и аккуратной организации данных внутри инфоблоков, а не одной универсальной настройки [8].

Российская специфика

«1С-Битрикс: Управление сайтом» — российская разработка, включённая в реестр отечественного программного обеспечения при Минцифры России; правообладателем выступает ООО «Битрикс», а исключительное право оформлено как результат собственной разработки компании [19]. Это снимает для большинства интернет-магазинов вопрос об импортозамещении CMS как таковой: платформа уже соответствует требованиям к отечественному ПО, и переносить каталог на другую систему ради этого не требуется.

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

Варианты реализации: что выбрать

Штатных средств «1С-Битрикс» — фасетного индекса, композитного кэширования и анализа индексов базы данных — обычно достаточно для каталогов среднего размера. Для интернет-магазинов с большим количеством товаров (по ориентировочным оценкам практиков — от тысячи и выше) ускорение фильтра — это уже не косметическая доработка, а прямая задача, влияющая на конверсию и выручку: медленный фильтр увеличивает время ожидания при выборе параметров и снижает интерес пользователей к продолжению работы с каталогом [14][5].

Готовые модули от партнёров платформы решают более узкую задачу — в первую очередь SEO-обвязку фильтра: человекопонятные адреса, автоматическое добавление страниц фильтра в карту сайта, канонические ссылки и защиту от дублей [16][17]. Такие решения удобны, когда штатных настроек ЧПУ и карты сайта для фильтра не хватает, но они не заменяют работу с фасетным индексом и архитектурой данных — это разные слои одной задачи.

Индивидуальная доработка нужна в двух ситуациях. Первая — очень специфичная логика фильтрации, для которой типовые свойства инфоблока избыточны или неудобны: в одном из практических кейсов фильтр по производителю для каталога на 80 тысяч товаров и 3 тысячи разделов был реализован через отдельную индексацию каталога без создания дополнительных товарных свойств на стороне 1С, что позволило фильтру работать быстро на большом объёме номенклатуры полностью в автоматическом режиме [15]. Вторая ситуация — каталоги на границе возможностей стандартной архитектуры (миллионы SKU), где требуется вынос части свойств в отдельные структуры и ручная оптимизация запросов, как в упомянутом выше кейсе с каталогом на несколько миллионов SKU [8].

SEO страниц фильтра

Ускоренный фильтр не приносит SEO-пользы автоматически — это отдельная задача. По умолчанию страницы результатов фильтрации не участвуют в продвижении: они не попадают в карту сайта, а значит, не индексируются, а сформированные фильтром ссылки при выборе нескольких значений быстро становятся длинными и нечитаемыми [16]. Решается это на уровне настроек компонента каталога: в параметрах bitrix:catalog на вкладке «Управление адресами страниц» есть поле, задающее шаблон человекопонятного адреса вида #SECTION_CODE#/filter/#SMART_FILTER_PATH#/, где символьный код и значение свойства подставляются в адрес вместо стандартных GET-параметров [18].

При грамотной настройке страницы фильтра превращаются в дополнительные посадочные страницы под конкретные запросы — например, отдельная страница под запрос вида «жёлтый облицовочный кирпич» внутри раздела с облицовочным кирпичом. Это позволяет закрыть семантическое ядро практически любого размера и полезно не только для органического поиска, но и для контекстной рекламы [17]. Здесь же стоит заранее решить, какие комбинации фильтра открывать для индексации, а какие закрывать, чтобы не плодить дубли и не размывать вес важных страниц каталога.

Практические этапы

1. Диагностика. Определить, где именно медленно — список товаров, сама фильтрация или детальная страница, — с помощью встроенного инструмента тестирования нагрузки в разделе «Производительность», который показывает, на каком именно запросе происходит просадка [14].
2. Аудит фасетного индекса. Проверить, создан ли индекс, актуален ли он и как часто перестраивается после синхронизации с 1С.
3. Анализ индексов базы данных. Прогнать штатный анализ индексов и создать недостающие, предварительно сделав резервную копию.
4. Настройка компонента. Отключить избыточные проверки активности и прав там, где это допустимо бизнес-логикой каталога.
5. Включение композитного кэширования с проверкой корректности его работы по служебным заголовкам ответа сервера, а не только на глаз.
6. Оценка целесообразности перехода на инфоблоки 2.0 — актуально при десятках и сотнях тысяч товаров или большом числе свойств SKU.
7. Настройка ЧПУ и SEO-параметров страниц фильтра: карта сайта, канонические адреса, правила индексации комбинаций.
8. Нагрузочное тестирование после изменений — сравнение показателей до и после на реалистичном сценарии, а не только на тестовой странице.

Ограничения, ошибки и риски

Частая ошибка — включать композитное кэширование в режиме, который скрывает сбои, вместо стандартного режима перезаписи кеша, который такие сбои показывает; в результате проблема с композитом обнаруживается уже по жалобам пользователей, а не по логам [13]. Вторая типичная ошибка — менять состав свойств умного фильтра и забывать пересоздать фасетный индекс: индекс остаётся привязан к прежнему набору свойств, и фильтр либо продолжает работать по старой схеме, либо выдаёт некорректные результаты [5]. Третья — запускать построение или перестроение индекса на большом каталоге в часы пиковой нагрузки, что может ощутимо просадить сайт для реальных покупателей; для этого специально рекомендуют выбирать часы наименьшей нагрузки [6].

Отдельный риск — рассчитывать, что фасетный индекс решает проблему производительности при любом объёме данных. Нагрузочные тесты показывают, что при очень большом каталоге сам индекс становится узким местом из-за разросшихся таблиц и тяжёлых соединений, и в этом случае дальнейшее ускорение требует уже архитектурных решений, а не только включения штатных механизмов [8]. Наконец, стоит помнить про синхронизацию с 1С: без обработчика на событие окончания обмена деактивированные товары могут какое-то время оставаться видимыми в результатах фильтра, что для интернет-магазина означает риск продавать то, чего фактически нет в наличии [7].

Рекомендации по выбору решения

Если каталог насчитывает до нескольких десятков тысяч товаров и фильтр тормозит впервые, обычно достаточно штатных средств: фасетный индекс, анализ и создание индексов базы данных, композитное кэширование и настройка компонента. Это можно сделать силами штатного администратора или разработчика с опытом «1С-Битрикс», без глубокой переработки архитектуры.

Если каталог исчисляется сотнями тысяч товаров, в нём много свойств SKU или типов цен, а штатные механизмы уже включены, но эффекта недостаточно, стоит рассматривать переход на инфоблоки 2.0 и пересмотр организации данных каталога — это уже задача, требующая оценки конкретной конфигурации проекта, а не набора действий по чек-листу.

Отдельно от производительности стоит решить вопрос SEO фильтра: даже быстрый фильтр не приносит пользы поисковому трафику, если его страницы не индексируются и не имеют человекопонятных адресов. Здесь можно обойтись настройками штатного компонента либо специализированным модулем — выбор зависит от того, насколько тонкая настройка мета-тегов и карты сайта нужна проекту.

Как может помочь «Пятый фактор»

Оптимизация фильтра на «1С-Битрикс» редко сводится к одной настройке — обычно нужно последовательно проверить фасетный индекс, настройки компонента, индексы базы данных, композитное кэширование и, при необходимости, архитектуру хранения свойств каталога, а также синхронизацию с 1С, которая может незаметно возвращать проблему после каждого обмена данными. Команда «Пятого фактора» может изучить конкретный каталог и сценарии его использования, провести технический аудит производительности фильтра и предложить решение — от точечной настройки штатных механизмов до доработки архитектуры каталога или обработчиков синхронизации с 1С, в зависимости от того, что реально требуется проекту.

Вывод

Медленный фильтр товаров на «1С-Битрикс» почти всегда объясним и почти всегда решаем без замены платформы. В основе решения — фасетный индекс, который нужно вовремя создавать и перестраивать, разумная настройка компонента без избыточных проверок, композитное кэширование и, при росте каталога до сотен тысяч товаров, переход на инфоблоки 2.0 или пересмотр организации данных. Отдельно стоит заняться SEO страниц фильтра — это уже не про скорость, а про то, чтобы быстрый фильтр приносил ещё и трафик. Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.

Источники

[1] dev.1c-bitrix.ru — Умный фильтр (учебный курс, официальная документация разработчика платформы) — https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=42&LESSON_ID=5371

[2] dev.1c-bitrix.ru — Умный фильтр весь такой фасетный и няшный (обсуждение на форуме разработчиков) — https://dev.1c-bitrix.ru/community/blogs/product_features/smart-filter-all-such-faceted-and-clean-and-very-good.php

[3] koderline.ru — Настройка общих свойств товаров в Битрикс — https://www.koderline.ru/expert/programming/article-umnyy-filtr-bitriks/

[4] onvolga.ru — Что такое умный фильтр в 1С-Битрикс — https://onvolga.ru/statsozd/2304-umnyj-filtr-1c-bitrix/

[5] dev.1c-bitrix.ru — Фасетный поиск: улучшаем работу каталога товаров (учебный курс) — https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=42&LESSON_ID=5364&LESSON_PATH=3912.4771.5364

[6] web.nav-it.ru — Умный фильтр весь такой фасетный и няшный — https://web.nav-it.ru/technology/bitrix/226451/

[7] gdecider.github.io — Умный фильтр, бизнес-логика сайта и перестроение фасетного индекса — https://gdecider.github.io/articles_bx-smart-filter-faset.html

[8] habr.com — «Большие» объемы данных в Битрикс: что убивает производительность — https://habr.com/ru/companies/intervolga/articles/963406/

[9] intervolga.ru — Повышаем производительность Битрикс при больших объемах данных — https://www.intervolga.ru/blog/projects/bolshie-obemy-dannykh-v-bitriks-chto-ubivaet-proizvoditelnost/

[10] acrit-studio.ru — Как достичь наибольшей эффективности при использовании Инфоблоков 2.0 — https://www.acrit-studio.ru/pantry-programmer/knowledge-base/effektivnost_i_proizvoditelnost/kak-dostich-naibolshey-effektivnosti-pri-ispolzovanii-infoblokov-2-0/

[11] sendev.ru — Инфоблоки 2.0 в 1С-Битрикс: улучшение производительности и упрощение разработки — https://sendev.ru/blog/1c-bitrix/infobloki-2-0-v-1s-bitriks/

[12] docs.1c-bitrix.ru — Композитный сайт (официальная документация BitrixFramework) — https://docs.1c-bitrix.ru/pages/performance/composite-site.html

[13] intervolga.ru — Композитный сайт в 1С-Битрикс: как правильно использовать технологию и ускорить загрузку — https://www.intervolga.ru/blog/support/1c-bitrix-avtokompozit/

[14] marketplace.1c-bitrix.ru — 8 способов увеличить производительность сайта на 1С-Битрикс — https://marketplace.1c-bitrix.ru/blog/8-ways-to-increase-the-performance-of-your-site-on-1cbitrix/

[15] webformat.ru — Фильтр каталога товаров для интернет-магазина на 1С-Битрикс — https://www.webformat.ru/blog/websites/filtr-kataloga-po-proizvoditelyu/

[16] sotbit.ru — Как заставить умный фильтр 1С-Битрикс работать на SEO продвижение — https://www.sotbit.ru/info/1c-bitrix/umnyy-filtr-1s-bitriks-rabotaet-na-seo-prodvizhenie.html

[17] intervolga.ru — Использование и настройка Умного фильтра с ЧПУ в Битрикс для SEO — https://www.intervolga.ru/blog/marketing/smartfilter-chpu-dlya-seo/

[18] progclub.ru — Тонкая настройка SEO страниц фильтра 1С Битрикс — https://progclub.ru/blog/bitrix/tonkaya-nastroyka-seo-dlya-rezultatov-filtratsii-kataloga-bitriks/

[19] reestr.digital.gov.ru — 1С-Битрикс: Управление сайтом (реестровая запись Минцифры РФ) — https://reestr.digital.gov.ru/reestr/301404/