Webflow API проти безголового CMS: обмеження швидкості та реальні компроміси

Webflow — це візуальний інструмент для створення сайтів, який водночас містить CMS та API. Натомість безвізуальний CMS — це сховище контенту, орієнтоване на API, без будь-якого візуального інструменту для створення. Різниця між ними стає очевидною лише тоді, коли обсяг трафіку через API починає досягати своїх обмежень, а не під час розташування елементів на сторінці.

Люди постійно плутають ці два підходи, переважно тому, що Webflow дійсно має справжній API. Однак цей API не був розроблений для використання як основний бекенд контенту для чогось, крім сторінок, які сам Webflow відображає. У цій статті розглядається, де цей API працює ефективно, а де він дає збої, а також конкретні обмеження, які визначають, який сценарій стосується саме вас.

Що насправді є CMS Webflow?

CMS Webflow базується на колекціях, які є еквівалентом типів контенту. Ви заповнюєте їх за допомогою того самого візуального редактора, який використовується для створення сторінок, тож створення контенту та дизайн сторінок відбуваються в одному інструменті. Саме в цьому полягає основна перевага, і для таких проектів, як маркетинговий сайт чи портфоліо, це справді значуща перевага.

API додається до цієї структури. Він надає доступ до елементів колекцій через REST-кінцеві точки, підтримуючи читання та обмежений набір операцій запису. Він існує для того, щоб зовнішні інструменти могли надсилати дані до власної системи рендерингу Webflow, а не для того, щоб окремий фронтенд, мобільний додаток та внутрішня панель керування могли отримувати дані з єдиного спільного джерела. Саме така конфігурація з кількома користувачами є метою створення безголових CMS, таких як Draftbase, з самого початку.

Чи є Webflow безголовим CMS?

Ні. Webflow — це тісно інтегрований CMS, який випадково має API. Справжній безголовий CMS зовсім не має вбудованого шару рендерингу; кожен елемент маркування походить від фронтенду, який ви самостійно створюєте. Webflow, навпаки, спочатку завжди рендерує власні сторінки — API виступає як додатковий канал, а не основний спосіб надходження контенту до читача.

Справжні обмеження API Webflow (та чому вони створюють проблеми)

Майже кожна стаття з порівнянь згадує, що «у Webflow є обмеження», але дуже мало з них наводять конкретні цифри, і майже жодна не пояснює, яке саме обмеження створює справжні проблеми під час роботи в продакшені.

Обмеження частоти запитів та виняток, про який ніхто не згадує

Згідно з документацією для розробників Webflow, API даних дозволяє 60 запитів на хвилину у планах Starter та Basic, а кількість зростає до 120 запитів на хвилину у планах CMS, eCommerce та Business. Клієнти Enterprise укладають договори з індивідуальними обмеженнями. Якщо ви перевищите ліміт, ви отримаєте відповідь 429.

Ось деталь, яку більшість статей пропускають: запити до API доставки контенту, які повертаються з кешу, не враховуються у цьому ліміті. Враховуються лише ті виклики, які фактично доходять до оригінального сервера API даних. Тож якщо ваше інтеграційне рішення постійно читає опублікований контент без будь-яких змін, ваша фактична швидкість обробки буде значно вищою, ніж це вказано. Але якщо ви щоразу записуєте дані чи читаєте некешовані дані, цей ліміт у 120 запитів на хвилину швидко вичерпується, як тільки ви починаєте синхронізувати більше кількох сотень елементів.

Кількість колекцій та полів

У планах CMS та Business кількість полів у кожній колекції обмежена 60, а будь-яке поле з багатьма посиланнями може вказувати максимум на 1 000 елементів. Оновлення цін Webflow від травня 2026 року також ввело обмеження кількості елементів за планом: у плані CMS максимум — 2 000 елементів у колекції, план Business дозволяє до 20 000 елементів за умови придбання додаткових опцій, а план Enterprise має індивідуально узгоджене обмеження. Жодне з цих обмежень не становить проблеми для невеликого маркетингового сайту з вбудованим блогом. Вони починають мати значення, коли каталог продуктів чи набір документації перевищує обмеження вашого плану — те саме стосується бібліотеки контенту, яка охоплює кілька локалізацій.

Одна публікація на хвилину

Згідно з власною документацією Webflow щодо обмежень швидкості, операції публікації сайту обмежені однією успішною публікацією на хвилину. CI-пайплайн, налаштований на запуск публікації після кожного з’єднання з основною гілкою, почне формувати чергу після досягнення цього ліміту як тільки буде спостерігатися реальний трафік, а не лише у гіпотетичному випадку.

Де API безголового CMS має зовсім іншу структуру

Безголовий CMS побудований навколо свого API доставки як основного способу передачі контенту користувачам. Не існує розрізнення „кеш проти вихідного джерела“, адже API доставки є єдиним шляхом, яким контент потрапляє до читача. Обмеження швидкості та кешування є частиною основних принципів проектування, а не додатком до візуального конструктора, який ніколи не був призначений для обробки такого типу трафіку.

Глибша структурна відмінність полягає у наступному: CMS без керування контентом розглядає моделювання контенту як свій центральний інтерфейс, причому будь-який візуальний шар є необов’язковим або повністю відокремленим від нього. Webflow змінює цей пріоритет — основним інтерфейсом є візуальний конструктор, а API є додатковим елементом, який додається пізніше. Ця різниця у пріоритетах чітко проявляється у тому, що кожен продукт обирає для реалізації спочатку, коли додає нові функції.

Де Webflow справді має перевагу

Варто чесно сказати про це. Для маркетингової команди, яка хоче ідеального візуального вигляду без необхідності писати жодної рядка коду, інструменти Webflow значно кращі за ті, що можна отримати з Draftbase чи будь-якої іншої безголової платформи для виконання саме цього завдання. Контроль над макетом на рівні пікселів за допомогою перетягування просто не є тією сферою, у якій безголові платформи намагаються конкурувати, і стверджувати протилежне може ввести в оману тих, хто порівнює ці два підходи. Коли всі, хто працює з контентом, не є технічними фахівцями, а сайт складається переважно зі статичних сторінок, багатофункціональний інструментарій Webflow є справжньою перевагою, а не чимось, з чим доводиться миритися.

Де перемагає безголовий CMS

Розгляньмо ситуацію, коли один і той самий контент потрібно надавати веб-сайту, мобільному додатку та певному внутрішньому інструменту, причому усе це з однієї схеми. У Webflow така ситуація відразу стикається з обмеженнями кількості елементів та полів за планом, що перетворює звичайну роботу на складну процедуру міграції. headless CMS забезпечує наявність текстових полів та збереження цілісності даних від самого початку. Його API призначений для обробки тисяч запитів на день без проблем. Не існує жодних штучних обмежень. API не є доповненням, створеним відповідно до патернів трафіку візуального конструктора; він є частиною самого продукту.

Коли варто використовувати Webflow замість headless CMS?

Використовуйте Webflow, коли люди, які редагують контент, не є розробниками, у сайту невелика кількість сторінок, і для обробки цього контенту не потрібно нічого, крім власних інструментів рендерингу Webflow. Уявіть собі веб-сайт ресторану, окрему сторінку-лендінг для одного продукту чи портфоліо невеликої агенції. У таких випадках візуальне редагування у Webflow безумовно переважає за швидкістю запуску.

Чи можна поєднати Webflow з безголовим CMS?

Так, і до 2026 року таке поєднання стане досить стандартним. Залишіть веб-сайт маркетингу на Webflow, щоб скористатися його інструментами дизайну. Потім вийміть усе, що функціонує як структуровані дані — наприклад, каталог продуктів, бібліотеку документації чи контент, створений користувачами — та керуйте ним через окремий безголовий CMS, відображаючи його через власні маршрути. Таким чином співробітники, які не є технічними фахівцями, все одно матимуть редактор Webflow для контенту, яким вони фактично керують, тоді як кожна частина системи, де обсяг контенту або кількість додатків, що його використовують, перевищує можливості пов’язаного CMS, отримає відповідний API для доставки.

Часто ставлені запитання

Чи вважається Webflow безголовим CMS? Не зовсім. Він надає API для читання даних та запису в колекції у обмеженому форматі, але по суті це пов’язаний CMS, створений насамперед для відображення власних сторінок. Справжній безголовий CMS зовсім не має вбудованого шару відображення.

Який ліміт швидкості діє для API Webflow? Згідно з документацією для розробників Webflow, плани Starter та Basic передбачають 60 запитів на хвилину, плани CMS, eCommerce та Business — 120, а для плану Enterprise може бути узгоджений індивідуальний ліміт. Варто зазначити, що запити з кешу від Content Delivery API не враховуються у цьому ліміті.

Яка максимальна кількість елементів може містити колекція Webflow? У плані CMS — 2 000 елементів, у плані Business з платними додатками — до 20 000, а для плану Enterprise ліміт може бути узгоджений індивідуально. Ці цифри наведені у оновленні цін Webflow за травень 2026 року.

Чи можливо використовувати CMS Webflow як бекенд для абсолютно окремого додатку? У принципі, так, через його API. Але ви зіткнетеся з обмеженнями кількості елементів, обмеженнями полів та лімітами швидкості, про які йшлося раніше, значно раніше, ніж у випадку з системою, створеною спеціально для доставки контенту. API Webflow призначений для синхронізації даних у власну систему обробки, а не для функціонування як універсальний бекенд для зовнішніх додатків.

Чесна відповідь

Webflow та безголовий CMS створені для вирішення різних проблем, а не як конкуруючі версії одного й того самого продукту. Обмеження API, описані в цій статті, не є дефектом проектування — це природний наслідок створення API навколо візуального інструменту для створення контенту, а не навпаки. Якщо у вашій команді немає розробників, а обсяг сайту легко вміщується в ліміт одного плану, Webflow допоможе досягти цієї мети швидше. Якщо ви потрібно надавати контент більш ніж одному фронтенду з однієї моделі контенту, безголовий CMS Draftbase створений з самого початку для повного уникнення таких обмежень. У супровідному матеріалі детальніше розглядається аспект впровадження цього рішення. Ви можете знайти його на HackMD: у ньому описано отримання та кешування контенту з реального API використовуючи Node.js та Express.

Пов’язані матеріали

• Тестування продуктивності компілятора Go TypeScript 7 у реальному додатку Next.js — практичне порівняння часу виконання команд tsc між TypeScript 6 та 7 у реальному кодовому базисі Next.js, включаючи проблему несумісності у CI та рекомендації щодо оновлення.
• 20 просунутих патернів Next.js для додатків App Router виробничого рівня — дізнайтеся про двадцять патернів високого рівня для Next.js, які охоплюють серверно-орієнтоване проектування, стрімінг, кешування, маршрутизацію та оптимізацію продуктивності для створення швидших та масштабованих додатків.