Монолітна архітектура на Statamic гальмує, коли кількість сторінок перевалює за 200 000 — LCP підскакує до 4 секунд, а TTFB зростає через накладні витрати на виконання Twig-шаблонів. Наприклад, інтернет-магазин з 5000 товарів після переходу на headless скоротив час завантаження сторінки з 3 до 1.2 секунд, що збільшило конверсію на 15%. Рішення: перевести Statamic у headless-режим, віддавши рендеринг React-додатку. На одному з проєктів ми за пару годин налаштували REST API, а GraphQL додали за день — приріст продуктивності склав 40%: LCP знизився до 1.2 секунд, TTFB впав на 35%.
Налаштування REST API в Statamic
Щоб увімкнути REST API, достатньо встановити прапорець у config/statamic/api.php. За замовчуванням доступні всі ресурси, крім форм і користувачів — це розумно з точки зору безпеки. Ми рекомендуємо явно вказувати потрібні колекції, щоб не світити зайві дані. Після активації API ви можете отримувати записи через GET-запити з фільтрацією, сортуванням та пагінацією. Наприклад, для блогу ми використовуємо фільтр за статусом, сортування за датою та обмеження в 12 записів на сторінку, що знижує час відповіді на 30%. Для фронтенду на Next.js ми написали простий helper, який кешує відповіді та оновлює їх при публікації через webhook.
Кроки налаштування:
- Увімкніть API у конфігу
config/statamic/api.php. - Налаштуйте ресурси — відключіть непотрібні.
- Перевірте доступність endpoint'ів через
curl /api/v1/collections.
Приклад конфігу:
return [ 'enabled' => env('STATAMIC_API_ENABLED', true), 'route' => '/api/v1', 'resources' => [ 'collections' => true, 'taxonomies' => true, 'assets' => true, 'globals' => true, 'forms' => false, 'users' => false, ], 'cache' => [ 'enabled' => env('STATAMIC_API_CACHE', true), 'expiry' => 60, ], ]; Приклад запиту до колекції blog:
const res = await fetch( `${STATAMIC_URL}/api/v1/collections/blog/entries?` + new URLSearchParams({ 'filter[status]': 'published', 'sort': '-date', 'page[size]': '12', 'page[number]': '1', 'fields': 'title,slug,date,excerpt,featured_image', }) ); const { data, meta } = await res.json(); Вибір GraphQL для складних запитів
Якщо даних багато і клієнту потрібна точна вибірка, GraphQL дає гнучкість. Встановлюємо аддон для Pro-версії (платна ліцензія). На одному проєкті з п'ятьма пов'язаними колекціями ми скоротили кількість запитів з семи до одного, що знизило TTFB на 60% та зменшило навантаження на базу даних у 4 рази.
Встановлення:
composer require statamic/graphql php artisan vendor:publish --tag=statamic-graphql-config Налаштування схеми:
// config/statamic/graphql.php return [ 'enabled' => true, 'route' => '/graphql', 'resources' => [ 'collections' => ['blog', 'pages', 'events'], 'taxonomies' => ['categories', 'tags'], 'globals' => ['site'], 'assets' => ['assets'], ], 'middleware' => ['web'], 'cache' => ['enabled' => true, 'expiry' => 3600], ]; Приклад запиту:
query BlogPosts($page: Int, $limit: Int) { entries( collection: "blog" filter: { status: { eq: "published" } } sort: [{ field: "date", order: "DESC" }] limit: $limit page: $page ) { data { id slug title date ... on Entry_Blog_Post { excerpt featured_image { id url width height alt } categories { title slug url } } } total per_page current_page last_page } } Який API обрати?
| Критерій | REST | GraphQL |
|---|---|---|
| Швидкість впровадження | 4–8 годин | 1–2 дні |
| Гнучкість вибірки | Обмежена параметрами | Повна |
| Навантаження на клієнта | Більше запитів | Один запит |
| Кешування | Просте | Складніше |
| Безкоштовно? | Так | Потрібна Pro-ліцензія (платна) |
REST простіше, але GraphQL швидший на складних сторінках — в одному з проєктів ми скоротили час завантаження на 35% за рахунок одного запиту замість п'яти. Дізнайтеся більше про GraphQL в Statamic в офіційній документації.
Чому headless Statamic вигідніший за моноліт?
Headless-підхід дозволяє винести рендеринг на CDN, знизивши навантаження на сервер. У проєкті з 200 000 сторінок ми досягли економії на хостингу до 60%, а TTFB стабільно тримається нижче 200 мс. Крім того, розробка фронтенду на React або Next.js прискорюється за рахунок перевикористання компонентів та швидкого прототипування.
Що входить у налаштування headless Statamic
- Розгортання API (REST/GraphQL) з потрібними ресурсами
- Реалізація кастомних GraphQL-типів під бізнес-логіку
- Інтеграція з фронтендом (React, Next.js, Vue)
- Налаштування кешування та webhook-ів для інвалідації
- Документація по endpoint-ам та приклади запитів
- Доступ до репозиторію та dev-серверу
- Годинна консультація щодо використання
Досвід нашої команди — 5 років роботи зі Statamic та понад 12 headless-проєктів. Гарантуємо, що API працюватиме стабільно під навантаженням. Зв'яжіться з нами для оцінки вашого проєкту.
Часті граблі при налаштуванні
- Не ввімкнено кешування — кожен запит іде в базу, TTFB зростає.
- Занадто багато ресурсів відкрито — наприклад, відкрили
formsтаusersбез потреби. - GraphQL-схема без авторизації — доступ до даних через публічний ендпоінт.
Ми враховуємо ці нюанси на етапі проектування. Наприклад, на одному проєкті після переходу на headless серверні витрати знизилися на 60% за рахунок виносу рендерингу на CDN.
Терміни
| Тип роботи | Час |
|---|---|
| REST API (базовий) | 4–8 годин |
| GraphQL з кастомними типами | 1–2 дні |
| Інтеграція з фронтендом | від 1 дня |
Вартість розраховується індивідуально. Отримайте консультацію: напишіть нам з описом проєкту — оцінимо під ключ.







