Коли headless WordPress виправданий?
У вас уже є сайт на WordPress, але клієнти скаржаться на повільне завантаження, а редактори звикли до адмінки. Переїжджати на іншу CMS — ризик втратити контент і SEO-позиції. Headless WordPress залишає адмінку для контенту, а фронтенд переписується на сучасному стеку (Next.js, React, Vue). Це дає швидкість SPA, гнучкість компонентів і звичний редактор. Не варто обирати headless, якщо сайт будується з нуля і немає жорстких вимог — звичайний WordPress простіший і дешевший.
Як ми це робимо: розбір на реальному кейсі
Для одного з проєктів ми використовували WordPress + Next.js 14 з ISR. Вихідні дані: 10 000 постів, 5 категорій, ACF-поля для портфоліо. Проблема — сторінки завантажувалися за 4 секунди (LCP > 4s). Після headless-інтеграції LCP впав до 1.2 с, TTFB — з 800 до 120 мс. Зниження навантаження на сервер у 3 рази (з 8 до 3 запитів на сторінку).
Ключові кроки:
- Налаштування REST API — увімкнули
_fields для мінімізації відповіді, вимкнули невикористовувані ендпоінти.
- CORS та безпека — дозволили лише домен фронту, додали валідацію Origin.
- ACF в API — через
register_rest_field додали метаполя прямо у відповідь.
- Next.js API-клієнт — єдиний fetch з ISR revalidate.
- Webhook on-demand revalidation — при публікації посту WordPress відправляє POST на
/api/revalidate в Next.js.
Результат: швидкість завантаження зросла на 70%, SEO-трафік збільшився на 25% за місяць.
Технічна реалізація: від REST API до on-demand revalidation
WP REST API: базові ендпоінти та оптимізація
WordPress REST API включено з версії 4.7. Базовий URL: https://site.com/wp-json/wp/v2/. Критично важливо використовувати параметр _fields — за замовчуванням відповідь містить десятки полів, більшість не потрібні.
# Список постів з потрібними полями
GET /wp-json/wp/v2/posts?_fields=id,title,slug,date,excerpt,featured_media&per_page=10
Як налаштувати CORS для headless WordPress?
add_action('rest_api_init', function () {
remove_filter('rest_pre_serve_request', 'rest_send_cors_headers');
add_filter('rest_pre_serve_request', function ($value) {
$allowed_origins = ['https://frontend.site.com', 'http://localhost:3000'];
$origin = $_SERVER['HTTP_ORIGIN'] ?? '';
if (in_array($origin, $allowed_origins, true)) {
header("Access-Control-Allow-Origin: {$origin}");
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
header('Access-Control-Allow-Headers: Authorization, Content-Type');
}
return $value;
});
}, 15);
Розширення REST API: ACF та кастомні ендпоінти
add_action('rest_api_init', function () {
register_rest_field('portfolio', 'acf', [
'get_callback' => function ($post) { return get_fields($post['id']); },
'schema' => ['type' => 'object'],
]);
register_rest_route('app/v1', '/home', [
'methods' => 'GET',
'callback' => function (WP_REST_Request $request) {
return rest_ensure_response([
'hero' => get_fields(get_option('home_hero_page_id')),
'featured' => array_map(fn($p) => [
'id' => $p->ID, 'title' => get_the_title($p), 'slug' => $p->post_name
], get_posts(['post_type' => 'portfolio', 'posts_per_page' => 3])),
]);
},
'permission_callback' => '__return_true',
]);
});
Інтеграція з Next.js: ISR та preview mode
const WP_API = process.env.WP_API_URL;
export async function getPosts(params = {}) {
const url = new URL(`${WP_API}/posts`);
url.searchParams.set('_fields', 'id,slug,title,excerpt,date,featured_image_url,acf');
const res = await fetch(url, { next: { revalidate: 60 } });
if (!res.ok) throw new Error(`WP API error: ${res.status}`);
return { posts: await res.json(), total: Number(res.headers.get('X-WP-Total')) };
}
Для preview mode додаємо API-роут /api/preview, який активує draftMode та редиректить на потрібний пост.
On-demand revalidation: WordPress → Next.js
При збереженні посту WordPress відправляє POST на /api/revalidate:
export async function POST(req: Request) {
const { secret, slug } = await req.json();
if (secret !== process.env.REVALIDATE_SECRET) return Response.json({ error: 'Forbidden' }, { status: 403 });
revalidatePath(`/blog/${slug}`);
revalidatePath('/blog');
return Response.json({ revalidated: true });
}
Кешування та продуктивність
REST API не кешується за замовчуванням. Ми додаємо Redis Object Cache або Nginx-кеш для анонімних запитів. Це знижує TTFB на 30–50% і навантаження на БД у 2 рази. Якщо у вас високі вимоги до швидкості — використовуємо Edge Cache (Cloudflare) з purge по webhook.
Що входить у роботу та терміни
| Етап |
Що робимо |
Результат |
| Аналітика |
Розбираємо контентну модель, типи записів, таксономії |
Документація з API-специфікацією |
| Налаштування WordPress |
CORS, ACF у REST, кастомні ендпоінти, вимкнення фронту |
Headless-режим |
| Розробка фронту |
API-клієнт, компоненти, ISR, preview mode |
Репозиторій з типами та хуками |
| Тестування |
Перевірка всіх ендпоінтів, кешування, навантажувальне тестування |
Протокол тестування |
| Деплой та передача |
Документація з оновлення контенту, доступи, навчання редакторів |
Git-репозиторій, README, дамп БД |
- Налаштування headless (CORS, ACF, ендпоінти) — 6–8 годин.
- Інтеграція з Next.js (клієнт, ISR, preview) — 1–1.5 робочих дні.
- Webhook та on-demand revalidation — 3–4 години.
Ми даємо гарантію на код 3 місяці та безкоштовну підтримку після деплою. За 10+ років ми інтегрували WordPress із десятками проєктів — від лендінгів до порталів з мільйонами відвідувачів. Зв'яжіться з нами — оцінимо ваш проєкт за один день.
Порівняння: Headless vs Традиційний WordPress
| Параметр |
Headless |
Традиційний |
| Швидкість завантаження |
LCP 1–1.5 с |
LCP 2–4 с |
| Гнучкість стеку |
Будь-який фреймворк |
PHP-шаблони |
| Складність розробки |
Вища |
Нижча |
| Зручність для редакторів |
Звична адмінка |
Та ж |
| Підтримка мультиплатформи |
Вбудована |
Потребує доопрацювання |
| Вартість підтримки |
Нижча (менше серверних ресурсів) |
Вища (PHP + MySQL) |
Headless WordPress — розумний вибір, коли важлива продуктивність і контроль над фронтендом. Не підходить, якщо бюджет обмежений або немає команди фронтендерів. Отримайте консультацію: ми допоможемо обрати архітектуру та оцінимо ваш проєкт безкоштовно. Замовте інтеграцію — перші результати через 2 дні.
Додаткові матеріали: REST API та ISR.
Розробка WordPress: кастомні теми, плагіни та WooCommerce
Клієнт приходить з готовим сайтом — і перше, що бачу в DevTools: 47 активних плагінів, сторінка важить 6.8 MB, TTFB 2.4 с, у консолі п'ять конфліктуючих версій jQuery. Це не рідкість — стандарт «доробленого» сайту, що виріс із шаблону в щось живе, але некероване. Ми вирішуємо такі завдання під ключ: від аудиту до деплою. Оцініть ваш проект за один робочий день — зв'яжіться з нами.
WordPress займає 43% ринку CMS (дані Wikipedia) — не тому що ідеальний, а тому що передбачуваний і має екосистему під будь-яке завдання. Завдання інженера — використовувати цю екосистему акуратно, не перетворюючи сайт на смітник залежностей. Ми допомагаємо знайти баланс між функціональністю та продуктивністю, спираючись на 10-річний досвід і 80+ виконаних проектів.
Чому кастомна тема швидша за page builder?
Page builders (Elementor, Divi) генерують роздутий HTML і прив'язують клієнта до візуального редактора назавжди. Кастомна тема на базі _s (underscores) завантажується в 4 рази швидше, ніж тема на Elementor, і не накопичує CSS/JS, які не використовуються. Критичний CSS витягується автоматично, а некритичні скрипти — в defer. На 30+ проектах ми переконалися: кастомна тема дає LCP на 60% нижче при однаковій кількості контенту.
Архітектурні рішення та часті проблеми
Блокування рендерингу через плагіни
Plugin A завантажує jQuery 3.6, Plugin B — jQuery 1.12, тема — свій jQuery Migrate. В результаті wp_enqueue_scripts віддає три різні версії бібліотеки, рендеринг сторінки блокується на 800 мс. Вирішується через wp_dequeue_script, централізований контроль залежностей та переведення некритичних скриптів у defer/async.
N+1 запити та їх вирішення
Розробник написав WP_Query в циклі — кожен пост генерує окремий SQL-запит. На сторінці з 20 постами це 21+ запит до бази. MySQL починає тупити, сервер гріється. Фіксується через post__in з prefetch або перехід на wpdb->get_results() з JOIN. Query Monitor — перший інструмент для діагностики.
WooCommerce під навантаженням
Магазин з 15 000 SKU без object caching і Redis — при 200 одночасних користувачах wc_get_product() вбиває базу. Транзиент-кеш WordPress не рятує: він пише в базу, збільшуючи навантаження. Реальне рішення — Redis через wp-redis або Memcached, плюс wp_cache_set()/wp_cache_get() в кастомному коді.
Як вибрати архітектуру: headless чи моноліт?
Вибір залежить від вимог до продуктивності та складності інтерфейсів. Headless (REST API / WPGraphQL + Next.js) дає приріст TTFB до 50% та ізоляцію фронтенду, але вимагає більш складної інфраструктури. Монолітна тема простіша в підтримці для контентних проектів, де SEO критичне і потрібен прямий доступ до WP Rewrite. Ми допомагаємо визначити оптимальний варіант на етапі аудиту. Перехід на headless покращує LCP у 2.5 рази порівняно з монолітом при правильному налаштуванні кешування — це підтверджено на 30+ проектах.
Стек та підходи в розробці WordPress
Розробка тем. Не використовуємо page builders для продуктових сайтів — вони генерують роздутий HTML. Кастомна тема на базі _s (underscores) завантажується в 4 рази швидше, ніж тема на Elementor. Замість цього: кастомна тема або блочна тема для Full Site Editing, Tailwind CSS через Vite, TypeScript для складного JS.
Gutenberg та блочна розробка. Розробляємо кастомні блоки через @wordpress/scripts, реєструємо через register_block_type() з block.json. Серверний рендеринг через PHP для SEO-критичних блоків, клієнтський — для інтерактивних. Inner Blocks для складених компонентів.
REST API та headless. WordPress як headless CMS через WP REST API v2 або WPGraphQL. Типова схема: WordPress на піддомені cms.example.com, Next.js фронтенд на основному домені. ISR (Incremental Static Regeneration) для сторінок блогу — сторінка регенерується у фоні при зверненні після закінчення revalidate. Для аутентифікованих запитів — JWT через jwt-authentication-for-wp-rest-api або Application Passwords (вбудовано з WP 5.6). Детальніше про REST API — Wikipedia.
WooCommerce. Розширюємо через хуки та фільтри — ніколи не правимо core-файли. Кастомні типи продуктів через WC_Product extension. Для складної логіки цін — woocommerce_get_price_html та woocommerce_product_get_price. Payment gateways пишемо з нуля, успадковуючи від WC_Payment_Gateway. Інтеграція з 1С — через CommerceML або кастомний REST endpoint.
Продуктивність. Обов'язковий стек: Redis Object Cache + Full Page Cache (LiteSpeed Cache або WP Rocket) + CDN для статики + WebP через add_image_size() з конвертацією. Lazy load нативний (loading="lazy") плюс кастомний для критичних зображень вище згину — preload через <link rel="preload">.
| Підхід |
Продуктивність |
Складність розробки |
SEO |
Рекомендується для |
| Монолітна тема |
Середня |
Низька |
Відмінна |
Контентні сайти, блоги, лендінги |
| Headless (REST/GraphQL) |
Висока |
Висока |
Хороша (з SSR) |
Веб-додатки, SPA, мультидомени |
| Headless + Next.js (ISR) |
Дуже висока |
Середня |
Відмінна |
Каталоги, новинні портали |
Кейс з нашої практики: WooCommerce‑магазин, LCP 9:00 с → 1.8 с
Наш клієнт — магазин електроніки з 40 000 SKU, WooCommerce + кастомна тема. PageSpeed Insights: LCP 9.2 с, CLS 0.41, INP 680 мс.
Діагноз:
- Hero-зображення 3.8 MB JPEG, не оптимізоване, без
srcset.
- 23 плагіни завантажували JS/CSS на кожній сторінці, включаючи сторінки продуктів.
-
wc_get_product() викликався 60 разів на сторінці категорії без кешування.
- Шрифти завантажувалися через Google Fonts (додатковий DNS lookup).
Що зробили:
- Hero — WebP 180 KB,
<img fetchpriority="high" decoding="async">, srcset для 3 breakpoints.
- Умовне завантаження плагінів через
is_product(), is_cart(), is_checkout() — прибрали 80% зайвого JS.
- Redis Object Cache,
WC_Product prefetch через wc_get_products() з include.
- Шрифти — self-hosted через
@font-face, font-display: swap.
- CLS перемогли через
aspect-ratio на всіх product card images.
Результат: LCP 1.8 с, CLS 0.04, INP 140 мс. Core Web Vitals — зелені. Клієнт скоротив витрати на хостинг на 40% — це дозволило перейти на дешевший тариф. Додатково заміна десяти плагінів на один кастомний заощадила 12 000 грн на рік на ліцензіях.
Процес роботи
-
Аудит та аналітика. Аналіз існуючої кодової бази, конкурентів, технічних вимог. Для нового сайту — семантичне ядро, UX-прототипування.
-
Архітектура. Вирішуємо: моноліт чи headless. Визначаємо Custom Post Types, Custom Fields (ACF або нативні
register_meta()), таксономії.
-
Розробка. Локальне середовище: Docker (nginx + php-fpm + MariaDB). Git з pre-commit хуками для PHP CS Fixer та ESLint. Деплой через WP-CLI + SSH або Buddy.works CI/CD.
-
Тестування. PHPUnit для кастомних плагінів. Playwright для E2E критичних сценаріїв (додати в кошик → оформити замовлення → підтвердження). Lighthouse CI в пайплайні — падаємо, якщо Performance Score < 85.
-
Деплой та підтримка. Staging через WP Stagecoach або ручний клон. Моніторинг — UptimeRobot + Sentry для PHP помилок. Оновлення плагінів — через WP-CLI в тестовому середовищі спочатку.
Що входить в роботу
- Повністю кастомна тема або доопрацювання існуючої.
- Налаштоване об'єктне кешування (Redis/Memcached) та Full Page Cache.
- Оптимізовані медіафайли: WebP, srcset, lazy load, preload критичних зображень.
- Видалення дублюючих плагінів та централізація функціоналу.
- Документація по структурі коду та інструкції по оновленню.
- Навчання контент-менеджерів роботі з блоками Gutenberg.
- Гарантія безперебійної роботи протягом 30 днів після деплою.
- Доступ до репозиторію з повною історією змін.
Як провести аудит WordPress сайту за 5 кроків?
- Перевірте
wp-config.php — чи увімкнено WP_DEBUG та WP_DEBUG_LOG. В продакшені вони мають бути вимкнені.
- Відкрийте Query Monitor і подивіться кількість запитів на головній. Норма — менше 30.
- Запустіть Lighthouse — зверніть увагу на LCP, CLS, INP. Якщо LCP > 2.5 с, шукайте блокуючі ресурси.
- Перевірте плагіни на дублювання функціоналу (наприклад, два плагіни кешування).
- Зробіть навантажувальний тест за допомогою Locust або k6 — 200 одночасних візитів не повинні викликати помилки тайм-ауту.
Типові помилки при розробці на WordPress
- Пряме редагування файлів теми — при оновленні теми всі зміни втрачаються. Завжди використовуйте дочірню тему або повністю кастомну.
-
update_post_meta() в циклі — кожен виклик окремий UPDATE. Для масових операцій застосовуйте $wpdb->update() або update_metadata_by_mid().
- Вимкнений
WP_DEBUG в розробці — приховані PHP Notice засмічують error log і часто вказують на реальні проблеми.
- Зберігання медіа в Git —
wp-content/uploads в .gitignore, синхронізація через WP-CLI media import або rsync.
- Немає ліміту на
WP_Query — posts_per_page => -1 на сторінці з тисячами записів гарантує таймаут.
Орієнтири по термінах
| Тип проекту |
Термін |
| Лендинг на кастомній темі |
2–3 тижні |
| Корпоративний сайт (10–30 сторінок) |
4–8 тижнів |
| WooCommerce-магазин (базовий) |
6–10 тижнів |
| WooCommerce + кастомна логіка + інтеграції |
3–6 місяців |
| Headless WordPress + Next.js |
8–16 тижнів |
Вартість розраховується індивідуально після аудиту вимог. Отримайте консультацію для попередньої оцінки.
Чому варто довірити розробку WordPress професіоналам?
Ми на ринку більше 10 років, виконали 80+ проектів, маємо сертифікати Automattic та досвід роботи з WooCommerce на високонавантажених майданчиках. Наші рішення враховують усі нюанси: від сумісності плагінів до вимог Core Web Vitals (рекомендації Google). Після завершення проекту ви отримуєте не просто сайт, а документовану, протестовану та готову до масштабування платформу.
Для консультації та оцінки вашого проекту — пишіть або телефонуйте. Ми відповідаємо протягом години в робочий час. Замовте аудит вже сьогодні.