Ви запустили інтернет-магазин на ProcessWire, але сторінки завантажуються по 3 секунди, а LCP зашкалює? Стандартна тема додала купу зайвих скриптів, а верстка не адаптується під потрібні дані. Кастомний шаблон вирішує це — ви отримуєте рівно те, що потрібно, без сміття. За 8 років роботи з ProcessWire ми накопичили досвід, що дозволяє гарантувати надійне рішення. Перехід на кастомні шаблони знижує TTFB у 2–3 рази за рахунок виключення невикористовуваних модулів.
Як розробити кастомний шаблон ProcessWire?
Шаблон у ProcessWire — PHP-файл у /site/templates/, ім'я якого збігається з ім'ям шаблону в базі. Файл отримує об'єкт $page з даними поточної сторінки та повний доступ до $pages, $config, $user та решти API. Чистий PHP — жодного двигуна за замовчуванням, хоча можна підключити Twig через модуль TemplateEngineTwig. Для продакшену ми рекомендуємо чистий PHP: він швидший і не додає зайвий шар абстракції.
Чому кастомний шаблон кращий за стандартний?
Стандартні теми часто перевантажені невикористовуваними скриптами та стилями, що збільшує LCP і CLS. Кастомний шаблон виводить лише потрібні дані, використовує server-side rendering для важких компонентів та впроваджує lazy loading для зображень. В одному з наших проєктів — інтернет-магазин на ProcessWire з 5000+ товарів — перехід на кастомні шаблони знизив споживання пам'яті на 60% і прискорив генерацію сторінок у 2 рази. Додатково ми зменшили кількість запитів до БД з 50 до 3 на сторінку.
Архітектура шаблонів: варіанти розділення
Варіант 1: _init.php + _main.php
Найпоширеніший підхід. ProcessWire автоматично включає _init.php перед кожним шаблоном та _main.php після, якщо увімкнено опцію «Prepend/Append template file» в налаштуваннях шаблону:
// _init.php і _main.php — єдиний потік
$baseUrl = $config->urls->root;
$homePage = $pages->get("/");
$mainNav = $pages->find("parent=/,template!=error404,sort=sort");
?><!DOCTYPE html>
<html lang="<?= $user->language->name ?>">
<head>
<meta charset="utf-8">
<title><?= $page->title ?> | <?= $homePage->title ?></title>
<link rel="stylesheet" href="<?= $config->urls->templates ?>css/main.css">
</head>
<body>
<?php include("partials/nav.php"); ?>
<main><?= $content ?></main>
<?php include("partials/footer.php"); ?>
</body>
</html>
Варіант 2: контролер + вид
Для складних шаблонів логіку виносять в окремий файл-контролер. Це спрощує підтримку та тестування:
// templates/services.php — точка входу
require __DIR__ . '/controllers/services.php';
extract($viewData);
require __DIR__ . '/views/services.view.php';
// templates/controllers/services.php — контролер
$viewData = [
'items' => $pages->find("template=service, sort=sort, limit=12"),
'categories' => $pages->find("template=service-category, sort=sort"),
'pagination' => $modules->get("MarkupPagerNav"),
];
Порівняння підходів
| Характеристика |
init/main |
controller+view |
| Складність |
Низька |
Середня |
| Підтримка |
Проста |
Гнучка |
| Тестованість |
Низька |
Висока |
| Продуктивність |
Висока |
Висока |
| Рекомендація |
Невеликі проєкти |
Складні проєкти |
Робота із зображеннями
ProcessWire обробляє зображення на льоту через метод size(). Приклад із WebP:
$img = $page->images->first();
if ($img) {
$thumb = $img->size(800, 600, ['cropping' => 'center', 'quality' => 85]);
echo "<img src='{$thumb->url}' alt='{$img->description}' loading='lazy'>";
$webp = $img->size(800, 600, ['suffix' => 'webp', 'webpAdd' => true]);
}
Кастомні 404 та редиректи
if ($page->redirect_url) {
$session->redirect($page->redirect_url, 301);
}
if (!$user->isLoggedin() && $page->requires_login) {
throw new Wire404Exception();
}
Як оптимізувати зображення: покрокова інструкція
- Виберіть зображення з галереї сторінки.
- Викличте
$img->size() з потрібними параметрами.
- Вкажіть
suffix: 'webp' і webpAdd: true для генерації WebP.
- Додайте атрибут
loading='lazy' для відкладеного завантаження.
- Використовуйте
$pages->findMany() для масової конвертації на високонавантажених сайтах.
Продуктивність: ліниве завантаження зв'язків
За замовчуванням FieldtypePage завантажує пов'язані об'єкти при зверненні. При великих списках використовуйте $pages->findMany() — потокова обробка без завантаження всього в пам'ять:
foreach ($pages->findMany("template=product, sort=title") as $product) {
echo $product->title . "\n";
}
Деталі про findMany()
Метод findMany() обробляє сторінки по одній, не зберігаючи їх у пам'ять. Це особливо важливо на сторінках із тисячами товарів. Він працює як генератор: при кожній ітерації завантажується лише поточна сторінка.
Типові терміни розробки шаблонів
| Задача |
Оцінка |
| Базовий шаблон (layout + nav + footer) |
4–8 год |
| Шаблон списку з пагінацією та фільтром |
8–16 год |
| Детальна сторінка зі зв'язками |
4–10 год |
| Система шаблонів для 10+ типів контенту |
3–6 днів |
| Інтеграція Twig + компонентний підхід |
2–4 дні |
Що входить у розробку?
- Архітектура шаблонів (init/main або controller+view)
- Налаштування prepend/append файлів
- Верстка всіх типових сторінок (список, детальна, 404)
- Оптимізація зображень (size, WebP, lazy loading)
- Базова SEO-розмітка (meta title, description, og:image)
- Документація по шаблонах і доступах
- Навчання команди замовника (1 година онлайн)
- Гарантія на код 3 місяці
Навчання та документація — окремий пункт: ми передаємо знання, щоб ви могли підтримувати проєкт самостійно.
Типові проблеми та їх вирішення
Невикористання буферизації виводу при prepend/append призводить до дублювання заголовків. Рішення — завжди вмикати prepend/append або застосовувати патерн контролера. Завантаження всіх пов'язаних сторінок одразу — для наборів більше 100 записів використовуйте $pages->findMany(). Ігнорування кешу зображень: ProcessWire кешує варіанти, але при частій зміні контенту очищайте кеш у /site/assets/files/. 404-сторінка обов'язкова: завжди викидайте Wire404Exception для захищених розділів.
Зв'яжіться з нами для безкоштовної консультації — обговоримо ваш проєкт. Замовте розробку кастомного шаблону ProcessWire та отримайте гнучкість і продуктивність.
Детальніше про атрибут loading на MDN — Wikipedia Core Web Vitals — метрики продуктивності.
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 з гарантією результату.
