Розробка фронтенду на Next.js для 1С-Бітрікс: headless-архітектура

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 фронтенд.

Реалізація:

1. API Bitrix: контролери для товарів, категорій, брендів, пошуку, кошика (SSR-сумісний через cookie-сесію).

2. Next.js App Router (Next.js 14): Server Components для SEO-сторінок, Client Components для інтерактивних елементів (фільтр, кошик, авторизація).

3. Зображення: next/image з автоматичною оптимізацією, WebP, responsive srcset. Хостинг зображень через CDN (окремо від Bitrix).

4. Пошук: Meilisearch з індексом з Bitrix, React-компонент instant search.

5. Кошик: state в Zustand + синхронізація з Bitrix-кошиком через REST API при кожній зміні.

Перехід зайняв 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? Отримайте консультацію безкоштовно. Замовте аудит — ми підготуємо пропозицію під ключ.