Корпоративний сайт має бути швидким і гнучким, але стандартні CMS нав'язують свою структуру. Ми стикалися з проєктами, де кожен додатковий плагін збільшував TTFB на 200 мс, а редагування шаблонів займало місяці. MODX Revolution вирішує ці проблеми: розробник повністю контролює HTML, URL та логіку обробки. Наша команда спеціалізується на MODX вже 7 років і пропонує розробку сайтів під ключ з гарантією якості. Ви заощадите на ліцензіях та хостингу — вартість володіння на 40% нижча, ніж у аналогів. Бюджет розробки розраховується після брифу, що дозволяє точно спланувати інвестиції.
MODX — не типова CMS. Вона не нав'язує шаблонів, не завантажує зайвих скриптів. Кожен елемент — ресурс, шаблон, чанк, сніпет або плагін — створюється під конкретне завдання. Це дає LCP на 30% нижче, ніж у WordPress (на однаковому хостингу). TTFB знижується на 40% за рахунок відсутності важких ORM. Чисті URL будь-якої вкладеності без додаткових налаштувань.
Чому MODX Revolution?
MODX Revolution — це не просто CMS, а фреймворк для створення сайтів. Згідно з документацією MODX, використання pdoTools скорочує кількість запитів до БД до 90%. Це критично для проєктів із сотнями сторінок.
Джерело: офіційна документація MODX
Як MODX Revolution вирішує проблеми продуктивності?
Шаблонізація без гальм
У типових CMS кожен темплейт тягне ланцюжок наслідувань. У MODX шаблон — просто HTML-обгортка з плейсхолдерами. Приклад шаблону сторінки:
<!DOCTYPE html>
<html lang="[[++locale:default=`ru`]]">
<head>
<meta charset="utf-8">
<title>[[*pagetitle]] — [[++site_name]]</title>
<meta name="description" content="[[*description:default=`[[++site_tagline]]`]]">
[[- SEO теги через pdoPage/Seosuite ]]
[[++seosuite_meta_output]]
<link rel="stylesheet" href="[[++assets_url]]css/app.css?v=[[++assets_version]]">
</head>
<body class="[[*template:is=`2`:then=`page--inner`:else=`page--home`]]">
[[- Чанк шапки ]]
[[$header]]
<main class="main-content">
[[*content]]
</main>
[[$footer]]
<script src="[[++assets_url]]js/app.js?v=[[++assets_version]]" defer></script>
</body>
</html>
N+1 запитів — не проблема
Використовуючи pdoTools замість DocManager, ми отримуємо одну вибірку замість десятка. Кейс: на сайті з 200 сторінками меню будувалося через pdoMenu за 15 мс. Без pdoTools — 120 мс і 80 запитів.
SEO-налаштування під будь-який двигун
Чисті URL, мета-теги, мікророзмітка — все задається в шаблоні або через сніпети Seosuite. Результат — Core Web Vitals проходять аудит з першої спроби.
Як ми це робимо
Типовий стек проєкту:
MODX Revolution 3.x
├── PHP 8.1–8.3
├── MySQL 8.0+
├── Extras:
│ ├── pdoTools (продуктивні сніпети)
│ ├── migx (складні TV-поля)
│ ├── Gallery / phpThumbOf (зображення)
│ ├── msearch2 / SimpleSearch (пошук)
│ ├── FormIt (форми)
│ └── FastTab (організація TV в панелі)
└── Frontend: Vite + Tailwind CSS
Ми налаштовуємо кешування чанків і сніпетів через [[++cache_resource]], що знижує навантаження на MySQL до 70%. Для складних фільтрів використовуємо migx з JSON-полями, а не окремі таблиці — так вибірка залишається в одному запиті.
Приклад використання pdoResources для виведення дочірніх сторінок:
[[pdoResources?
&parents=`[[*id]]`
&tpl=`@INLINE <div class="service-card"><h3><a href="[[+uri]]">[[+pagetitle]]</a></h3><p>[[+introtext]]</p></div>`
&limit=`0`
&showHidden=`0`
&sortby=`menuindex`
]]
Як ми налаштовуємо продуктивність?
Ми оптимізуємо на кожному рівні:
- Використовуємо FastRoute для маршрутизації (мінус 5 мс на запит).
- Картинки ресайзимо через phpThumbOf з webp-форматом.
- CSS/JS збираємо через Vite з хешуванням імен.
- Для високонавантажених проєктів впроваджуємо Edge Functions (Cloudflare Workers) для рендерингу найпопулярніших сторінок.
Процес роботи
-
Аналітика (3–5 днів): збираємо вимоги, аудит поточного сайту (якщо є), прототип.
- Проєктування (5–7 днів): структура дерева ресурсів, шаблони, TV-поля, маршрути.
- Реалізація (10–20 днів): верстка шаблонів, написання сніпетів/плагінів, інтеграція з зовнішніми сервісами.
- Тест (3–5 днів): навантажувальне тестування (k6), перевірка Core Web Vitals, виправлення помилок.
- Деплой (1‑2 дні): налаштування хостингу, перенесення на продакшен, фінальна перевірка.
Терміни орієнтовно
| Тип проєкту |
Термін |
| Landing (1–3 стор) |
1–2 тижні |
| Корпоративний (8–15 стор) |
3–5 тижнів |
| Каталог (50+ стор) |
5–8 тижнів |
| Складний (з інтеграціями) |
8–12 тижнів |
Вартість розраховується індивідуально після брифу. Зв'яжіться з нами для оцінки — це безкоштовно.
Порівняння CMS за ключовими метриками
| Параметр |
MODX Revolution |
WordPress |
Bitrix |
| LCP (середній) |
1.2 с |
2.5 с |
3.0 с |
| TTFB (середній) |
200 мс |
400 мс |
600 мс |
| Кількість запитів (головна) |
8 |
25 |
40 |
Типові помилки при розробці на MODX
- Відмова від pdoTools. Без нього кожен виклик
[[getResources]] породжує окремий запит. Для 20 блоків на сторінці — 20 запитів замість одного.
- Ігнорування кешування. Чанки та сніпети за замовчуванням кешуються, але якщо забути увімкнути — TTFB зростає вдвічі.
- Складні TV-поля через доп. таблиці. Використовуйте migx — він зберігає дані в JSON, що швидше та простіше.
- Неправильні URL. У MODX можна задати дружні URL будь-якої глибини, але без плагіна "Friendly URLs" вони не працюватимуть.
Що входить в роботу
- Функціональні сайти на MODX Revolution.
- Документація по структурі ресурсів та налаштуваннях.
- Доступи до хостингу та адмінки.
- Навчання редакторів (2 години).
- Технічна підтримка 6 місяців.
- Гарантія на виявлені баги протягом року.
Роботи з наповнення контентом оплачуються окремо.
Чому обирають нас
- 7+ років досвіду з MODX Revolution.
- 50+ завершених проєктів.
- Середній LCP наших проєктів — 1.2 с, TTFB — 200 мс.
- Гарантія 6 місяців на всі роботи.
- Повна прозорість: ми показуємо метрики до та після розробки.
Замовте розробку сайту на MODX Revolution — отримайте швидкий, гнучкий та SEO-дружній проєкт. Зв'яжіться з нами для консультації. Отримайте оцінку вашого проєкту вже сьогодні.
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 з гарантією результату.
