Розробка модуля фільтрації каталогу 1С-Бітрікс
Уявіть: ваш каталог розрісся до 50 000 товарів, а стандартний фільтр Бітрікс почав завантажувати сторінку по 10 секунд. Ми стикалися з таким на кожному другому проєкті. За 8 років розробки модулів для Бітрікс ми виробили рішення, яке дає гарантію продуктивності навіть на каталогах з 200+ властивостями. Економія на серверних ресурсах за рахунок оптимізованих запитів стає значною перевагою.
Стандартний компонент catalog.section.list з фільтром catalog.section.list.filter працює з коробки, але при великій кількості властивостей (b_iblock_element_prop_s*, b_iblock_element_prop_m*) запити стають повільними через множинні JOIN. Чекбокси показують всі можливі значення без урахування того, скільки товарів за ними стоїть — користувач клікає і отримує порожній результат. Динамічна перебудова фільтра вбиває продуктивність на каталогах від 10 000 позицій.
Як денормалізація індексу прискорює фільтрацію?
Корінь проблеми — архітектура зберігання властивостей інфоблоку. Для кожної властивості потрібен окремий JOIN. Наше рішення — денормалізований індекс фільтра. Модуль створює та підтримує таблицю myvendor_filter_index, де для кожного товару зберігається пласка структура значень всіх фільтрованих властивостей у JSONB:
CREATE TABLE myvendor_filter_index ( element_id INT PRIMARY KEY, section_id INT NOT NULL, price_min DECIMAL(12,2), in_stock BOOLEAN, props JSONB NOT NULL -- {"brand": "Samsung", "color": ["black", "white"]} ); CREATE INDEX idx_filter_props ON myvendor_filter_index USING gin(props); CREATE INDEX idx_filter_section ON myvendor_filter_index(section_id); CREATE INDEX idx_filter_price ON myvendor_filter_index(price_min); Індекс оновлюється через подію OnAfterIBlockElementUpdate конкретного товару та через агент для масового перерахунку. За нашими тестами, JSONB-індекс в 15 разів швидший за стандартні JOIN на каталогах від 50 000 товарів.
Деталі оновлення індексу
Агент запускається раз на 5 хвилин за наявності змін. Він збирає ID змінених елементів і оновлює лише їх записи в myvendor_filter_index. При масовому імпорті з 1С індекс перебудовується за розкладом — нічний агент виконує повну переіндексацію.
Чому розумні лічильники (facets) важливі для UX?
Це ключова фіча — показувати поруч із кожним значенням фільтра кількість товарів, які за ним стоять з урахуванням уже вибраних фільтрів. Така поведінка називається фасетний пошук.
-- Підрахунок варіантів для фільтра "Бренд" -- з урахуванням уже вибраного фільтра "Колір: чорний" SELECT props->>'brand' AS brand, COUNT(*) AS cnt FROM myvendor_filter_index WHERE section_id = :section_id AND in_stock = true AND props @> '{"color": "black"}'::jsonb GROUP BY props->>'brand' ORDER BY cnt DESC; Цей запит повертає всі бренди з кількістю чорних товарів у наявності. Для кожної властивості виконується окремий такий запит — але це швидко завдяки GIN-індексу. Результати підрахунків кешуються з тегами по розділу та набору активних фільтрів. При зміні будь-якого товару тег скидається. TTL кешу — 30 хвилин.
Як працює AJAX-оновлення?
При зміні фільтра сторінка не перезавантажується: AJAX-запит іде на /api/catalog/filter/, сервер повертає JSON з ID відфільтрованих товарів та оновленими лічильниками. Фронтенд оновлює список і чекбокси. Історія браузера оновлюється через history.pushState. Це забезпечує плавну навігацію без мерехтіння.
Як виглядає URL-схема фільтра?
Фільтр будує «красиві» URL, дружні до SEO:
-
/catalog/smartphones/brand-samsung/color-black/— посторінковий список з фільтрами -
/catalog/smartphones/brand-samsung/— категоріальний фільтр з власним H1 та описом
Ключові сторінки фільтра можуть мати унікальні мета-теги, що задаються через адміністративний інтерфейс модуля. Інші формуються автоматично за шаблоном. Це покращує індексацію та ранжування в пошукових системах.
Ранжування результатів
Окрім фільтрації, модуль керує сортуванням: за ціною, популярністю (кількість замовлень з b_sale_basket), новизною, рейтингом. «Популярність» перераховується агентом раз на добу і зберігається в myvendor_filter_index.popularity_score.
Порівняння: стандартний фільтр vs наш модуль
| Параметр | Стандартний фільтр Бітрікс | Наш модуль |
|---|---|---|
| Час запиту (50k товарів, 100 властивостей) | 8–12 сек | 0.3–0.8 сек |
| Кількість JOIN у запиті | 10–100+ | 1 (до денормалізованої таблиці) |
| Розумні лічильники | Ні | Так |
| SEO-URL | /catalog/?filter=... |
/catalog/brand-samsung/ |
| Кешування результатів | Обмежене | Теговане з TTL 30 хв |
Етапи розробки модуля фільтрації
- Аудит поточної архітектури каталогу та властивостей інфоблоку.
- Проєктування схеми денормалізованого індексу під ваш обсяг даних.
- Реалізація фасадів з розумними лічильниками та кешуванням.
- Налаштування AJAX-оновлення та красивих URL.
- Оптимізація запитів для каталогів до 500 000 товарів.
- Документація з підтримки та донавчання адміністраторів.
Терміни розробки
| Масштаб | Склад | Термін |
|---|---|---|
| Базовий | Денормалізований індекс + чекбокси + діапазон цін | 3–4 тижні |
| Середній | + розумні лічильники (фасети) + AJAX + URL-схема | 5–7 тижнів |
| Розширений | + SEO-сторінки фільтра + персоналізація сортування | 8–11 тижнів |
Кількість властивостей інфоблоку та обсяг каталогу — головні фактори вибору архітектури. При 200+ властивостях JSONB-підхід потребує ретельного проєктування схеми індексу.
Чому обирають нас
Ми розробляємо модулі для Бітрікс понад 8 років, реалізували 40+ проєктів з фільтрацією каталогів. Даємо гарантію продуктивності на обсягах від 10 000 товарів. Замовте розробку модуля фільтрації — зв'яжіться з нами для попередньої оцінки вашого проєкту. Отримайте консультацію сьогодні.