← Назад в блог

Пять вопросов, которые я задаю перед тем, как предложить headless

За последние два года я трижды отговорил клиента от headless-миграции. Не потому что headless плохой — я люблю его строить и видел, что он даёт. А потому что ответы на пять вопросов делали результат очевидным ещё до того, как мы открывали Figma. В четвёртый раз ответы были другими, и проект получил полноценный Next.js + Bitrix на бэкенде. Сейчас это один из лучших ecom-проектов, с которыми я работал.

Вот пять вопросов, которые я задаю всегда — до того, как предлагать headless клиенту.

Почему «нам нужен headless» — почти всегда неточный запрос

Когда клиент или продакт-менеджер говорит «нам нужен headless», за этим обычно стоит что-то другое:

  • сайт тормозит и это раздражает
  • конкурент сменил дизайн за неделю, а у нас это занимает месяц
  • разработчики жалуются, что CMS мешает им работать
  • кто-то прочитал статью про Netflix или Airbnb

Ни одна из этих проблем не решается переходом на headless автоматически. Тормоза чаще оказываются в кэше и запросах к БД. Медленные релизы — это проблема процессов и архитектуры деплоя, а не CMS. Жалобы разработчиков могут быть про headless, а могут быть про технический долг или про что-то третье.

Headless — это архитектурное решение со своей ценой: отдельный frontend-деплой, API-контракт между системами, новые точки отказа. Эта цена оправдана, когда ответы на пять вопросов складываются в одну сторону.

Вопрос 1. Как часто фронтенд меняется независимо от контента?

Главный аргумент в пользу headless — возможность менять UI без касания CMS. Дизайн-система обновилась, вышла новая версия компонентов — фронтенд катится отдельно, CMS не трогаем.

Это реальное преимущество. Но только если такие обновления происходят регулярно.

Если фронтенд меняется раз в квартал, а между релизами команда всё равно работает в Bitrix или другой CMS — польза от разделения сомнительная. Деплой-независимость нужна там, где она используется. Я видел проекты, где headless-архитектуру построили «на вырост», а за два года фронтенд не катили отдельно ни разу. Зато API-контракт ломался дважды.

Честный вопрос: «Покажите мне последние 10 деплоев фронтенда. Сколько из них требовали изменений в CMS?» Если ответ «все» или «почти все» — headless здесь не помогает.

Вопрос 2. Есть ли выделенная frontend-команда — или план её нанять?

Headless требует отдельного frontend-разработчика или команды. Не полного стека, который умеет немного в React, — а человека, который живёт в Next.js, понимает SSR, ISR, edge caching и умеет дебажить гидрацию.

Это не снобизм. Это цена архитектуры.

На монолите один разработчик может двигаться по всему проекту — PHP-шаблоны, логика, контент. На headless у тебя два отдельных домена: backend-API и frontend-приложение. Переключаться между ними — дорого.

Если у клиента два разработчика на весь проект и бюджет на найм не предусмотрен — headless удвоит стоимость поддержки. Проект, который я отказался переписывать за $40K, выглядел именно так: команда из двух человек, которая взяла бы на себя и API, и frontend, и поддержку Bitrix.

Вопрос 3. В чём конкретная боль текущей CMS — и headless её лечит?

Это самый важный вопрос. И чаще всего на него не отвечают честно.

Попросите клиента назвать три конкретные проблемы, которые они хотят решить миграцией. Потом пройдитесь по каждой.

Сайт тормозит. Headless может помочь, если тормоз в рендеринге PHP-шаблонов. Но если проблема в запросах к БД или в неправильно настроенном кэше — headless ничего не изменит. Нужен профайлер, не новая архитектура.

Сложно вносить изменения в UI. Если причина в запутанной Bitrix-разметке — headless решает. Если причина в накопленном за годы плохом коде — headless перенесёт эту боль в другое место.

Разработчики хотят современный стек. Это не бизнес-аргумент. Иногда за этим стоит реальная проблема с наймом или скоростью разработки. Иногда — просто желание сменить инструмент.

Хороший симптом для headless: «Редакторы публикуют контент в CMS, а мы хотим показывать его в мобильном приложении, на сайте и в киоске одновременно». Headless — это про decoupling контента от представления. Если этой задачи нет — и выгоды нет.

Вопрос 4. Готовы ли к 3-6 месяцам замедления на переходе?

Headless-миграция — это параллельная разработка двух систем. Старый сайт должен продолжать работать, пока строится новый. Это значит: часть команды занята «старым», часть — «новым». Фичи тормозят.

На реальном проекте с 28 000 SKU мы оценивали переход в 6 недель для каталога и поиска. Но это только потому, что мы заранее приняли решение: checkout и личный кабинет остаются на старых Bitrix-шаблонах. Полный rewrite занял бы 6 месяцев, если не больше.

Вопрос не «можете ли вы себе позволить headless». Вопрос «можете ли вы себе позволить следующие полгода работать в режиме строительства, пока конкуренты не стоят».

Если у клиента горячий сезон через три месяца — headless сейчас плохая идея.

Вопрос 5. Кто будет владеть API-контрактом через два года?

API между Bitrix и Next.js — это живой артефакт. Он меняется с каждой новой фичей: добавили поле в карточку товара, изменили структуру категорий, поменяли логику цен. Кто будет делать эти изменения синхронно на обоих концах?

На фазе проекта это звучит как детали. Через два года это становится главным источником боли.

Я видел проекты, где исходная команда построила API-слой, а потом ушла. Новая команда добавила поля в Bitrix, не зная, что они используются на фронте. Фронт сломался в продакшене. Такие инциденты чинятся долго.

Если на вопрос «кто через два года будет отвечать за этот контракт» ответа нет — headless будет кому строить, но некому поддерживать.

Когда headless — правильный ответ

Я не против headless. Я против headless по умолчанию.

Когда ответы на пять вопросов складываются в нужную сторону — headless даёт реальный выигрыш:

  • Frontend меняется независимо от контента и это происходит часто
  • Есть выделенная команда, которая умеет работать с современным JS-стеком
  • Конкретная боль (скорость рендеринга, multi-channel, deploy-независимость) прямо решается headless-архитектурой
  • Команда готова к переходному периоду и не связана жёстким дедлайном
  • Понятно, кто будет владеть API-контрактом в долгосроке

На проекте с 28 000 SKU все пять ответов были правильными. Поэтому мы пошли в headless. LCP упал с 4.2s до 1.4s, конверсия на мобайле выросла на 23%, и за два года ни один деплой фронта не ронял бэкенд.

Когда headless — это плохая идея, я говорю об этом честно. Когда это правильный ответ — тоже.

Пять вопросов дают материал для этого разговора. До Figma.