Разработка фронтенда на Next.js для 1С-Битрикс
Bitrix-монолит с PHP-шаблонами решает 80% задач. Оставшиеся 20% — высоконагруженные страницы, SEO для динамичного контента, PWA, персонализация с edge computing — требуют другой архитектуры. Next.js как фронтенд поверх Битрикс-бэкенда — это headless-подход: Битрикс управляет контентом и бизнес-логикой, Next.js занимается рендерингом.
Это не замена Битрикс, а разделение ответственности: Битрикс — надёжный бэкенд для e-commerce (заказы, каталог, CRM, оплаты), Next.js — современный фронтенд с SSR, SSG, ISR и отличными Core Web Vitals.
Архитектура headless Битрикс + Next.js
Битрикс выступает в роли API-сервера. На его стороне разрабатываются REST-контроллеры через \Bitrix\Main\Engine\Controller или кастомные endpoint'ы в /local/ajax/.
Next.js работает на отдельном сервере (Node.js), потребляет Битрикс 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: страницы генерируются статически при первом запросе и перегенерируются в фоне по расписанию. Это даёт скорость статики при актуальности динамического контента.
API на стороне Битрикс
Создание чистого REST API поверх Битрикс без лишних зависимостей:
// /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 должен возвращать нормализованные данные, а не сырые Битрикс-структуры с мусорными полями ~PREVIEW_TEXT и IBLOCK_ELEMENT_ID.
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 сек), Битрикс-шаблон тяжёлый, медленный на мобильных.
Битрикс оставили как backend: управление товарами, заказы, CRM, 1С-интеграция. Разработали Next.js фронтенд.
Реализация:
-
API Битрикс: контроллеры для товаров, категорий, брендов, поиска, корзины (SSR-совместимый через cookie-сессию).
-
Next.js App Router (Next.js 14): Server Components для SEO-страниц, Client Components для интерактивных элементов (фильтр, корзина, авторизация).
-
Изображения:
next/imageс автоматической оптимизацией, WebP, responsive srcset. Хостинг изображений через CDN (отдельно от Битрикс). -
Поиск: Meilisearch с индексом из Битрикс, React-компонент instant search.
-
Корзина: state в Zustand + синхронизация с Битрикс-корзиной через REST API при каждом изменении.
| Метрика | Битрикс-шаблон | 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 Битрикс, 3 месяца на Next.js фронтенд. Параллельно работал старый шаблон, переключение — по DNS в минуту.
Управление состоянием корзины в Next.js
Корзина — сложный случай при headless: она должна работать до авторизации, синхронизироваться с Битрикс при авторизации, не теряться при переходе между страницами.
Решение: guest_token в cookie, корзина хранится в Битрикс по этому токену. При авторизации — merge гостевой корзины с пользовательской. React-состояние — только UI-зеркало серверной корзины.
Деплой и инфраструктура
Next.js — Node.js-приложение, требует отдельного процесса. Варианты: Vercel (наиболее просто, но данные уходят за рубеж), VPS/dedicated с PM2 + nginx, Docker-контейнер.
Nginx как reverse proxy перед Next.js и Битрикс:
# Статика и SEO-страницы → Next.js
location / {
proxy_pass http://nextjs:3000;
}
# REST API → Битрикс
location /api/bitrix/ {
proxy_pass http://bitrix/local/ajax/;
}
# Административная часть → Битрикс
location /bitrix/ {
proxy_pass http://bitrix;
}
Состав работ
- Проектирование API: эндпоинты, схема данных, кеширование
- Разработка REST-контроллеров в Битрикс
- Разработка Next.js приложения: роутинг, SSG/ISR/SSR, компоненты
- Интеграция корзины, авторизации, чекаута с Битрикс
- Настройка CDN для изображений, кеширование на уровне nginx
- Деплой, мониторинг, CI/CD
Сроки: MVP (каталог + карточка + поиск) — 2–3 месяца. Полный фронтенд с корзиной, чекаутом, кабинетом — 4–6 месяцев.







