Что такое headless CMS и почему компании переходят на неё?

Традиционная система управления контентом (самый известный пример — WordPress) выполняет сразу две задачи: хранит ваш контент и с помощью собственной системы шаблонов определяет, как этот контент будет выглядеть на веб-странице. Headless CMS разделяет эти задачи. Она по-прежнему даёт редакторам место, где можно писать и упорядочивать контент, но отдаёт этот контент через API в виде структурированных данных, никак не определяя, как и где он будет отображаться. Саму страницу — на сайте, в мобильном приложении, на умном экране в магазине, в голосовом помощнике — собирает совершенно отдельное приложение, созданное на той фронтенд-технологии, которая лучше всего подходит для задачи.

Почему «безголовость» — это плюс

Слово headless («безголовая») описывает то, чего не хватает, а не то, что добавлено: здесь нет встроенной «головы», то есть слоя шаблонов по умолчанию, жёстко привязанного к контенту. Это кажется недостатком, пока вы не окажетесь в команде, которая пытается переиспользовать контент на сайте, в мобильном приложении и во встраиваемом виджете партнёра, причём из CMS, изначально рассчитанной только на выдачу готовых HTML-страниц для одного сайта. В headless-архитектуре один и тот же материал, написанный один раз, может питать все три канала: каждый из них просто обращается к API и отображает ответ так, как ему нужно.

Что вы получаете

Свободу на фронтенде. Веб-команда может работать с любым фреймворком, подходящим для продукта, а не быть запертой в языке шаблонов и экосистеме плагинов конкретной CMS.
Один источник контента — много каналов. Напишите материал один раз и показывайте его на сайте, в мобильном приложении, на цифровых экранах или в интеграции с партнёром из одного источника.
Более высокую производительность и безопасность по умолчанию. Поскольку публичные страницы часто отдаёт не сама CMS, значительная часть поверхности атаки — медленные плагины и уязвимости, характерные для конкретной CMS, — просто не попадает в зону, открытую посетителям.
Редакторы сохраняют интерфейс, созданный для работы с текстом, а не для борьбы с кодом: большинство headless-платформ по-прежнему дают нетехническим специалистам удобный и продуманный редактор, просто не привязывают его к тому, как будет отображаться результат.

Чем приходится жертвовать

Компромисс в том, что headless CMS по своей природе — лишь половина системы: чтобы что-то отобразить, нужно отдельное фронтенд-приложение, а это реальная инженерная работа, которой не требует традиционная CMS со встроенными темами. Предпросмотр — возможность увидеть, как страница будет выглядеть до публикации, — требует больше усилий для настройки, ведь сама CMS понятия не имеет, как выглядит итоговая страница. А некоторых привычных удобств традиционных CMS, например маркетплейса плагинов с готовым решением почти для любой задачи, здесь в том же виде просто нет, потому что фронтенд создаётся индивидуально.

Когда переход действительно оправдан

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

Как принять честное решение

Оцените, в скольких местах ваш контент действительно должен присутствовать сегодня и, реалистично, в ближайшие год-два, а не гипотетически. Одно место, невысокая сложность контента — традиционной CMS обычно достаточно, а переход стал бы решением проблемы, которой у вас пока нет. Несколько каналов, модель контента, переросшая одну систему шаблонов, или фронтенд-команда, которой нужна свобода от ограничений конкретной CMS, — вот тогда headless-архитектура начинает окупать свою дополнительную сложность.

Выстраивание такой архитектуры контента — с решением, что должно жить в CMS, а что во фронтенд-приложении, которое этот контент использует, — частая часть проектов по веб-разработке, которые мы берём в Burncode, особенно для компаний, которые уже переросли единственный сайт на традиционной платформе.