Когда headless - плохая идея
Я много пишу про Bitrix + Next.js, headless, Elasticsearch и аккуратную модернизацию старых e-commerce систем.
Но есть важная оговорка: иногда headless - плохая идея.
Не потому что подход слабый. А потому что команда пытается лечить архитектурой проблему, которая живёт в другом месте: в данных, процессах, ожиданиях, SEO, интеграциях или просто в отсутствии владельца решения.
Если этого не проговорить до старта, проект быстро превращается в дорогой способ перенести хаос из одной системы в другую.
1. Вы не знаете, что именно тормозит
Фраза «Bitrix медленный» почти ничего не говорит.
Медленным может быть SQL-запрос. Шаблон компонента. Внешний API доставки. Поиск. Фильтры. 1C-обмен. Неправильный кэш. Картинки. CDN, которого нет. Или checkout, где каждый шаг ходит в три сервиса.
Если команда не видела slow logs, web-vitals, карту запросов и реальные пики нагрузки, headless легко становится дорогой верой.
Сначала диагностика. Потом архитектура.
Иногда после двух дней профилирования выясняется, что не нужен новый фронтенд. Нужны индексы в MySQL, нормальный cache warming и один удалённый синхронный вызов из критического пути.
2. У вас нет владельца данных
Headless делает границы видимыми.
Где название товара: в Bitrix, в 1C, в PIM или в Excel у категорийного менеджера? Кто владеет ценой? Откуда приходит остаток? Какие поля можно кешировать, а какие нельзя? Как обновляется SEO-текст для фильтра?
В монолите этот хаос часто спрятан внутри шаблонов и админки. В headless он становится API-контрактом. И если контракта нет, команда начинает проектировать его на ходу.
Это плохой знак.
До перехода нужен хотя бы компактный data map: источники, владельцы, частота обновления, обязательные поля, fallback, права на изменение. Без этого Next.js просто красиво покажет старую неопределённость.
3. SEO держится на случайных костылях
В e-commerce SEO редко живёт в одном месте.
URL собираются исторически. Фильтры частично индексируются. Canonical когда-то правил подрядчик. Хлебные крошки отличаются от структуры каталога. Старая посадочная страница получает трафик, потому что пять лет назад её вручную добавили в шаблон.
Если это не снять до миграции, headless может ускорить сайт и одновременно убить органику.
Я не драматизирую. Просто SEO-поверхность надо считать частью продукта, а не «потом перенесём мета-теги».
Минимум перед стартом: список URL, правила canonical, sitemap, редиректы, индексируемые фильтры, микроразметка, страницы с трафиком и страницы с деньгами. Без этого rewrite идёт вслепую.
4. Бизнес хочет fixed price, но scope ещё не существует
Для продуктовых форматов fixed price нормален: повторяемый стек, понятные ограничения, известный результат.
Для кастомной модернизации fixed price до discovery часто означает, что риск просто спрятали в красивую таблицу.
В headless-проекте scope зависит от интеграций, данных, ролей, workflow, acceptance criteria, SEO и того, какие части старой системы нельзя трогать. Пока это не разложено, честнее говорить о первом ограниченном work slice, а не о «стоимости переписать сайт».
Хороший первый шаг выглядит скучно:
- Собрать предварительные требования.
- Отделить базовое от optional и client-specific.
- Зафиксировать, что не трогаем в первой итерации.
- Выбрать маленький участок для pilot.
- Измерить результат и workflow.
Скучно - это комплимент. Скучные проекты чаще доходят до production.
5. Команда хочет сменить стек вместо смены процесса
Иногда проблема не в Bitrix.
Нет staging. Нет code review. Нет понятного Git Flow. Нет ответственного за релиз. Нет списка acceptance criteria. Клиент меняет требования в середине спринта, а подрядчик делает вид, что это «мелкая правка».
В такой ситуации Next.js не спасает.
Новый стек даже усилит проблему, потому что появится ещё один runtime, ещё один deploy, ещё один API-контракт и ещё одна зона ответственности.
Headless хорошо работает там, где команда готова к прозрачности: отдельные environments, логирование, rollback, документация, review, понятный владелец решения. Без этого это не modernization. Это новое место для старых привычек.
Когда headless всё-таки имеет смысл
Я не против headless. Наоборот.
Я против headless как замены мышлению.
Подход имеет смысл, когда:
- текущий фронтенд реально тормозит релизы и рост;
- есть большой каталог, поиск, фильтры или контентные сценарии, которые старый монолит держит слишком жёстко;
- команда готова зафиксировать API-контракт;
- SEO-поверхность описана до разработки;
- можно начать с pilot, а не с большого обещания;
- бизнес понимает, какие части старой системы остаются на первом этапе.
Мой любимый формат - не «снести старое». Мой любимый формат - оставить то, что зарабатывает деньги, и вынести то, что мешает расти.
Иногда это Next.js-витрина. Иногда только Elasticsearch-поиск. Иногда BFF-слой перед несколькими фронтендами. Иногда вообще не код, а карта риска и честное решение ничего не переписывать в этом квартале.
Что спросить до первого коммерческого предложения
Если у вас на проекте прозвучало «давайте уйдём в headless», я бы начал с пяти вопросов:
- что именно сейчас не даёт бизнесу выпускать изменения;
- какие страницы и сценарии приносят деньги;
- какие интеграции нельзя останавливать;
- где правда о товарах, ценах, остатках и SEO;
- какой маленький pilot покажет пользу без большого rewrite.
Если ответы есть, можно обсуждать архитектуру.
Если ответов нет, сначала discovery. Не на три месяца и не на сто страниц. Достаточно компактной карты: scope, anti-scope, риски, данные, интеграции, критерии решения.
Это хорошо ложится и на личную работу senior engineer, и на формат WGP: короткий audit/pilot вместо ставки вслепую. Если вы смотрите на старый Bitrix или PHP-проект и не уверены, нужен ли там headless, начните с этого списка. А уже потом выбирайте стек.
Связанное чтение: перед rewrite Bitrix я сначала считаю риск, первые 15 минут аудита проблемного проекта, pilot как следующий шаг WGP.