У вас готовий дизайн, але інтеграція з October CMS перетворюється на головний біль: N+1 запити при виведенні записів, hydration mismatch при використанні Vue.js, роздутий CSS без tree-shaking. Кожна секунда завантаження коштує грошей — перші 3 секунди LCP вирішують, чи піде користувач. Ми розробляємо кастомні теми October CMS під ключ, вирішуючи ці проблеми на рівні архітектури. Досвід 5+ років і 30+ проєктів у портфоліо — це не просто цифри, а відпрацьовані шаблони для типових задач: від блогів до корпоративних порталів. Інвестиції в кастомну тему окупаються протягом першого року за рахунок зниження навантаження на сервер і зменшення часу завантаження. Наші клієнти економлять до 40% на правках у перший рік. Зв'яжіться з нами для консультації щодо вашого проєкту.
Які проблеми вирішує кастомна тема October CMS?
Кастомна тема усуває N+1 запити, роздутий CSS та JS, а також проблеми з кешуванням. Ми оптимізуємо Core Web Vitals: LCP, CLS, INP. Результат — завантаження на 30–50% швидше готових тем. Крім того, правильне кешування Twig знижує час відповіді сервера на 200–400 мс.
Як Vite інтегрується з October CMS?
Збірка фронтенду через Vite дає гаряче перезавантаження, мініфікацію та автоматичний tree-shaking. Плагін vite-plugin-october-cms-theme інтегрується безпосередньо з темплейт-системою, прискорюючи розробку в 2–3 рази порівняно з ручною збіркою. Зміни відображаються миттєво через HMR, а фінальні файли отримують хеші для інвалідації кешу. Порівняйте: без Vite на ребілд іде 10–15 секунд, з ним — менше секунди. Економія часу на кожному циклі розробки становить 80–90%, що безпосередньо впливає на бюджет проєкту.
npm install vite laravel-vite-plugin
Що входить у розробку кастомної теми?
Розробка кастомної теми включає:
- Аналіз дизайн-макету та підготовка структури
- Створення theme.yaml з полями форми для редактора
- Верстку layouts, pages, partials (піксель-перфект, адаптив)
- Інтеграцію компонентів (блог, товари, форми)
- Збірку через Vite з HMR, мініфікацією та хешуванням
- Тестування на десктопі та мобільних (перевірка LCP, CLS, INP)
- Документацію щодо структури теми та навчання роботі з компонентами
- Гарантійну підтримку 1 місяць
Вартість розраховується індивідуально залежно від складності проєкту.
Що всередині кастомної теми?
Типова структура кастомної теми October CMS включає:
- theme.yaml — метадані та поля форми
- layouts/ — базові шаблони (default.htm, minimal.htm)
- pages/ — сторінки сайту (index, about, blog)
- partials/ — перевикористовувані блоки (header, footer, nav, blog/)
- assets/ — стилі, скрипти, зображення
# theme.yaml
name: My Theme
description: Corporate theme for My Site
author: My Company
homepage: https://mycompany.com
code: mytheme
form:
fields:
primary_color:
label: Primary Color
type: colorpicker
default: '#1a56db'
logo:
label: Site Logo
type: mediafinder
mode: image
Поля з theme.yaml доступні в шаблоні через this.theme. Це дозволяє змінювати кольори, логотип та інші параметри без правки коду — редактор може налаштувати оформлення самостійно.
Layout і сторінки: як це працює?
Базовий layout підключає стилі та скрипти, задає метатеги. Поля з this.page використовуються для унікальних title, description та H1. Компоненти October CMS, такі як blogPosts, автоматично вибирають записи з пагінацією та кешуванням.
description = "Default Layout"
==
<!DOCTYPE html>
<html lang="{{ this.site.locale ?? 'uk' }}">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>
{% if this.page.meta_title %}
{{ this.page.meta_title }} | {{ this.site.name }}
{% else %}
{{ this.page.title }} | {{ this.site.name }}
{% endif %}
</title>
<meta name="description" content="{{ this.page.meta_description }}">
{% styles %}
<link rel="stylesheet" href="{{ 'assets/css/app.css' | theme }}">
</head>
<body class="{{ this.page.layout_class }}">
{% partial 'header' %}
<main id="main">
{% page %}
</main>
{% partial 'footer' %}
{% scripts %}
<script src="{{ 'assets/js/app.js' | theme }}" defer></script>
</body>
</html>
Сторінка з компонентами: блог за 10 хвилин
title = "Блог"
url = "/blog/:page?"
layout = "default"
is_hidden = 0
[blogPosts]
postsPerPage = 12
sortOrder = "published_at desc"
[blogCategories]
slug = "{{ :slug }}"
==
{% set currentPage = this.param.page ?? 1 %}
<section class="blog-header">
<h1>{{ this.page.title }}</h1>
</section>
<section class="blog-content">
<div class="posts-grid">
{% for post in blogPosts %}
{% partial 'blog/post-card' post=post %}
{% endfor %}
</div>
<aside class="sidebar">
<h3>Категорії</h3>
<ul>
{% for cat in blogCategories %}
<li><a href="{{ cat.url }}">{{ cat.name }} ({{ cat.posts_count }})</a></li>
{% endfor %}
</ul>
</aside>
</section>
Чому кастомна тема швидша за готову?
Готова тема часто містить надлишковий код, мертвий CSS та JS, що сповільнює завантаження. Кастомна тема позбавлена цього: ми підключаємо лише необхідні стилі та скрипти, використовуємо tree-shaking та оптимізуємо зображення. У результаті сторінки завантажуються на 30–50% швидше.
Порівняння збірників: Vite vs Webpack
| Критерій |
Vite |
Webpack |
| Час холодного старту |
< 1 с |
5–10 с |
| Гаряча заміна модулів |
Миттєво |
Затримка 1–3 с |
| Tree-shaking |
Автоматичний |
Потребує налаштування |
| Мініфікація |
Вбудована через esbuild |
Через Terser |
| Конфігурація |
Мінімальна |
Складна |
Vite виграє за швидкістю та простотою. У наших проєктах він використовується за замовчуванням, що скорочує час збірки на 70%.
Типові помилки при самостійній розробці
- Ігнорування кешування Twig — сторінка завантажується довше на 200–400 мс.
- Відсутність partials для повторюваних блоків — дублювання коду та N+1 запити.
- Hand-made збірка замість Vite — довга розробка, відсутність tree-shaking.
Процес роботи
- Аналіз дизайн-макету — оцінюємо складність, готуємо кошторис та терміни.
- Створення theme.yaml та структури — закладаємо поля форми, маршрути.
- Верстка layouts, pages, partials — піксель-перфект, адаптив.
- Інтеграція компонентів — налаштування блогу, товарів, форм.
- Збірка через Vite — HMR, мініфікація, хеші.
- Тестування на десктопі/мобільних — перевірка LCP, CLS, INP.
- Передача та навчання — документація, налаштування редакторів.
Ми використовуємо October CMS актуальної версії та стежимо за оновленнями. Зв'яжіться з нами для консультації щодо вашого проєкту. Замовте розробку кастомної теми з гарантією результату.
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 з гарантією результату.
