← Назад в блог

Когда headless — это плохая идея

Я строю headless-сайты на Next.js + Bitrix уже несколько лет. Мигрировал каталог на 28 000 SKU. Отказался от $40K-контракта, потому что переписывать монолит там не имело смысла. И когда клиент приходит с запросом «хотим headless», первый вопрос всегда один: «А почему именно headless?»

Когда не нужен headless — это разговор, который в индустрии почти не ведут. Все пишут про преимущества. Про скорость. Про гибкость стека. Мало кто пишет про два деплой-пайплайна, которые нужно поддерживать синхронно. Про API contract, который ломается, когда Bitrix-разработчик меняет поле в инфоблоке, не предупредив фронтенд-команду. Про CMS-редакторов, которые неделю не могут разобраться без WYSIWYG.

Что на самом деле стоит headless-переход

Headless — это не просто «Next.js вместо PHP-шаблонов». Это:

  • Два деплой-пайплайна: бэкенд (PHP/Bitrix) и фронтенд (Next.js/Vercel или свой сервер)
  • API contract между командами — документ или соглашение, которое надо поддерживать актуальным
  • Edge caching с инвалидацией: ISR, revalidate tags или webhooks при каждом изменении контента
  • Новый слой для редакторов: они больше не нажимают «Сохранить и опубликовать», они постят в headless CMS и ждут ребилда

По опыту: это от 3 до 6 дополнительных часов в неделю на поддержку в первые полгода. Без учёта времени на onboarding команды.

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

5 ситуаций, когда headless вас убьёт, а не спасёт

Первый признак: команда без выделенного фронтенда

Headless требует двух человек с разными компетенциями, или одного очень широкого. Если оба в команде знают PHP и кто-то из них «немного умеет React» — это не то же самое. TypeScript, SSR, hydration, edge caching, CI/CD для двух репозиториев — каждый навык требует практики. Иначе получите: Next.js шаблоны пишет PHP-разработчик, который гуглит каждую третью строку. А потом уходит в отпуск.

Второй признак: бюджет есть на миграцию, нет на поддержку

Самая частая ошибка. Клиент выделяет деньги на migration project, но не закладывает поддержку двух систем после. Через полгода приходит вопрос: «А почему у нас сейчас два сервера, два CI/CD и два разработчика вместо одного?» Ответ простой. Потому что headless. Если maintenance budget не вырос, переход не окупился.

Третий признак: редакторы живут в WYSIWYG

Bitrix, WordPress, 1С-контент — в них сидят редакторы, которые научились жить в визуальном редакторе. Headless CMS переносит их в structured content workflow: поля, блоки, preview через API. Одни привыкают за пару недель. Для других это катастрофа производительности. Прежде чем менять стек, поговорите с редакторами.

Четвёртый признак: SEO не измеряется

Главный аргумент за headless с точки зрения SEO — контроль над LCP, CLS, рендерингом. Это работает. Но только если SEO реально измеряется, оптимизируется и есть ответственный. Если SEO «ну да, важно» — монолит с нормальным кэшированием даст достаточный результат. Headless без SEO-дисциплины дорого стоит при том же итоге.

Пятый признак: малый каталог без динамики

Headless даёт максимальный эффект на больших каталогах с динамическим контентом, A/B-тестами, персонализацией. Если у вас 300 товаров, статичная структура и никакого CDN-edge — хватит PHP с нормальным кэшем. Я сам видел Bitrix-магазины на 400 SKU с LCP 1.4s. Без Next.js.

Как понять, что headless окупится именно у вас

Три вопроса. Если все три «да» — начинайте считать ROI. Хотя бы одно «не уверен» — стоп.

  1. Есть ли в команде (или в бюджете) выделенный фронтенд-разработчик с опытом SSR/Next.js?
  2. Будет ли через год поддерживаться два деплой-пайплайна — с документацией, дежурством и ответственным?
  3. Есть ли измеримый бизнес-KPI, который headless улучшит: LCP < 2s, конверсия, индексируемость?

Если хотя бы на один вопрос «не уверен» — это уже сигнал.

Что делать вместо headless

Есть варианты, которые работают без второго репозитория.

Оптимизация монолита

Кэширование композитных страниц в Bitrix, вынос статики на CDN, правильные индексы в базе — это даёт 60–80% прироста производительности. Подробнее — как Bitrix не тормозит.

Частичный headless

Только каталог переводится на Next.js, остальное остаётся в монолите. Один API endpoint, один пайплайн. Это то, что я предложил вместо полного rewrite в кейсе на $40K. Разбор там. Подробнее о том, когда headless оправдан именно из-за независимости деплоя — отдельный разбор.

SSI и edge caching

Если проблема в скорости, иногда достаточно вынести тяжёлые блоки на Edge и подключить Server-Side Includes. Не headless, но и не классический монолит без CDN.

Итог

Headless — хороший инструмент. Я его использую и рекомендую.

Но только когда команда, бюджет и бизнес-KPI это поддерживают. В остальных случаях это дополнительная сложность без отдачи.

Если сейчас на проекте звучит «надо на headless» — проверьте пять признаков выше. Один честный разговор до старта дешевле, чем разворот через полгода.