Bitrix-моноліт з PHP-шаблонами вирішує 80% завдань. Решта 20% — високонавантажені сторінки, SEO для динамічного контенту, PWA, персоналізація з edge computing — потребують іншої архітектури. Ми пропонуємо headless-підхід: Next.js як фронтенд поверх Bitrix-бекенду. Bitrix керує контентом і бізнес-логікою, Next.js займається рендерингом. Це не заміна Bitrix, а розподіл відповідальності: Bitrix — надійний бекенд для e-commerce (замовлення, каталог, CRM, оплати), Next.js — сучасний фронтенд з SSR, SSG, ISR та відмінними Core Web Vitals. Наш досвід — 10+ років розробки на Bitrix та 50+ успішних проєктів. Оцінимо ваш проєкт за 1 день.
Архітектура headless Bitrix + Next.js
Bitrix виступає в ролі API-сервера. На його стороні розробляються REST-контролери через \Bitrix\Main\Engine\Controller або кастомні endpoint'и в /local/ajax/. Next.js працює на окремому сервері (Node.js), споживає Bitrix API та рендерить сторінки. Між ними — API-шар.
Browser → Next.js (SSR/SSG) → Bitrix REST API → DB
↓
Redis Cache
Типова схема запитів:
// next.js: getStaticProps для сторінки категорії
export async function getStaticProps({ params }) {
const [category, products] = await Promise.all([
fetchBitrix(`/api/catalog/category/${params.slug}`),
fetchBitrix(`/api/catalog/products?section=${params.slug}&limit=24`),
]);
return {
props: { category, products },
revalidate: 300, // ISR: перегенерація через 5 хвилин
};
}
Incremental Static Regeneration (ISR) — ключова фіча Next.js для e-commerce: сторінки генеруються статично при першому запиті та перегенеруються у фоні за розкладом. Це дає швидкість статики при актуальності динамічного контенту.
Чому Next.js кращий за традиційні PHP-шаблони Bitrix?
Порівняємо метрики: Next.js забезпечує LCP до 1.4 сек проти 4.8 сек у стандартного шаблону, а PageSpeed Mobile піднімається з 34 до 82 балів. Традиційний шаблон завантажується довше через монолітну архітектуру, тоді як Next.js з ISR віддає сторінку з кешу за мілісекунди. ISR — це різниця між втраченим клієнтом і конверсією.
API на стороні Bitrix
Створення чистого REST API поверх Bitrix без зайвих залежностей:
// /local/php_interface/include/api/catalog/ProductsController.php
class ProductsController extends \Bitrix\Main\Engine\Controller
{
public function getListAction(
string $section = '',
int $page = 1,
int $limit = 24,
string $sort = 'NAME',
string $order = 'ASC'
): array {
$filter = ['ACTIVE' => 'Y', 'IBLOCK_ID' => CATALOG_IBLOCK_ID];
if ($section) {
$sectionId = $this->getSectionIdBySlug($section);
$filter['SECTION_ID'] = $sectionId;
$filter['INCLUDE_SUBSECTIONS'] = 'Y';
}
$result = \CIBlockElement::GetList(
[$sort => $order],
$filter,
false,
['nPageSize' => $limit, 'iNumPage' => $page],
['ID', 'NAME', 'DETAIL_PAGE_URL', 'PREVIEW_PICTURE',
'PROPERTY_BRAND', 'CATALOG_PRICE_1']
);
$products = [];
while ($el = $result->GetNextElement()) {
$products[] = $this->formatProduct($el);
}
return [
'items' => $products,
'total' => (int)$result->SelectedRowsCount(),
'pages' => ceil($result->SelectedRowsCount() / $limit),
];
}
}
API має повертати нормалізовані дані, а не сирі Bitrix-структури зі сміттєвими полями ~PREVIEW_TEXT та IBLOCK_ELEMENT_ID. Докладніше про REST API Bitrix читайте в офіційній документації.
SSR для SEO-критичних сторінок
Картки товарів, сторінки категорій, статті блогу — кандидати на SSG/ISR. Кошик, чекаут, особистий кабінет — CSR (рендеринг на клієнті), SEO не потрібен.
// Динамічна генерація шляхів для товарів
export async function getStaticPaths() {
const products = await fetchBitrix('/api/catalog/products/slugs');
return {
paths: products.map(p => ({ params: { slug: p.slug } })),
fallback: 'blocking', // нові товари рендеряться при першому запиті
};
}
fallback: 'blocking' дозволяє обробляти нові товари без повної перегенерації сайту.
Кейс з нашої практики: Next.js фронтенд для fashion-ритейлера
Мережа магазинів одягу, онлайн-каталог ~35 000 SKU, сезонне поповнення. Проблема: Core Web Vitals LCP = 4.8 сек (ціль < 2.5 сек), Bitrix-шаблон важкий, повільний на мобільних.
Bitrix залишили як backend: управління товарами, замовлення, CRM, 1С-інтеграція. Розробили Next.js фронтенд.
Реалізація:
-
API Bitrix: контролери для товарів, категорій, брендів, пошуку, кошика (SSR-сумісний через cookie-сесію).
-
Next.js App Router (Next.js 14): Server Components для SEO-сторінок, Client Components для інтерактивних елементів (фільтр, кошик, авторизація).
-
Зображення:
next/imageз автоматичною оптимізацією, WebP, responsive srcset. Хостинг зображень через CDN (окремо від Bitrix). -
Пошук: Meilisearch з індексом з Bitrix, React-компонент instant search.
-
Кошик: state в Zustand + синхронізація з Bitrix-кошиком через REST API при кожній зміні.
| Метрика | Bitrix-шаблон | Next.js |
|---|---|---|
| LCP | 4.8 сек | 1.4 сек |
| CLS | 0.18 | 0.02 |
| FID / INP | 280 мс | 45 мс |
| PageSpeed Mobile | 34 | 82 |
| TTFB (категорія) | 820 мс | 180 мс (ISR кеш) |
Перехід зайняв 4 місяці: 1 місяць на API Bitrix, 3 місяці на Next.js фронтенд. Паралельно працював старий шаблон, перемикання — по DNS за хвилину.
Як інтегрувати кошик між Next.js та Bitrix?
Кошик — складний випадок при headless: він має працювати до авторизації, синхронізуватися з Bitrix при авторизації, не губитися при переході між сторінками. Рішення: guest_token в cookie, кошик зберігається в Bitrix за цим токеном. При авторизації — merge гостьового кошика з користувацьким. React-стан — лише UI-дзеркало серверного кошика.
Наші інженери гарантують, що кошик не загубиться: досвід десятків проєктів підтверджує надійність цієї схеми.
Деплой та інфраструктура
Next.js — Node.js-застосунок, потребує окремого процесу. Варіанти: Vercel (найпростіше, але дані йдуть за кордон), VPS/dedicated з PM2 + nginx, Docker-контейнер.
Nginx як reverse proxy перед Next.js та Bitrix:
# Статика та SEO-сторінки → Next.js
location / {
proxy_pass http://nextjs:3000;
}
# REST API → Bitrix
location /api/bitrix/ {
proxy_pass http://bitrix/local/ajax/;
}
# Адміністративна частина → Bitrix
location /bitrix/ {
proxy_pass http://bitrix;
}
Що входить в роботу
- Аудит поточного Bitrix-фронтенду та підготовка архітектури headless
- Проєктування REST API: ендпоїнти, схема даних, кешування
- Розробка чистих REST-контролерів в Bitrix
- Розробка Next.js застосунку: роутинг, SSG/ISR/SSR, компоненти
- Інтеграція кошика, авторизації, чекауту з Bitrix
- Налаштування CDN для зображень, кешування на рівні nginx
- Деплой, моніторинг, CI/CD
- Документація та навчання вашої команди
Терміни орієнтовно
MVP (каталог + картка + пошук) — 2–3 місяці. Повний фронтенд з кошиком, чекаутом, кабінетом — 4–6 місяців. Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проєкту.
Хочете покращити Core Web Vitals та SEO? Отримайте консультацію безкоштовно. Замовте аудит — ми підготуємо пропозицію під ключ.