Определение
Headless Commerce Site — это модель e-commerce, в которой «голова» (фронтенд: витрина, каталог, корзина, оформление заказа, личный кабинет) полностью отделена от «тела» (бэкенд: товарный учёт, цены, склады, платежи, логистика, CRM). Фронтенд общается с бэкендом не через готовые шаблоны CMS, а через API — чаще всего REST или GraphQL.
Проще говоря: вы больше не «прикручиваете» дизайн к готовому движку. Вы собираете витрину на любом стеке (Next.js, Nuxt, Astro, React Native, Swift, Kotlin), а коммерческое ядро подключаете как сервис. Для российского DTC-рынка это означает: один и тот же товарный каталог и один и тот же заказ могут обслуживать сайт, мобильное приложение, Telegram-бот, маркетплейс-витрину и POS в офлайн-точке.
Аналогия
Представьте ресторан. Классическая CMS-платформа — это ресторан, где меню, кухня и зал находятся в одном здании: чтобы поменять меню, нужно переставить мебель. Headless — это кухня (бэкенд), которая готовит блюда по API-заказам, а зал (фронтенд) вы проектируете сами: сегодня это веранда, завтра фуд-трак, послезавтра доставка. Кухня одна — точек подачи сколько угодно.
Или так: бэкенд — это «двигатель», фронтенд — «кузов». Вы можете поставить один и тот же двигатель в седан, кроссовер и пикап, не перепроектируя мотор.
Формула
Базовая модель стоимости и производительности headless-решения:
TCO = C_dev + C_api + C_infra + C_support − E_scale где: C_dev — разработка и поддержка кастомного фронтенда C_api — лицензии/трафик commerce-API (за заказ, за SKU, за запрос) C_infra — хостинг, CDN, edge-функции, очереди C_support — DevOps, мониторинг, безопасность E_scale — экономия за счёт переиспользования одного бэкенда на N каналах
Ключевая метрика эффективности:
E_scale = (N_каналов − 1) × C_дублирования Пример: 4 канала, стоимость дублирования логики 180 000 ₽/мес E_scale = (4 − 1) × 180 000 = 540 000 ₽/мес экономии
Техническая формула времени отклика витрины:
TTFB_front = TTFB_edge + T_api + T_render Цель для DTC: TTFB_front ≤ 200 мс, T_api ≤ 120 мс, T_render ≤ 80 мс
Сравнение подходов
| Критерий | Классическая CMS (1С-Битрикс, WordPress+Woo) | SaaS-конструктор (Shopify, Tilda) | Headless Commerce |
|---|---|---|---|
| Скорость запуска | 2–6 недель | 3–10 дней | 8–20 недель |
| Гибкость фронтенда | Низкая (шаблоны) | Средняя (темы) | Максимальная |
| Мультиканальность | Ограниченная | Через приложения | Нативная (API-first) |
| Стоимость разработки | 150–600 тыс. ₽ | 0–50 тыс. ₽/мес | от 1,5 млн ₽ |
| Скорость загрузки (LCP) | 2,5–5 с | 1,8–3,5 с | 0,8–1,6 с |
| Конверсия (типично) | 1,2–1,8% | 1,5–2,2% | 2,0–3,4% |
| Зависимость от вендора | Высокая | Высокая | Низкая |
| Кто нужен в команде | 1 разработчик | Маркетолог | Frontend + DevOps + Backend |
Сценарии применения
1. DTC-бренд с омниканальностью. Одежда, косметика, БАДы: сайт + приложение + Telegram-магазин + витрина на маркетплейсе. Один бэкенд отдаёт остатки и цены во все каналы. Пример: бренд с 12 000 SKU сокращает время вывода нового канала с 6 недель до 9 дней.
2. Высоконагруженные распродажи. Black Friday, 11.11, запуск коллекции. Headless на CDN выдерживает 40 000 RPS на статике, а API масштабируется отдельно. Классическая CMS падает на 3 000–5 000 RPS.
3. B2B с индивидуальными ценами. Дистрибьютор с 800 клиентами: у каждого свой прайс, отсрочка, лимит. API отдаёт персональные условия, фронтенд рендерит личный кабинет под роль.
4. Гибридный офлайн+онлайн. Сеть из 60 точек: единый каталог, онлайн-заказ, самовывоз, POS-терминал — всё через один commerce-API.
5. Международная экспансия. Мультивалютность, мультиязычность, локальные платёжки (ЮKassa, Stripe, Payme). Фронтенд под каждый рынок — свой, бэкенд — общий.
Частые ошибки
Ошибка 1. Headless ради headless. Если у вас 300 SKU, один канал и нет команды — вы потратите 1,5–2 млн ₽ и 4 месяца, тогда как Shopify решит задачу за 2 недели. Headless оправдан при 3+ каналах или специфичном UX.
Ошибка 2. Недооценка DevOps. Headless требует CI/CD, мониторинга, кэширования, очередей, обработки ошибок API. Без DevOps-инженера проект деградирует за 3–4 месяца. Закладывайте 25–35% бюджета на инфраструктуру и поддержку.
Ошибка 3. Слабое кэширование. Каждый запрос к API «в лоб» — это +150–400 мс и рост счёта. Нужны ISR/SSG, edge-кэш, stale-while-revalidate. Иначе LCP уходит за 3 секунды и вы теряете преимущество.
Ошибка 4. Игнорирование SEO. SPA без SSR/SSG = пустой HTML для роботов. Обязательно серверный рендеринг или пререндеринг, sitemap, structured data, корректные canonical.
Ошибка 5. Разрыв аналитики. События фронтенда и данные бэкенда живут отдельно. Нужен единый слой: GA4 + Measurement Protocol, server-side events, CDP. Иначе атрибуция ломается и вы не видите реальный ROAS.
Ошибка 6. Выбор API «на вырост» без плана миграции. Смена commerce-бэкенда (например, с самописного на коммерческий) стоит 400–900 тыс. ₽. Проектируйте контракты API так, чтобы бэкенд можно было заменить.
Связанные термины
- Composable Commerce — модульная архитектура, где headless — один из слоёв.
- API-first — подход, при котором API проектируется до интерфейса.
- JAMstack — стек JavaScript + API + Markup, типичная база headless-витрины.
- SSR / SSG / ISR — стратегии рендеринга фронтенда.
- Edge Computing — вычисления на CDN-узлах для низкого TTFB.
- PIM — система управления товарной информацией, часто отдельный сервис в headless-стеке.
- OMS — система управления заказами, подключается через API.
- GraphQL — язык запросов, популярный для связи фронтенда и commerce-бэкенда.
- MACH-архитектура — Microservices, API-first, Cloud-native, Headless.