Послуги з розробки каталогу та фільтрації на 1С-Бітрікс

Каталог та фільтрація на 1С-Бітрікс

Чому каталог на інфоблоках — це і благо, і головний біль

Інфоблоки в Бітрікс зберігають товари в таблицях b_iblock_element та b_iblock_element_property. Коли в каталозі 5 000 SKU — все літає. Коли 80 000 — bitrix:catalog.smart.filter починає генерувати JOIN на 6-8 таблиць властивостей, і MySQL іде в full scan. Ми проєктуємо каталоги, що витримують півмільйона позицій без деградації — завдяки фасетним індексам, правильній архітектурі властивостей і гібридному зберіганню.

Розумний фільтр: штатний компонент та його межі

bitrix:catalog.smart.filter будує форму фільтрації автоматично за властивостями інфоблоку. З коробки є чекбокси, радіокнопки, повзунки (range), випадні списки, кольорові кола та кнопки із зображеннями.

Але ось що доводиться допрацьовувати майже на кожному проєкті:

• Підрахунок кількості товарів біля кожного значення — без цього покупець клікає в порожнечу
• Приховування порожніх значень — «кладовище» нульових чекбоксів вбиває UX
• Ajax-застосування без кнопки «Показати» — користувач очікує миттєвої реакції
• Скидання окремих параметрів, а не всього фільтра одразу
• Згортувані групи із запам'ятовуванням стану в localStorage

Горизонтальне розташування над каталогом економить місце на мобільних — але потребує переверстки шаблону, штатний варіант збоку.

Фасетний індекс — найважливіше, що треба знати

Ось де закопана основна продуктивність. Без фасетного індексу кожен клік по фільтру — це SQL-запит із JOIN по b_iblock_element, b_iblock_element_property, b_catalog_price та ще парі таблиць. На 100 000 товарів такий запит виконується 2-4 секунди. З фасетним індексом — 30-80 мс.

Як це працює: Бітрікс створює таблицю b_catalog_smart_filter (фасетний індекс), куди складає попередньо розраховані комбінації «розділ + властивість + значення + кількість товарів». При фільтрації рушій звертається до цієї плоскої таблиці замість того, щоб збирати дані з нормалізованої структури інфоблоків.

Граблі, на які всі наступають:

• Індекс потрібно створювати для кожного розділу каталогу окремо — через адмінку «Товари → Фасетний індекс → Створити»
• При масовому імпорті (обмін із 1С, CSV-завантаження) індекс інвалідується. Якщо не налаштувати переіндексацію через агент CIBlockCatalog::ReindexFacet або cron-задачу — фільтр почне показувати невірні лічильники
• Не всі властивості потрібні у фасеті. Властивість «Внутрішній артикул», за якою ніхто не фільтрує, лише роздуває індекс
• На каталогах 300 000+ таблиця фасету важить гігабайти — моніторте розмір через SHOW TABLE STATUS LIKE 'b_catalog_smart_filter'

SEO-фільтри

Стандартний фільтр генерує ?filter[brand]=apple&filter[color]=black — пошуковики такі URL або не індексують, або вважають дублями. А запит «ноутбуки apple чорні» — це найконверсійніший низькочастотний трафік.

Робимо ЧПУ: /catalog/noutbuky/brand-apple/color-black/ з унікальними title, description та H1. Не шаблонними «Купити {бренд} у Мінську», а осмисленими — з урахуванням конкретної комбінації.

Важливі нюанси:

• Канонічні URL — щоб /brand-apple/color-black/ та /color-black/brand-apple/ не дублювалися
• Контроль кількості індексованих комбінацій — 10 властивостей по 20 значень дають мільйони сторінок, пошуковики за таке карають фільтром
• Автоматична sitemap для SEO-сторінок фільтрації
• Адміністративний інтерфейс для менеджера — він сам вирішує, які перетини індексувати

Інфоблоки vs Highload-блоки

На практиці найкраща архітектура — гібридна. Товари та розділи живуть в інфоблоках — там SEO, візуальний редактор, штатні компоненти каталогу. А ось довідкові властивості (бренди, міста, розмірні сітки) з тисячами значень переносимо в Highload-блоки. HLB працюють з окремими таблицями напряму, без overhead b_iblock_element_property.

Коли точно пора на HLB: довідник «Міста» перевалив за 5 000 значень, і випадний список у картці товару вантажиться 8 секунд. Або властивість «Розмір» для взуттєвого каталогу — 200 значень, що смикаються на кожній сторінці.

Користувацькі дані (обране, переглянуте, порівняння) — також у Highload-блоки. Вони швидко зростають, і інфоблоки під це не заточені.

Мультикатегорії

Товар у Бітрікс може належати кільком розділам одночасно. Рюкзак — і в «Туристичному спорядженні», і в «Подарунках для чоловіків». Прив'язка через додаткові розділи без фізичного дублювання елемента. Головне — налаштувати канонічні URL, щоб пошуковик не сприйняв один товар у трьох розділах як три дублі.

Швидкий перегляд та сортування

Швидкий перегляд — AJAX-модалка з фото, ціною, наявністю та кнопкою «До кошика». Попереднє завантаження при наведенні курсора дає відчуття миттєвого відгуку. На мобільних — bottom sheet замість попапу.

Сортування з коробки: ціна, популярність, рейтинг, новизна, назва, наявність. Для акційних розділів додаємо сортування за розміром знижки, для B2B-каталогів — табличний вигляд із технічними параметрами. Уподобання зберігаємо в cookie між сесіями.

Продуктивність

• Вибірка лише потрібних полів через arSelect — жодних SELECT * по інфоблоках
• Керований кеш із тегами: додали товар — кеш перестворився автоматично
• Композитний кеш для анонімів — TTFB < 100 мс, HTML віддається без запуску PHP
• Індекси на властивостях, що беруть участь у фільтрації — без них MySQL сканує b_iblock_element_property цілком
• Моніторинг TTFB: якщо каталог відповідає довше 500 мс — дивимося slow query log

Терміни реалізації

Каталог окупається через зростання конверсії та приплив SEO-трафіку за низькочастотними запитами. Але головне — покупець знаходить товар за два кліки, а не йде після першого натискання на фільтр.