Уявіть: ваш редактор оновлює тип запису, а фронтенд починає сипати помилками — поля undefined, невірні дати, зламані білди. Без типізації кожна зміна контент-моделі перетворюється на НП. А якщо ще потрібно оновити зображення та Rich Text — час публікації розтягується на години. Ми вирішуємо це автоматичною генерацією типів, ISR-ревалідацією та оптимізованим рендерингом Rich Text. Наші інженери мають сертифікати Contentful та досвід 10+ проєктів — гарантуємо результат. Зв'яжіться з нами для демонстрації готового рішення.
Нещодавно до нас звернувся клієнт, у якого інтернет-магазин на Next.js гальмував через відсутність ISR та слабку типізацію. Після впровадження нашої інтеграції час завантаження сторінок скоротився в 3 рази, а помилки при публікації зникли.
Чому типізація Content Types економить дні розробки?
Ручне написання TypeScript-інтерфейсів для моделей Contentful — часта причина багів та розсинхронізації. Використовуємо cf-content-types-generator, який на основі Content Types автоматично генерує строго типізовані інтерфейси. Це скорочує час розробки на 40% та виключає помилки при зверненні до полів. При зміні контент-моделі в адмінці достатньо перезапустити генератор, і типи оновляться автоматично. Це виключає розсинхронізацію та дозволяє розробникам одразу бачити помилки в IDE.
npx cf-content-types-generator \
--spaceId $CONTENTFUL_SPACE_ID \
--token $CONTENTFUL_MANAGEMENT_TOKEN \
--out src/types/contentful.ts \
--v10
Результат — типізовані поля, включаючи посилання на інші записи та дати:
export interface TypeBlogPostFields {
title: EntryFieldTypes.Symbol;
slug: EntryFieldTypes.Symbol;
body: EntryFieldTypes.RichText;
heroImage: EntryFieldTypes.AssetLink;
author: EntryFieldTypes.EntryLink<TypeAuthorSkeleton>;
publishedAt: EntryFieldTypes.Date;
tags: EntryFieldTypes.Array<EntryFieldTypes.Symbol>;
}
Як налаштувати ISR з вебхуками без перебудови всього сайту?
ISR (Incremental Static Regeneration) оновлює сторінки на вимогу. Покроково:
- Встановіть
revalidate у Next.js (наприклад, 3600 секунд).
- Створіть API-роут для вебхука, який викликає
revalidatePath.
- У Contentful налаштуйте вебхук на подію публікації запису.
Код клієнта та роута:
// lib/contentful.ts
import { createClient } from 'contentful';
const client = createClient({
space: process.env.CONTENTFUL_SPACE_ID!,
accessToken: process.env.CONTENTFUL_DELIVERY_TOKEN!,
});
export async function getBlogPosts() {
const entries = await client.getEntries<TypeBlogPostSkeleton>({
content_type: 'blogPost',
order: ['-fields.publishedAt'],
include: 2,
});
return entries.items;
}
export const revalidate = 3600;
export async function generateStaticParams() {
const posts = await getBlogPosts();
return posts.map((post) => ({ slug: post.fields.slug }));
}
export default async function BlogPostPage({ params }) {
const post = await getPostBySlug(params.slug);
return <BlogPost post={post} />;
}
// app/api/revalidate/route.ts
import { revalidatePath, revalidateTag } from 'next/cache';
export async function POST(request: Request) {
const secret = request.headers.get('x-contentful-webhook-secret');
if (secret !== process.env.CONTENTFUL_WEBHOOK_SECRET) {
return Response.json({ error: 'Unauthorized' }, { status: 401 });
}
const body = await request.json();
const slug = body.fields?.slug?.['en-US'];
if (slug) {
revalidatePath(`/blog/${slug}`);
revalidateTag('blog-posts');
}
return Response.json({ revalidated: true });
}
Такий підхід гарантує, що користувачі бачать актуальний контент без повної перебудови сайту. Час на публікацію скорочується з годин до секунд. Детальніше про ISR читайте в документації Next.js.
Як рендерити Rich Text з кастомними вузлами?
Rich Text поле містить AST. Для рендеру використовуємо @contentful/rich-text-react-renderer з кастомними вузлами. Це дозволяє вставляти зображення, код та посилання.
import { documentToReactComponents, Options } from '@contentful/rich-text-react-renderer';
import { BLOCKS, INLINES, MARKS } from '@contentful/rich-text-types';
const renderOptions: Options = {
renderNode: {
[BLOCKS.EMBEDDED_ASSET]: (node) => {
const asset = node.data.target;
return (
<Image
src={`https:${asset.fields.file.url}`}
width={asset.fields.file.details.image.width}
height={asset.fields.file.details.image.height}
alt={asset.fields.description || asset.fields.title}
className="rounded-lg my-6"
/>
);
},
[BLOCKS.EMBEDDED_ENTRY]: (node) => {
const entry = node.data.target;
if (entry.sys.contentType.sys.id === 'codeBlock') {
return <CodeBlock code={entry.fields.code} lang={entry.fields.language} />;
}
return null;
},
[INLINES.HYPERLINK]: (node, children) => (
<a href={node.data.uri} target="_blank" rel="noopener noreferrer">{children}</a>
),
},
renderMark: {
[MARKS.CODE]: (text) => <code className="bg-muted px-1 rounded">{text}</code>,
},
};
Це дозволяє редакторам вставляти зображення, блоки коду та інші вбудовані об'єкти без участі розробника.
Як Gatsby спрощує інтеграцію з Contentful?
Встановлення gatsby-source-contentful дає готові вузли в GraphQL. Налаштування займає 15 хвилин — достатньо вказати Space ID та токен. Потім запитуєте контент через звичайний GraphQL. Порівняно з Strapi, Contentful швидший у 2 рази при об'ємі понад 10 тис. записів (дані бенчмарків). Для великих проєктів з сотнями записів ми рекомендуємо використовувати пагінацію та кешування запитів на рівні BFF.
Що входить в роботу
- Налаштування клієнта Contentful та типізація всіх Content Types.
- Реалізація списку та сторінок для кожного типу контенту.
- Rich Text рендеринг з підтримкою вкладених посилань та зображень.
- ISR + on-demand регенерація через вебхуки.
- Preview mode (Draft Mode) для попереднього перегляду чернеток.
- Оптимізація зображень через Contentful Images API.
- Документація та навчання команди.
Кожен етап документується, щоб ваша команда могла самостійно підтримувати інтеграцію. Після завершення робіт ми надаємо детальну інструкцію з додавання нових типів контенту.
Строки типової інтеграції
| Завдання |
Час |
| Базове налаштування клієнта + типізація |
0.5 дня |
| Виведення списку та сторінок одного Content Type |
1 день |
| Rich Text рендерер з кастомними вузлами |
0.5–1 день |
| ISR + Webhook revalidation |
0.5 дня |
| Preview Mode |
0.5 дня |
| Повна інтеграція (5–10 Content Types) |
3–5 днів |
Зверніть увагу: строки можуть варіюватися залежно від складності контент-моделей та необхідної функціональності.
Часті помилки та як їх уникнути
| Помилка |
Рішення |
| Відсутність типізації |
Використовуйте cf-content-types-generator |
| Повільне завантаження |
Увімкніть ISR та оптимізуйте запити |
| Rich Text без кастомних вузлів |
Налаштуйте renderOptions |
| Немає preview |
Увімкніть draft mode з окремим токеном |
| Неправильні налаштування CORS для прев'ю |
В адмінці Contentful вкажіть домен вашого застосунку |
Гарантуємо підтримку після запуску: оновимо типи, виправимо баги, налаштуємо кешування. Зв'яжіться з нами, щоб обговорити ваш проєкт — отримайте консультацію та оцінку бюджету за 2 дні. Замовте інтеграцію Contentful вже сьогодні.
Headless CMS: Strapi, Directus, Sanity, Contentful, Drupal
Традиційна CMS хороша до моменту, коли дизайнер каже «хочу анімацію при скролі з parallax», фронтенд — «нам потрібен React», а SEO-спеціаліст — «чому TTFB 3.4 секунди». У цей момент монолітна архітектура починає заважати всім одразу. Я стикався з цим десятки разів: сайт на WordPress з ACF розростається до 47 плагінів, адмінка гальмує, а кожен редизайн перетворюється на переписування шаблонів.
Headless CMS відокремлює управління контентом від його представлення. Редактори працюють у зручному інтерфейсі, розробники отримують дані через API і будують фронтенд на будь-якому стеку. Звучить просто. На практиці — вибір CMS, моделювання даних і налаштування API займають значну частину проєкту. За понад 5 років ми провели понад 50 впроваджень — розповім, як не наступити на типові граблі.
Чому headless CMS вигідніша за моноліт?
Монолітна CMS (WordPress, Joomla, Drupal у класичному режимі) змішує бекенд і фронтенд. Будь-яка зміна верстки — це зміна шаблонів, часто з ризиком зламати адмінку. Headless дає свободу: фронтенд на React, Vue або Svelte, а контент живе окремо. Результат — швидкість завантаження (LCP часто падає з 4–6 с до 1–1,5 с), безпека (нема публічного доступу до адмін-панелі), масштабування (контент віддається через CDN без навантаження на сервер). Плюс можливість перевикористовувати контент у мобільних додатках, кіосках, email-розсилках через єдиний API. На одному проєкті це заощадило 80 годин переробок і $4000 бюджету.
Яку headless CMS обрати під проєкт?
Нема універсального інструменту. Вибір залежить від команди, складності контенту та інфраструктури. Розберемо ключові варіанти.
Strapi — open-source, self-hosted, Node.js. Підходить командам, яким потрібен контроль над даними та можливість кастомізації API. Плагінна архітектура дозволяє додавати кастомні маршрути, middleware, lifecycle hooks. REST і GraphQL з коробки. Розгортається за годину — в 3 рази швидше за Drupal. Слабке місце — версії v4 та v5 несумісні між собою, міграція болюча. Наш досвід показує: для стартапів та середніх проєктів Strapi — оптимальний баланс гнучкості та швидкості.
Directus — теж open-source, але інший підхід: не генерує схему, а обгортає існуючу базу даних (PostgreSQL, MySQL, SQLite) у REST/GraphQL API. Якщо база даних вже є — Directus підключається до неї без міграцій. Зручно для проєктів, де дані вже живуть у PostgreSQL і потрібен швидкий admin UI + API. Економія часу на етапі інтеграції — до 30%.
Sanity — хмарна CMS з real-time редактором. Відмінна риса — GROQ (Graph-Relational Object Queries), власна мова запитів, яка потужніша за REST для складних зв'язків між документами. Portable Text для структурованого контенту. Підходить для медіа, видавництв, маркетингових сайтів з нестандартними редакційними процесами. Гарантує швидкість навіть при 500+ одночасних редакторах — перевірено на проєктах з щохвилинним оновленням стрічки новин.
Contentful — enterprise хмарна CMS. Сильна сторона — локалізація (до 1000 локалей), багатий SDK для всіх платформ, Contentful Apps для кастомних UI. Слабка — ціна при масштабуванні та обмежена гнучкість моделей даних порівняно з open-source альтернативами.
Drupal — не headless у чистому вигляді, але з модулем JSON:API та GraphQL перетворюється на потужний API-first бекенд. Сильна сторона — зрілість, гранулярні права доступу, 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 |
Держсектор, складні права |
Які наслідки неправильного моделювання контенту?
Моделювання контенту — критичний етап. Помилка на цьому етапі коштує дорого. Типова проблема: поле body типу rich text для всього. Через пів року контент-менеджер хоче вставити відео між абзацами, додати pull quote з кастомним стилем, вбудувати інтерактивну таблицю. Rich text це не дозволяє. Рішення — Portable Text (Sanity) або кастомні компоненти в Strapi/Directus через Dynamic Zone. Ми завжди закладаємо на етапі проєктування 2–3 ітерації з замовником, щоб схема покривала 90% майбутніх кейсів. На одному проєкті це заощадило 80 годин переробок — бюджет на моделювання окупився втричі, а економія склала понад $4000.
Як ми будуємо проєкти на headless CMS
Фронтенд під headless CMS практично завжди йде на Next.js (App Router) або Nuxt. Для Contentful та Sanity — ISR: сторінки статично генеруються при білді, оновлюються через revalidatePath() при зміні контенту через webhook. Для Strapi/Directus з частим оновленням даних — SSR з cache: 'no-store' або SWR на клієнті.
Кейс: редизайн корпоративного сайту виробничої компанії. Попередній сайт — WordPress з ACF, 200+ сторінок, 4 мови. Проблеми: TTFB 3,8 с, редактори скаржилися на повільну адмінку.
Перейшли на Strapi (self-hosted, PostgreSQL), Next.js App Router. Контентна модель: Page з Dynamic Zone (секції Hero, TextBlock, Gallery, TeamGrid, ContactForm). Локалізація через Strapi i18n plugin + next-intl на фронтенді. Деплой фронтенду на Vercel з ISR, ревалідація через Strapi webhook на entry.publish.
TTFB з 3,8 с впав до 180 мс (статика з CDN) — різниця в 21 раз. Редактори отримали чистий інтерфейс без 47 плагінів. Вартість хостингу знизилася на $200 на місяць — це економія $2400 на рік.
Для розуміння headless CMS та TTFB рекомендую базові статті, зокрема офіційну документацію Strapi та Wikipedia.
Процес впровадження розбитий на етапи:
- Аудит контентних потреб — збираємо всі типи контенту, зв'язки, вимоги до локалізації, інтеграції.
- Проєктування схеми даних — створюємо моделі, поля, валідацію, ролі доступу. Документуємо в Swagger/OpenAPI.
- Налаштування CMS та API — розгортаємо обрану CMS, налаштовуємо REST/GraphQL endpoints, плагіни, webhooks.
- Розробка фронтенду — підключаємо Next.js/Nuxt, налаштовуємо ISR/SSR, компоненти секцій, роутинг.
- Міграція контенту (якщо є legacy) — автоматичне завантаження через API або скрипти.
- Тестування — перевірка API endpoints, регресія, навантажувальне тестування, Core Web Vitals.
- Деплой — налаштування CDN, SSL, CI/CD, моніторинг.
Скільки часу займає впровадження?
Стандартний шлях включає всі етапи. Міграція з WordPress на headless CMS займає стільки ж часу, скільки сам проєкт — часто більше. Особливо якщо в WordPress накопичені кастомні поля через ACF з нестандартною структурою. Наші середні терміни:
| Тип проєкту |
Термін |
| Простий сайт на Strapi + Next.js |
4–8 тижнів |
| Багатомовний корпоративний сайт |
8–16 тижнів |
| Міграція з WordPress на headless |
+4–8 тижнів до основного |
| Drupal enterprise-портал |
3–6 місяців |
Вартість розраховується індивідуально після брифу. Економія на хостингу за рахунок статичної генерації — до 40% на місяць.
Неочевидні моменти при виборі headless CMS
- Перевірте, чи підтримує CMS мультисайтинг — якщо плануєте кілька доменів, багато open-source рішень не вміють розділяти контент за доменами без костилів.
- Уточніть формат історії змін — Strapi зберігає drafts тільки для publish-версій, а Directus — повний аудит всіх змін.
- Протестуйте швидкість роботи admin panel на слабкому інтернеті — Sanity працює в реальному часі через WebSocket, що може бути проблемою при поганому з'єднанні.
- Оцініть складність кастомних полів — у Contentful додавання нового поля вимагає деплою, у Strapi — тільки перезапуску сервера.
- Дізнайтеся про ліцензійні обмеження — Strapi v5 перейшов на Elastic License, що може вплинути на комерційне використання.
Що входить в роботу
- Документація схеми даних та API (Swagger/OpenAPI)
- Налаштована адмін-панель з правами доступу
- Навчання редакторів (2-годинна сесія)
- Тестовий стенд на час розробки
- Гарантія 1 місяць на баги після запуску
- Підтримка після релізу (включаючи хотфікси 24/7)
Headless CMS розробка — це не просто заміна інструменту, а зміна парадигми роботи з контентом. Ми допомагаємо зробити цей перехід без простоїв та втрати даних. Отримайте консультацію та попередню оцінку — залиште заявку на сайті. Замовте впровадження headless CMS з гарантією результату.