Headless CMS: Strapi, Directus, Sanity, Contentful, Drupal
Традиционная CMS хороша до момента, когда дизайнер говорит «хочу анимацию при скролле с parallax», фронтенд — «нам нужен React», а SEO-специалист — «почему TTFB 3.4 секунды». В этот момент монолитная архитектура начинает мешать всем сразу.
Headless CMS отделяет управление контентом от его представления. Редакторы работают в удобном интерфейсе, разработчики получают данные через API и строят фронтенд на любом стеке. Звучит просто. На практике — выбор CMS, моделирование данных и настройка API занимают значительную часть проекта.
Выбор инструмента под задачу
Нет универсальной headless CMS. Выбор зависит от команды, сложности контента и инфраструктуры.
Strapi — open-source, self-hosted, Node.js. Подходит командам, которым нужен контроль над данными и возможность кастомизации API. Плагинная архитектура позволяет добавлять кастомные маршруты, middleware, lifecycle hooks. REST и GraphQL из коробки. Слабое место — Strapi v4 и v5 несовместимы между собой, миграция болезненная.
Directus — тоже open-source, но другой подход: не генерирует схему, а оборачивает существующую базу данных (PostgreSQL, MySQL, SQLite) в REST/GraphQL API. Если база данных уже есть — Directus подключается к ней без миграций. Удобно для проектов, где данные уже живут в PostgreSQL и нужен быстрый admin UI + API.
Sanity — облачная CMS с real-time редактором. Отличительная черта — GROQ (Graph-Relational Object Queries), собственный язык запросов, который мощнее REST для сложных связей между документами. Portable Text для структурированного контента. Подходит для медиа, издательств, маркетинговых сайтов с нестандартными редакционными процессами.
Contentful — enterprise облачная CMS. Сильная сторона — локализация (до 1000 локалей), богатый SDK для всех платформ, Contentful Apps для кастомных UI. Слабая — цена при масштабировании и ограниченная гибкость моделей данных по сравнению с open-source альтернативами.
Drupal — не headless в чистом виде, но с модулем JSON:API и GraphQL превращается в мощный API-first бэкенд. Сильная сторона — зрелость (Drupal 10), гранулярные права доступа, enterprise-клиенты (NASA, weather.com). Порог входа высокий, но для сложных государственных или корпоративных порталов альтернатив мало.
| CMS | Хостинг | API | Лучший сценарий |
|---|---|---|---|
| Strapi | Self-hosted / Cloud | REST, GraphQL | Стартапы, кастомизация |
| Directus | Self-hosted / Cloud | REST, GraphQL | Обёртка над existing DB |
| Sanity | Облако | GROQ, GraphQL | Медиа, сложный контент |
| Contentful | Облако | REST, GraphQL | Enterprise, локализация |
| Drupal | Self-hosted | JSON:API, GraphQL | Госсектор, сложные права |
Как строим проекты на headless CMS
Моделирование контента — критичный этап. Ошибка на этом этапе стоит дорого. Типичная ошибка: поле body типа rich text для всего. Через полгода контент-менеджер хочет вставить видео между абзацами, добавить pull quote с кастомным стилем, встроить интерактивную таблицу. Rich text это не позволяет. Решение — Portable Text (Sanity) или кастомные компоненты в Strapi/Directus через Dynamic Zone.
Фронтенд. Под headless CMS практически всегда идёт Next.js или Nuxt. Для Contentful и Sanity — App Router с ISR: страницы статически генерируются при билде, обновляются через revalidatePath() при изменении контента через webhook. Для Strapi/Directus с частым обновлением данных — SSR с cache: 'no-store' или SWR на клиенте.
Кейс: редизайн корпоративного сайта с Strapi + Next.js. Клиент — производственная компания, предыдущий сайт на WordPress с ACF, 200+ страниц, 4 языка. Проблемы: TTFB 3.8s, редакторы жаловались на медленный админ.
Перешли на Strapi 4 (self-hosted на VPS, PostgreSQL), Next.js 14 App Router. Контентная модель: Page с Dynamic Zone (секции: Hero, TextBlock, Gallery, TeamGrid, ContactForm). Локализация через Strapi i18n plugin + next-intl на фронтенде. Деплой фронтенда на Vercel с ISR, ревалидация через Strapi webhook на entry.publish.
TTFB с 3.8s упал до 180ms (статика с CDN). Редакторы получили чистый интерфейс без 47 плагинов.
Процесс и сроки
Стандартный путь: аудит контентных потребностей → схема данных → настройка CMS и API → разработка фронтенда → миграция контента (если есть) → тестирование API endpoints → деплой.
Миграция с WordPress на headless CMS занимает столько же времени, сколько сам проект — часто больше. Особенно если в WordPress накоплены кастомные поля через ACF с нестандартной структурой.
| Тип проекта | Срок |
|---|---|
| Простой сайт на Strapi + Next.js | 4–8 недель |
| Многоязычный корпоративный сайт | 8–16 недель |
| Миграция с WordPress на headless | +4–8 недель к основному |
| Drupal enterprise-портал | 3–6 месяцев |
Стоимость — после аналитики требований и аудита существующей инфраструктуры.