Разработка каталога 1С-Битрикс: как превратить фильтр за 4 секунды в мгновенный отклик
В интернет-магазине 80 000 товаров, умный фильтр на Битрикс тормозит — каждый клик по свойству превращается в 4-секундное ожидание. Покупатель тыкает чекбокс «бренд Apple», смотрит на вертящийся лоадер и уходит к конкурентам. Конверсия падает на 20%. Это знакомая боль. Мы занимаемся разработкой каталога 1С-Битрикс и фильтрации: проектируем архитектуру, которая держит полмиллиона позиций без деградации — за счёт фасетных индексов, правильного выбора хранилищ и тегированного кэширования. Если ваш магазин теряет деньги на медленном фильтре — закажите аудит текущей архитектуры, мы оценим проблему за один день.
Как инфоблоки влияют на производительность каталога?
Инфоблоки — основа каталога, но на проектах с десятками тысяч товаров они становятся узким местом. Стандартный bitrix:catalog.smart.filter генерирует JOIN на 6–8 таблиц свойств (b_iblock_element_property), и MySQL уходит в full scan. Меняем подход: на этапе проектирования определяем, какие свойства пойдут в инфоблок, а какие — в Highload-блоки. Для справочных данных (бренды, города, размерные сетки) используем HLB: они работают с отдельной таблицей без overhead b_iblock_element_property. Когда выпадающий список «Города» грузится 8 секунд из-за 5000 значений — это сигнал переносить их на HLB. Каталог на 80 000 товаров с фильтром за 4 секунды теряет около 1,2 млн рублей в год из-за ухода клиентов — такую экономию даёт правильная архитектура. Свяжитесь с нами, чтобы прикинуть выгоду для вашего проекта.
Что такое фасетный индекс и почему он важен?
Основная производительность кроется здесь. Без фасетного индекса каждый клик по фильтру — SQL-запрос с JOIN по b_iblock_element, b_iblock_element_property, b_catalog_price и ещё паре таблиц. На 100 000 товаров такой запрос выполняется 2–4 секунды. С фасетным индексом — 30–80 мс. Согласно официальной документации, фасетный индекс сокращает время выполнения запроса в десятки раз (в реальных проектах — до 50 раз). Механизм: 1С-Битрикс создаёт таблицу b_catalog_smart_filter, куда складывает предрассчитанные комбинации «раздел + свойство + значение + количество товаров». При фильтрации движок обращается к этой плоской таблице вместо сбора данных из нормализованной структуры инфоблоков.
При настройке фасетного индекса часто допускают одни и те же промахи. Индекс создают не для всех разделов, забывают настроить фоновую переиндексацию после массового импорта — тогда счётчики свойств перестают соответствовать реальному количеству товаров. Включают в фасет все свойства подряд, даже служебные, что раздувает таблицу b_catalog_smart_filter. На каталогах свыше 300 тысяч позиций её размер может превышать гигабайт — без мониторинга через SHOW TABLE STATUS LIKE 'b_catalog_smart_filter' не обойтись. Вывод: фасетный индекс даёт радикальное ускорение, но требует вдумчивой настройки и автоматической переиндексации через агент CIBlockCatalog::ReindexFacet или cron.
Почему Highload-блоки быстрее инфоблоков для справочников?
| Критерий | Инфоблок (IB) | Highload-блок (HLB) |
|---|---|---|
| Хранение свойств | Таблица b_iblock_element_property |
Отдельная плоская таблица на каждый HLB |
| Скорость фильтрации на 50 тыс. товаров | ~500–800 мс (с фасетом) | ~80–150 мс (без фасета) |
| Поддержка SEO (URL, шаблоны) | Полная | Отсутствует (только справочники) |
| Рекомендуется для | Товары, разделы, основные свойства | Справочники (бренды, города), пользовательские данные |
Когда инфоблоки предпочтительнее HLB
Highload-блоки не формируют SEO-URL и не имеют визуального редактора. Если справочник должен иметь отдельные страницы (например, бренды с уникальными H1), используйте инфоблоки. HLB — для сугубо служебных данных, не требующих индексации.На практике лучшая архитектура — гибридная. Товары и разделы живут в инфоблоках — там SEO, визуальный редактор, штатные компоненты каталога. А справочные свойства с тысячами значений переносим в Highload-блоки. Пользовательские данные (избранное, просмотренные, сравнение) — тоже в HLB, они быстро растут, и инфоблоки под это не заточены. Хотите узнать, какую архитектуру выбрать для вашего каталога? Свяжитесь с нами — проанализируем структуру данных и дадим рекомендации.
SEO-фильтры: как получить ЧПУ и не попасть под фильтр Яндекса?
Стандартный фильтр генерирует ?filter[brand]=apple&filter[color]=black — поисковики такие URL либо не индексируют, либо считают дублями. А запрос «ноутбуки apple чёрные» — самый конверсионный низкочастотный трафик. Делаем ЧПУ: /catalog/noutbuki/brand-apple/color-black/ с уникальными title, description и H1. Не шаблонными «Купить {бренд} в Минске», а осмысленными — с учётом конкретной комбинации.
- Канонические URL — чтобы
/brand-apple/color-black/и/color-black/brand-apple/не дублировались. - Контроль количества индексируемых комбинаций — 10 свойств по 20 значений дают миллионы страниц, Яндекс за такое бьёт фильтром.
- Автоматическая sitemap для SEO-страниц фильтрации.
- Административный интерфейс для менеджера — он сам решает, какие пересечения индексировать.
Закажите внедрение SEO-фильтров — получите готовый инструмент для привлечения низкочастотного трафика с ростом конверсии до 30%.
Какие методы дают ощутимый прирост производительности?
- Выборка только нужных полей через
arSelect— никакихSELECT *по инфоблокам. - Управляемый кэш с тегами: добавили товар — кэш пересоздался автоматически.
- Композитный кэш для анонимов: TTFB < 100 мс, HTML отдаётся без запуска PHP.
- Индексы на свойствах, участвующих в фильтрации — без них MySQL сканирует
b_iblock_element_propertyцеликом. - Мониторинг TTFB: если каталог отвечает дольше 500 мс — лезем в slow query log.
Что входит в комплексную разработку каталога на 1С-Битрикс
Мы передаём не просто работающий код, а полный комплект документации и инструментов для самостоятельного управления. В deliverables входят:
- Аудит текущей архитектуры каталога и фильтрации.
- Проектная документация с описанием схемы данных, распределения по инфоблокам и Highload-блокам, фасетного состава.
- Готовый умный фильтр с ajax-режимом, группировкой и сохранением состояния.
- Настроенный фасетный индекс с cron-переиндексацией.
- SEO-фильтры с ЧПУ, уникальными метатегами, каноникалами и sitemap.
- Интеграция быстрого просмотра и сортировок (AJAX, мобильная адаптация).
- Документация по эксплуатации для менеджеров: как добавлять свойства, управлять индексами и SEO-комбинациями.
- Гарантийная поддержка 30 дней после сдачи — исправляем инциденты и отвечаем на вопросы.
Как мы разрабатываем каталог: пошаговый план
Мы не просто ставим компоненты. Процесс включает:
- Аудит текущего каталога — разбор структуры свойств, выявление узких мест, проверка индексов и кэша.
- Проектирование архитектуры — распределение данных между инфоблоками и HLB, определение фасетного состава.
- Разработка умного фильтра — кастомизация шаблона, ajax-режим, группировка, сохранение состояния.
- Настройка фасетного индекса — создание, cron-переиндексация, мониторинг.
- SEO-фильтры — ЧПУ, метатеги, каноникалы, sitemap.
- Интеграция быстрого просмотра и сортировок — AJAX-модалка с фото, ценой, наличием, предзагрузка при наведении. На мобильных — bottom sheet вместо попапа.
- Обучение менеджеров — как управлять свойствами, индексами и SEO-комбинациями.
- Гарантийная поддержка — 30 дней после сдачи.
Сроки реализации
| Задача | Ориентировочный срок |
|---|---|
| Настройка умного фильтра | 3–5 дней |
| Фасетный поиск | 2–3 дня |
| SEO-фильтры | 1–2 недели |
| Быстрый просмотр | 3–5 дней |
| Кастомный шаблон каталога | 1–2 недели |
| Миграция на Highload-блоки | 2–4 недели |
| Комплексная разработка каталога | 4–8 недель |
Каталог окупается через рост конверсии и приток SEO-трафика по низкочастотке. Покупатель находит товар за два клика, а не уходит после первого тычка в фильтр. Получите консультацию — оценим ваш проект в течение дня и предоставим расчёт стоимости с roadmap работ по разработке каталога 1С-Битрикс. Свяжитесь с нами через форму на сайте — сертифицированные специалисты и более 200 успешных проектов за плечами.