Что 28 000 SKU научили меня про Bitrix
Я зашёл в проект с предубеждением.
28 000 SKU на Bitrix — звучало как «мы будем страдать». N+1 в инфоблоках. Тормозящий торговый каталог. Запросы в базу на каждый чих. Я готовился к боли.
Через три месяца написал коллеге: «Bitrix реально умеет в каталоги».
Это не реклама CMS. Это разбор того, что я увидел внутри, и почему мои ожидания оказались неправильными.
Что я ожидал — и почему ошибся
Я пришёл из Next.js-экосистемы. Для меня Bitrix ассоциировался со старым PHP, медленными шаблонами и архитектурой «всё в одном файле». Услышав цифру 28 000 позиций, я автоматически перешёл в режим «как выживем».
Ожидал медленных выборок из инфоблоков: Bitrix ORM умеет делать JOIN'ы, которые выглядят страшно в SQL-логах, и на 28k SKU казалось, что каждая страница каталога будет вытаскивать всё. Ещё ожидал полного отсутствия кэширования на уровне элементов — думал, что буду вручную строить Redis-слои поверх всего. И фасеты — 28 000 позиций это сотни характеристик, сложная иерархия. На PHP казалось нереальным делать это быстро.
Реальность оказалась сложнее.
Как Bitrix устроен для большого каталога
Инфоблоки в Bitrix — не просто таблица товаров. Это система с отдельными сущностями под свойства, торговый каталог, ценообразование, склад. Она избыточная — но избыточность осмысленная.
Первое, что удивило: встроенный механизм кэширования элементов инфоблока. При правильной конфигурации Bitrix сам кэширует результаты выборок в файловый кэш или memcached. Мне не пришлось строить это с нуля.
Второе: HighLoadBlock — отдельный механизм для высоконагруженных таблиц. Мы перенесли туда историю цен и агрегированные данные по остаткам. Запрос, который раньше ждал 800ms, стал отвечать за 90ms.
Третье: торговый каталог Bitrix умеет в множественные ТП (торговые предложения) из коробки. Для вариаций по размеру, цвету, комплектации — не нужно изобретать структуру данных. Она уже есть, и 1С синхронизируется с ней без кастомных маппингов.
Я ожидал, что всё это придётся строить самому. Оказалось — не придётся.
Три вещи, которые Bitrix делает правильно
Синхронизация с 1С. На проектах с другими CMS я видел, как команды тратили месяцы на интеграцию с 1С: кастомный API, трансформации данных, reconciliation. В Bitrix этот канал встроен. Товары, цены, остатки приходят из 1С по протоколу CommerceML. Нам потребовалась неделя на настройку, а не три месяца на разработку.
Права доступа на уровне раздела каталога. Для 28k SKU с разными категориями, партнёрскими ценами и оптовыми прайсами это критично. Bitrix разграничивает доступ к инфоблокам на уровне групп пользователей без дополнительного кода. Мы настроили три ценовых уровня за день.
Нативный поиск для умеренных нагрузок. До Elasticsearch мы тестировали встроенный поиск Bitrix на полутора тысячах запросов. Для каталога без сложного ранжирования и синонимов он справлялся. Elasticsearch понадобился только когда пошли no-results запросы и нужен был fuzzy-matching.
Я не говорю, что Bitrix идеален. Я говорю, что он делает эти три вещи хорошо — и для e-commerce-каталога это важные вещи.
Где headless помог, а где был лишним
Headless принёс реальную пользу в двух местах.
Первое — деплой фронта без зависимости от Bitrix. Пока бэк обновлялся с FTP за 40 минут, фронт на Next.js деплоился за 3. Это убрало страх перед любыми обновлениями CMS: они не ронят фронт. Страница каталога, которая тормозила 4.2 секунды по LCP, после SSR + CDN стала отдавать за 1.4s.
Второе — гибкость рендеринга. ISR (Incremental Static Regeneration) позволила кэшировать страницы категорий и отдавать их с edge. Bitrix выступал чистым API — 12 REST-эндпоинтов под каталог, поиск, корзину.
Где headless оказался лишним. Оформление заказа мы оставили на Bitrix-шаблонах. Конверсия была 3.8%, бизнес не хотел рисковать. Next.js там не дал бы прироста, а разработки потребовал бы на два месяца больше. Правильное решение — оставить.
Checkout на шаблонах Bitrix — осознанный выбор, не техдолг.
Что я бы сделал иначе
Мы слишком поздно подключили HighLoadBlock. Первые два месяца проект работал на стандартных инфоблоках под статистику. Это создавало задержки на аналитических запросах. Надо было вынести агрегаты в HighLoadBlock с первого дня.
Ещё — Elasticsearch мы подключали параллельно с запуском, под давлением сроков. Это было сложнее, чем если бы мы закладывали поисковый слой с самого начала. Следующий раз начну с ES сразу, не как надстройку.
И последнее: я потратил две недели на попытки обойти кэш инфоблоков, думая что он плохо работает. Оказалось, что я неправильно сбрасывал его при изменениях в 1С. Документация Bitrix в этой части неочевидна — но решение простое, если понять логику тегов кэша.
Итог
28 000 SKU на Bitrix — это не страдание. Это работа с системой, которая проектировалась под e-commerce.
Я пришёл с предубеждением разработчика, который привык к более «чистым» фреймворкам. Вышел с пониманием: у Bitrix есть своя логика, и когда её знаешь — она работает.
Headless здесь не замена Bitrix. Это слой, который берёт на себя рендеринг и деплой фронта — и добавляет свою сложность в API-контракт, в кэш-инвалидацию, в локальную разработку. Вопрос всегда в том, где проходит граница ответственности каждого слоя.
На 28k SKU мы эту границу нашли.