Что такое headless CMS: сравнение Strapi, Sanity и Payload
Основы4 минРедакция Innovialabs
Коротко
Headless CMS хранит и редактирует контент, но не отвечает за его отображение — сайт, приложение или бот получают данные через API; это даёт свободу во фронтенде ценой более сложной разработки.
Коротко: что такое headless CMS
Headless CMS — система управления контентом без встроенного «лица» (head), то есть без шаблонов и тем для отображения. Она делает две вещи:
- даёт редакторам админку для создания и правки контента;
- отдаёт этот контент через API (REST или GraphQL).
Как именно контент будет выглядеть, решает отдельное приложение: сайт на Next.js или Nuxt, мобильное приложение, Telegram-бот, экран в торговом зале.
В традиционной CMS (например, WordPress в классическом режиме) контент и отображение живут в одной системе: тема сама рендерит страницы.
Как это устроено
- Разработчик описывает модели контента: «Статья» с заголовком, текстом, обложкой и автором; «Услуга» с ценой и описанием.
- Редактор заполняет записи в админке.
- Фронтенд запрашивает данные через API и рендерит их своим кодом.
- При изменении контента CMS может отправить webhook, чтобы сайт пересобрал или обновил нужные страницы.
Плюсы и минусы
| Headless CMS | Традиционная CMS | |
|---|---|---|
| Свобода дизайна и фронтенда | Полная | В рамках темы |
| Один контент для нескольких каналов | Да | Сложно |
| Производительность | Легко сделать статический или кешированный фронтенд | Требует настройки кеша |
| Предпросмотр страницы | Нужно настраивать | Из коробки |
| Порог входа | Нужны разработчики фронтенда | Можно запустить без кода |
| Число движущихся частей | Больше: CMS, фронтенд, хостинг для обоих | Меньше |
Когда подходит headless:
- сайт делается на современном фреймворке с уникальным дизайном;
- один и тот же контент нужен на сайте, в приложении и в боте;
- важна скорость и контроль над фронтендом;
- есть команда разработчиков для поддержки.
Когда лучше традиционная CMS:
- нужен простой сайт, который редакторы собирают сами;
- нет ресурсов на отдельную фронтенд-разработку.
Strapi, Sanity и Payload: короткое сравнение
| Strapi | Sanity | Payload | |
|---|---|---|---|
| Модель | Open source, self-hosted или облако | Облачное хранилище контента, редактор Studio — open source | Open source, self-hosted или облако |
| Технологии | Node.js | Контент в облаке Sanity, Studio на React | Node.js и TypeScript, тесная интеграция с Next.js |
| Как описывается схема | Через админку или файлы | В коде (JavaScript/TypeScript) | В коде (TypeScript) |
| API | REST и GraphQL | Собственный язык запросов GROQ и GraphQL | REST, GraphQL и локальный API |
| База данных | Ваша (PostgreSQL, MySQL, SQLite и др.) | Управляется Sanity | Ваша (PostgreSQL, MongoDB и др.) |
| Сильная сторона | Быстрый старт, визуальный конструктор моделей | Совместное редактирование в реальном времени, гибкая Studio | Контроль кода, типизация, удобство для разработчиков |
Strapi
Подходит, если нужна понятная админка и возможность собрать модели контента мышкой. Вы сами хостите сервер и базу — это даёт контроль над данными, но и ответственность за обновления и бэкапы.
Sanity
Контент хранится в облаке Sanity, а редактор Sanity Studio гибко настраивается кодом. Хорош для редакций и маркетинга, где несколько человек работают одновременно. Нужно учитывать, что данные лежат у внешнего провайдера, а стоимость зависит от тарифа и объёма использования.
Payload
CMS, «написанная для разработчиков»: схема и логика описываются на TypeScript, а сам Payload может работать внутри приложения на Next.js. Удобно, когда команде важны типы, контроль доступа и кастомная бизнес-логика рядом с контентом.
Как выбрать
- Где должны лежать данные? Если важно хранить их на своём сервере — Strapi или Payload.
- Кто описывает модели? Если менеджеры — удобнее Strapi; если разработчики в коде — Sanity или Payload.
- Какой у вас фронтенд? Для Next.js-проекта Payload даёт тесную интеграцию; остальные тоже работают через API.
- Нужно ли совместное редактирование? Здесь сильна Sanity.
- Кто будет поддерживать? Self-hosted решения требуют DevOps: обновления, бэкапы, мониторинг.
Частые ошибки
- Выбирать headless только потому, что это модно, для простого сайта-визитки.
- Забыть про предпросмотр — редакторы не видят результат до публикации.
- Не продумать модели контента заранее и потом переделывать их на живых данных.