← Назад в блог

Как понять, что вы реально упёрлись в потолок Bitrix — а не просто устали от него

Недавно мне написал клиент. Интернет-магазин, 30 тысяч SKU, Bitrix, «всё тормозит». Хотят уйти на headless. Я спросил: какой процент запросов превышает 2 секунды? Включён ли composite-режим? Смотрели slow_query_log за последние три месяца?

Тишина.

Они хотели мигрировать с Bitrix не потому что упёрлись в технический потолок. А потому что устали от него. Это два разных диагноза. Разница в деньгах — $200K и полтора года работы.

Усталость и потолок — это разные вещи

Усталость от Bitrix бывает разная. Интерфейс администратора не менялся с 2010. ORM генерирует запросы, которые сложно отлаживать. Новые разработчики морщатся. Реальный дискомфорт, но он не требует смены архитектуры.

Технический потолок — это другое. Это когда задача бизнеса невыполнима в текущей архитектуре, сколько бы хорошо ты её ни настраивал.

5 признаков, что вы реально упёрлись в ограничение Bitrix

Это структурные проблемы. Настройки здесь не помогут.

  1. Composite cache miss выше 30% при включённом composite-режиме. Если статика не кешируется при правильной конфигурации — архитектура страницы несовместима с composite. Bitrix не виноват, но и не поможет.
  1. MySQL slow_query_log фиксирует запросы к каталогу дольше 3 секунд — даже с правильным OPcache и Redis. Проблема в структуре данных или логике ORM, которую на Bitrix-уровне индексами не закрыть.
  1. N+1 на iblock PROPERTY_* JOIN не лечится индексами. Если на странице категории из 400 SKU запрос идёт сначала к основной таблице, потом к properties — это архитектурный паттерн Bitrix, а не баг конфигурации. На 28k SKU проекте мы видели 40 SQL-запросов на одну страницу. Индексы делали их быстрее, но не убирали.
  1. 1С-синхронизация блокирует checkout более 30 минут в сутки на каталогах от 10k SKU. Если импорт из 1С держит таблицы заблокированными, пока обновляет остатки — это не проблема настроек. Это отсутствие деплой-изоляции между бэкендом и фронтом.
  1. LCP выше 4 секунд, и деплой PHP-обновления Bitrix затрагивает фронт. Фронт и бэк деплоятся вместе. Это исправить настройками нельзя.

Если узнали хотя бы один из этих пунктов — разговор про headless начинает иметь смысл.

5 признаков, что сначала надо оптимизировать

Большинство обращений с «нужен headless» заканчиваются здесь.

  1. OPcache не настроен. validate_timestamps включён (убивает кеш на каждый запрос), pm.max_children на дефолте от ISPmanager. Я видел сервер с pm.max_children=5 на магазине с 3000 товарами — TTFB 8-12 секунд. После правки: 1.1 секунды. Ни одной строки кода не тронули.
  1. Composite-режим выключен. Пробовали включить? На правильно настроенном Bitrix composite-кеш убирает PHP со статических страниц полностью.
  1. slow_query_log не смотрели дольше трёх месяцев. Нет данных — нет диагноза. Включите, дайте поработать неделю, и только потом разговаривайте про архитектуру.
  1. PHP-сессии файловые. Под нагрузкой это 127 из 128 FPM-воркеров, ждущих файловых блокировок. Я видел это в продакшне в 23:00 во время промоакции: 504 ошибки 1100 в час. После переключения на Redis-сессии — ноль.
  1. Нет понимания разницы TTFB и LCP. Лечат LCP, не зная, что он складывается из TTFB и render-блокирующих ресурсов. Или наоборот — TTFB хороший, но тяжёлый JS убивает LCP. Миграция без этой диагностики просто перенесёт проблему в новую архитектуру.

Кейс: 28 000 SKU, где headless был единственным ответом

На проекте с 28k SKU мы получали 40 SQL-запросов на страницу категории. OPcache был настроен правильно. Composite работал. MySQL slow_query_log чистый на запросах к одному товару. Проблема была в структуре: Bitrix ORM при загрузке списка с PROPERTY_* JOIN физически не мог работать иначе при таком объёме данных.

Мы перешли на headless: Next.js как фронт, Bitrix как REST API backend. LCP упал с 4.2s до 1.4s. Мобильная конверсия выросла на 23%. Деплой фронта перестал затрагивать бэкенд: security-патч Bitrix — 40 минут, фронт при этом живёт без перезагрузки. Это история, с которой начался отказ от $40K-контракта на переписку.

Правильный headless. Не потому что «так модно», а потому что другого способа не было.

Кейс: клиент с 30 000 SKU, которого я отговорил

Тот же запрос. «30 тысяч SKU, Bitrix тормозит, хотим headless.» Прошли диагностику.

pm.max_children стоял на 5 — значение по умолчанию от хостинга. Мы подняли до 38 (по реальному потреблению памяти). Добавили Redis-сессии. Починили OPcache validate_timestamps. TTFB упал с 2.1s до 0.4s. 504 ошибок стало ноль.

Никакой миграции. Три дня работы. Три строки конфига.

Клиент сэкономил полтора года и несколько сот тысяч рублей. Я потерял потенциальный контракт на migration. Но это был правильный ответ. Подробнее об этих же настройках — в статье о том, почему Bitrix не тормозит, а тормозит то, как с ним работают.

Три вопроса до разговора про миграцию

Перед тем как обсуждать архитектуру и стек — ответьте честно на три вещи.

Что конкретно бизнес не может делать прямо сейчас — и почему это требует смены архитектуры, а не оптимизации?

OPcache, composite-режим и Redis-сессии включены и настроены? Если нет — начинаем там.

Сколько стоит полтора года, пока идёт migration? Команда, продакшн-риски, заморозка фич. Это реальная цена даже правильного решения.

Иногда ответ — headless. Иногда — три строки в php-fpm.conf. Правильный диагноз важнее быстрого решения.

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