Next.js Frontend for 1C-Bitrix: Headless Architecture

Bitrix monolithic architecture with PHP templates covers 80% of tasks. The remaining 20%—high-load pages, SEO for dynamic content, PWA, personalization with edge computing—require a different approach. We offer a headless solution: Next.js as the frontend on top of a Bitrix backend. Bitrix manages content and business logic, Next.js handles rendering. This is not a replacement for Bitrix but a separation of responsibilities: Bitrix is the reliable e-commerce backend (orders, catalog, CRM, payments), Next.js is the modern frontend with SSR, SSG, ISR, and excellent Core Web Vitals. Our team has 10+ years of Bitrix development experience and 50+ successful projects. We'll evaluate your project in 1 day.

Headless Architecture: Bitrix + Next.js

Bitrix acts as an API server. On its side, we develop REST controllers via \Bitrix\Main\Engine\Controller or custom endpoints in /local/ajax/. Next.js runs on a separate server (Node.js), consumes the Bitrix API, and renders pages. The API layer sits between them.

Browser → Next.js (SSR/SSG) → Bitrix REST API → DB
                            ↓
                       Redis Cache

Typical request flow:

// next.js: getStaticProps for a category page
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: regenerate every 5 minutes
  };
}

Incremental Static Regeneration (ISR) is a key Next.js feature for e-commerce: pages are statically generated on first request and regenerated in the background on a schedule. This gives static speed with dynamic content freshness.

Why Next.js Outperforms Traditional Bitrix PHP Templates

Let's compare metrics: Next.js achieves LCP up to 1.4 seconds versus 4.8 seconds with a standard template, and PageSpeed Mobile climbs from 34 to 82. Traditional templates load slower due to monolithic architecture, while Next.js with ISR serves pages from cache in milliseconds. ISR is the difference between a lost customer and a conversion.

API Development on the Bitrix Side

Creating a clean REST API on top of Bitrix without unnecessary dependencies:

// /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),
        ];
    }
}

The API must return normalized data, not raw Bitrix structures with junk fields like ~PREVIEW_TEXT and IBLOCK_ELEMENT_ID. For more on Bitrix REST API, see the official documentation.

SSR for SEO-Critical Pages

Product cards, category pages, blog articles are candidates for SSG/ISR. Cart, checkout, personal account are CSR (client-side rendering) – SEO is not needed.

// Dynamic path generation for products
export async function getStaticPaths() {
  const products = await fetchBitrix('/api/catalog/products/slugs');

  return {
    paths:    products.map(p => ({ params: { slug: p.slug } })),
    fallback: 'blocking', // new products render on first request
  };
}

fallback: 'blocking' allows handling new products without full site regeneration.

Case Study: Next.js Frontend for a Fashion Retailer

A clothing retail chain with an online catalog of ~35,000 SKUs and seasonal restocking. Problem: Core Web Vitals LCP = 4.8 sec (target < 2.5 sec), the Bitrix template was heavy and slow on mobile.

We kept Bitrix as the backend: product management, orders, CRM, 1C integration. We developed a Next.js frontend.

Implementation:

1. Bitrix API: controllers for products, categories, brands, search, cart (SSR-compatible via cookie session).

2. Next.js App Router (Next.js 14): Server Components for SEO pages, Client Components for interactive elements (filters, cart, authentication).

3. Images: next/image with automatic optimization, WebP, responsive srcset. Images hosted on CDN (separate from Bitrix).

4. Search: Meilisearch with index from Bitrix, React component for instant search.

5. Cart: state managed by Zustand + synchronization with Bitrix cart via REST API on every change.

The migration took 4 months: 1 month for Bitrix API, 3 months for Next.js frontend. The old template ran in parallel; switchover was done via DNS in minutes.

How to Integrate Cart Between Next.js and Bitrix?

The cart is challenging in headless: it must work before authentication, sync with Bitrix upon login, and not get lost when navigating between pages. Solution: guest_token in a cookie, cart stored in Bitrix by this token. On login – merge guest cart with user cart. React state is only a UI mirror of the server cart.

Our engineers guarantee no cart loss: decades of project experience confirm this scheme's reliability.

Deployment and Infrastructure

Next.js is a Node.js application requiring a separate process. Options: Vercel (simplest but data goes abroad), VPS/dedicated with PM2 + nginx, Docker container.

Nginx as a reverse proxy in front of Next.js and Bitrix:

# Static and SEO pages → Next.js
location / {
    proxy_pass http://nextjs:3000;
}

# REST API → Bitrix
location /api/bitrix/ {
    proxy_pass http://bitrix/local/ajax/;
}

# Admin section → Bitrix
location /bitrix/ {
    proxy_pass http://bitrix;
}

What's Included in the Work

• Audit of your current Bitrix frontend and headless architecture planning
• REST API design: endpoints, data schema, caching
• Development of clean REST controllers in Bitrix
• Next.js application development: routing, SSG/ISR/SSR, components
• Integration of cart, authentication, checkout with Bitrix
• CDN setup for images, nginx-level caching
• Deployment, monitoring, CI/CD
• Documentation and team training

Estimated Timelines

MVP (catalog + product page + search) – 2–3 months. Full frontend with cart, checkout, personal account – 4–6 months. Pricing is individual – contact us for a project estimate.

Want to improve Core Web Vitals and SEO? Get a free consultation. Order an audit – we'll prepare a turnkey proposal.

Why does website layout for 1C-Bitrix require professionalism?

Open template.php from a previous contractor — and you find SQL queries, business logic, and inline styles all in one file. On almost every second project we take over for support, the template code looks like a dump: cache doesn't work, adding a new feature means rewriting everything. Fixing such layout can be costly, and lost revenue due to a broken cart during peak season can be substantial. Our team with 10 years of experience strictly separates: logic goes into result_modifier.php or component_epilog.php, presentation into template.php. No CIBlockElement::GetList in templates. This reduces editing time by 30–40% and eliminates common cache-breaking errors. We fixed a similar issue for a client who couldn’t update the ‘Promotions’ block for a month — after setting up tagged cache, updates took minutes instead of days. Want the same results? Get a free audit of your current layout.

How to properly organize component templates?

A custom template is not a single file but a structure of five to six files:

• template.php — only HTML and output of $arResult
• result_modifier.php — data preparation, additional queries
• component_epilog.php — code after caching (counters, dynamic content)
• style.css and script.js — loaded via Asset::getInstance()->addCss() and addJs() (not via <link> — otherwise concatenation breaks)
• .parameters.php — visual editor parameters

Example structure for a catalog:

local/templates/your_template/components/bitrix/catalog.section/.default/
├── template.php
├── result_modifier.php
├── component_epilog.php
├── style.css
├── script.js
└── .parameters.php

Typical templates we develop turnkey:

Caching: why does it break and how do we fix it?

Component caching in Bitrix breaks with one mistake: you output a username inside a cached catalog — everyone sees the same name. Solution — use component_epilog.php for dynamic inserts.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) is configured by default. Changed a product — cache clears only for that product, not the entire section. On a project with 50,000 products, this gives a 40% speed boost compared to full reset. Official Bitrix documentation recommends using component_epilog.php for dynamic inserts. Real case. A client complained that everyone saw the same cart on the catalog page. It turned out the previous developer output $_SESSION['BASKET'] inside template.php of the catalog.section component. The component was cached for an hour — the cart was frozen. We moved the output to component_epilog.php and configured tagged cache on sale.basket.basket.line. The page didn’t lose speed, the cart became up-to-date. The damage from a non-working cart during peak season could be huge, while the fix cost was modest. Tagged cache reduces page rebuild time by 50× compared to full reset.

CSS approaches: BEM, Tailwind, or hybrid?

For large projects (30+ templates) we use BEM — .product-card__price, .product-card--featured. Styles are isolated, no conflicts. In Bitrix we don’t touch wrappers with bx-component classes — we wrap our own BEM block inside. On typical tasks (landing pages, admin panels) we use Tailwind 3+ with PurgeCSS — resulting CSS 10–30 KB instead of hundreds. Design tokens in tailwind.config.js lock colors, fonts, spacing in one place. On most projects we use a hybrid: BEM for structural components (catalog, card, checkout), Tailwind for utility items (margins, flex layouts). We agree on the boundary with the team in advance.

How do we achieve Core Web Vitals?

Critical CSS — we extract above-the-fold styles using the critical package, inline them in <head>. The rest loads asynchronously via media="print" onload="this.media='all'". LCP on mobile decreases by 1–1.5 seconds.

Images — the main bottleneck. We use <picture> with WebP and JPEG fallback. loading="lazy" for everything below the fold. width and height explicitly set — CLS = 0. A handler in urlrewrite.php generates WebP on the fly.

Minification and compression. CSS and JS via Vite or Bitrix built-in concatenation. Brotli on nginx (brotli_comp_level 6) — 15–20% more efficient than gzip. Static caching: expires 1y + versioning via query string.

For a catalog of 10,000 products, LCP went from 4.2 s to 2.1 s. Conversions improved by 12% after the speed fix. Want similar results? Order a free audit — we’ll evaluate your current layout and propose specific steps.

Deliverables after layout completion

When you order template development or adaptation, you receive:

• Source files of component templates with separation into template.php, result_modifier.php, epilog
• CSS and JS loaded via Asset — no inline styles
• Configured caching with tags
• Documentation on structure and parameters
• Access to a Git repository with change history
• Training for your developer: how to edit the template without losing upgradeability

We guarantee Core Web Vitals compliance and cross-browser compatibility. Each project is assigned a lead engineer with 10+ years of Bitrix experience.

Process:

1. Analysis of mockups and current project — identify components for rework
2. Structure design — break the page into BEM blocks
3. Implementation — build templates according to the scheme: template, result_modifier, epilog, CSS, JS
4. Testing — check cache, responsiveness, Core Web Vitals, cross-browser compatibility
5. Deployment — staging, acceptance, production

At each stage you get intermediate results and can make corrections. Contact our team for a project estimate — we’ll provide a timeline and cost within 1–2 days after receiving mockups.

Common mistakes in Bitrix layout

• SQL queries inside template.php — breaks caching and creates heavy load
• Inline <style> and <script> — breaks Asset concatenation and slows loading
• Missing result_modifier.php — logic mixed with presentation
• Direct $_REQUEST in cached components — user-specific data leaks
• Not using component_epilog.php for dynamic content — entire cache invalidated on each user action

Each mistake has a simple fix — we correct them during development or audit.

Timelines

Ready to improve your layout? Order a preliminary consultation — we’ll calculate timelines and budget individually.