Headless Commerce у 2025: архітектурні рішення, які дійсно важливі

Ми працювали з командами, які перейшли на headless з вагомих причин, і з командами, які перейшли просто тому що так було модно у 2023-му. Різниця в результатах — суттєва. У 2025 році у headless достатньо історії, щоб приймати це рішення на основі реальних компромісів, а не архітектурної моди.

Що таке headless насправді

У традиційній commerce-системі фронтенд (HTML-рендеринг, маршрутизація, інтерфейс чекауту) жорстко пов'язаний із commerce-рушієм (каталог, кошик, замовлення). Magento або WooCommerce — хороші приклади: один і той самий застосунок відповідає і за бізнес-логіку, і за генерацію сторінок.

Headless розділяє ці два аспекти. Commerce-рушій віддає все через API. Фронтенд — це окремий застосунок, зазвичай React або Next.js, — він викликає ці API і відповідає за власний рендеринг. Вони деплояться незалежно. Масштабуються незалежно. І коли одна команда хоче випустити зміну без очікування іншої — вона може.

Останнє звучить очевидно краще. На практиці це не завжди так. Розділення перекладає цілий клас проблем на вас.

Коли headless дійсно допомагає

Є три сценарії, де headless-модель виправдовує себе:

• Кілька каналів, єдине commerce-ядро. Якщо ви продаєте через веб-вітрину, мобільний застосунок, кіоск і B2B-портал — при цьому скрізь потрібен різний UX, але ті самі каталог, ціни та логіка замовлень — headless дозволяє використовувати спільний бекенд і контролювати фронтенд для кожного каналу.
• Фронтенд-команди, яким потрібен повний контроль. В деяких організаціях є сильні фронтенд-інженери та продуктова команда, яка хоче розвивати UX незалежно від релізів бекенду. Headless це дозволяє. Якщо це не ваш випадок, ви додаєте інфраструктурну складність заради переваги, якою не скористаєтесь.
• Продуктивно-критичні вітрини при високому навантаженні. Вітрина на Next.js зі статичною генерацією та edge-CDN може забезпечити Time-to-First-Byte у діапазоні 50–100 мс. Із серверним PHP це структурно складніше. Якщо ваш каталог достатньо стабільний для статичної генерації, це важливо.

Реальні витрати, які недооцінюють

Вибір headless означає, що тепер ви несете відповідальність за те, що платформа раніше робила сама:

• Процес оформлення замовлення: SDK платіжних провайдерів, валідація адрес, розрахунок податків
• Збереження кошика та управління сесіями на різних пристроях
• Пошук і фільтрація (скоріш за все знадобиться Algolia, Elasticsearch або аналог)
• Preview-середовища для редакторів контенту
• Інфраструктура аналітики та A/B-тестування

Жодне з цих завдань не є блокером. Але кожне потребує інженерного часу, якого не було закладено в оцінку. Команди, які у нас на очах спотикалися найбільше, — ті, хто оцінив scope headless-міграції, але не оцінив scope перебудови чекауту. Через півроку вони шиплять кастомний чекаут, поки решта роадмапу стоїть.

Ліміти API та бюджети затримок

Одна з речей, яка заскакує команди зненацька: у commerce API є ліміти запитів. Сторінка з 4 картками товарів — з ціною, наявністю та статусом акції — може потребувати 4–8 викликів API. При навантаженні з ISR-ревалідацією це може означати тисячі звернень на хвилину до вашого commerce-бекенду.

Стратегію кешування на рівні API треба продумувати до початку будівництва вітрини, а не після першого інциденту з лімітами в продакшні. Що можна віддавати з кешу 60 секунд. Що має бути свіжим. Чи потрібен BFF-шар для агрегації викликів. Це не складні задачі, але вони стоять вище за все інше.

Як прийняти рішення

Чотири запитання, які варто чесно опрацювати до того, як зробите вибір:

1. Чи є у нас (або плануємо найняти) виділена фронтенд-команда, яка розвиватиме вітрину як продукт?
2. Чи є у нас кілька каналів, яким потрібні ті самі дані з різним UX?
3. Чи пов'язані реальні обмеження продуктивності саме зі шаром рендерингу?
4. Чи готові ми відтворювати або купувати інструменти для того, що платформа робить зараз?

Якщо більшість відповідей — ні, добре оптимізований моноліт із CDN спереду обжене наспіх зібраний headless-стек у будь-який момент. «Headless» не робить вітрину кращою за замовчуванням. Він змінює те, де живе складність.

Куди рухається тренд

Патерн, що набирає обертів у 2025 році, — composable commerce: вибір кращих у своєму класі сервісів для пошуку, чекауту, CMS і промоакцій, пов'язаних через API. MACH-архітектура формалізує цей підхід. Справді потужна історія для інженерних організацій, у яких є пропускна здатність керувати кількома вендорними контрактами й інтеграційними поверхнями. Для більшості mid-market команд — поки все ще більше накладних витрат, ніж віддачі.

Наша чесна думка: починайте з конкретної проблеми, яку ви вирішуєте. Якщо це проліферація каналів або швидкість фронтенд-команди — headless, мабуть, має сенс. Якщо це «наш сайт повільний» — спочатку знайдіть повільний запит.