Headless CMS продають як обов’язковий крок у «сучасну архітектуру». Насправді це компроміс: ви отримуєте швидкий фронтенд і нормальний API, а платите другим сервісом в інфраструктурі, складнішим прев’ю й вищим порогом входу для редактора. Нижче — як воно влаштоване технічно, у яких сценаріях реально окупається, коли перетворюється на зайве ускладнення, і чим популярні рішення відрізняються за вартістю володіння, а не за маркетинговою сторінкою.

Що таке headless і чим воно відрізняється від звичайної CMS

Класична CMS — це три речі в одній коробці: база контенту, адмінка й шаблони, які перетворюють контент на HTML. Headless прибирає третю частину. Лишається сховище та адмінка, а назовні вони віддають контент структурованим JSON через API. Що з цим робити далі — справа фронтенду: зібрати сайт на Next.js, віддати той самий текст у мобільний застосунок або на екран у шоурумі.

1. 1

   Редактор публікує матеріал

   В адмінці він бачить не сторінку, а поля: заголовок, анонс, галерея, ціна, теги. Поля описані схемою, тож зламати верстку неможливо в принципі — її тут просто немає.

2. 2

   Контент стає доступним через API

   CMS віддає структуровані дані по REST або GraphQL. Той самий запис одночасно доступний для сайту, застосунку, розсилки й будь-якої зовнішньої системи, яка вміє ходити по HTTP.

3. 3

   Фронтенд забирає дані й будує сторінки

   Або під час збірки, або за першим запитом із подальшим кешуванням. Це ключовий момент: користувач отримує вже готовий HTML, а не результат запиту до бази в реальному часі.

4. 4

   CDN віддає готове

   Сторінка лежить на межі мережі, поруч із користувачем. Звідси й типова відповідь за 100–300 мс без жодного кешувального плагіна — кешувати просто нічого, все вже статичне.

// Один і той самий запис — для сайту, застосунку й розсилки.
// revalidate тримає сторінку статичною, але не старшою за годину.
const post = await fetch(
  `${CMS_URL}/api/posts?slug=${slug}&locale=${locale}`,
  { next: { revalidate: 3600 } },
).then((r) => r.json());

Що це реально дає бізнесу

• Швидкість без боротьби. Сторінка віддається статикою, тому Core Web Vitals виходять зеленими за замовчуванням, а не після трьох ітерацій оптимізації плагінів.
• Один контент — багато каналів. Каталог, який ви ведете в CMS, годує сайт, застосунок, прайс для маркетплейсу й імпорт для партнера. Без копіювання вручну й без розбіжностей у цінах.
• Редизайн без переїзду контенту. Фронтенд можна переписати з нуля, не торкаючись бази. Це економить 30–50% бюджету наступного редизайну — контент і структура лишаються на місці.
• Менша поверхня атаки. Немає публічної адмінки на відомій адресі й немає плагінів із правами на запис у файли сайту. Сама CMS живе за окремим доменом і закрита автентифікацією.
• Реальна багатомовність. Локалі — це поле в схемі, а не третій плагін поверх двох попередніх. Що з цим робити далі, ми розбирали в матеріалі про багатомовні сайти.

Коли headless — зайве ускладнення

Це та частина, яку зазвичай не пишуть. Headless має цілком реальну ціну, і найчастіше її платять проєкти, яким вона не потрібна. Ознаки, за яких ми самі відмовляємо клієнту в headless.

Найболючіший пункт — прев’ю. У звичайній CMS редактор натискає «Переглянути» і бачить сторінку. У headless прев’ю треба окремо реалізувати на фронтенді, і зроблене абияк воно перетворює редакторську роботу на гру в вгадайку. Закладайте на це 8–16 годин розробки одразу, інакше через місяць отримаєте «поверніть нам як було». Загальне порівняння двох підходів за витратами є в розборі Next.js проти WordPress.

Рішення, які реально доходять до продакшена

Практичне правило вибору: якщо у вас немає людини, яка відповідає за сервери, беріть хмарне рішення й закладайте підписку в бюджет. Якщо є вимога тримати дані у себе або ви вже платите за VPS — self-hosted дешевший на дистанції, але переносить на вас оновлення й резервне копіювання. Ці години теж треба порахувати, і найчесніше зробити це разом із річним бюджетом підтримки.

Скільки це коштує і як ухвалити рішення

На старті headless дорожчий приблизно на 20–35% від вартості аналогічного сайту на звичайній CMS. Різниця йде на опис схем контенту, налаштування прев’ю, окреме середовище для CMS і зв’язування двох частин. Далі математика розвертається: наступний редизайн коштує менше, додавання каналу коштує майже нічого, а щомісячні витрати на плагіни зникають.

1. 1Порахуйте канали. Один — беріть звичайну CMS. Два й більше або застосунок у планах на рік — headless виправданий.
2. 2Порахуйте частоту публікацій. До десяти оновлень на місяць різниці не відчуєте; від сотні — структуровані поля економлять редактору години.
3. 3Перевірте, хто підтримуватиме сайт. Без постійного розробника self-hosted headless стає покинутим сервісом за пів року.
4. 4Заплануйте прев’ю та ролі доступу на етапі кошторису, а не «додамо потім». Потім це коштує вдвічі дорожче.
5. 5Зафіксуйте формат експорту контенту в договорі. Головна перевага підходу — переносність, і вона має бути записана, а не малась на увазі.

Часті питання про headless CMS

Коротко

• Headless розділяє сховище контенту й фронтенд: контент віддається як структурований JSON, сторінки збираються заздалегідь і лежать на CDN.
• Підхід окупається за двох умов: контент іде більш ніж в один канал або обсяг публікацій достатньо великий, щоб структуровані поля економили час.
• На старті це на 20–35% дорожче, натомість наступний редизайн і додавання каналів коштують суттєво менше.
• Прев’ю, ролі доступу й формат експорту контенту треба закласти в кошторис одразу — це три речі, через які проєкти повертаються назад на звичайну CMS.