Developing Decoupled Frontend for 1C-Bitrix

We develop decoupled frontend for 1C-Bitrix: physically separate the interface from the CMS while preserving manageability and enabling gradual migration. We solve the problem where a standard Bitrix template hits a performance ceiling, yet a full redesign is too risky and costly. The decoupled approach gives you a modern UX (React/Vue, SPA, SSR) without stopping your business — we only replace critical pages, leaving the admin panel and SEO pages on the CMS.

Why Decoupled, Not Headless?

Headless means the entire site relies on an API and the CMS is merely a backend. That requires a complete architectural overhaul. Decoupled is the golden middle: you choose which pages to serve via SPA and which to keep on Bitrix templates. For example, the product catalog can be a React application, while content pages are still generated by the CMS. Comparison:

Decoupled frontend is 30% faster to implement compared to headless, yet delivers 90% of the interface performance gain. Plus, you retain existing Bitrix modules and business logic — no need to rewrite infoblocks, agents, or events.

How to Synchronize the Cart Between Bitrix and React?

The most common pain point in decoupled is the cart. The header icon (Bitrix template) must display the actual item count added via the React catalog. The solution is an Event Bus accessible in both worlds:

// shared/eventBus.js — accessible in both Bitrix part and React
window.BitrixEventBus = {
    listeners: {},
    emit(event, data) {
        (this.listeners[event] || []).forEach(cb => cb(data));
    },
    on(event, callback) {
        (this.listeners[event] ||= []).push(callback);
    }
};

// In a React component when adding to cart:
window.BitrixEventBus.emit('cart:updated', { count: newCount });

// In the Bitrix template (header):
window.BitrixEventBus.on('cart:updated', ({ count }) => {
    document.querySelector('.cart-counter').textContent = count;
});

This same pattern applies to syncing favorites, notifications, and any other global states. For more on the Bitrix24 REST API, see the official documentation.

The "Island" Pattern — Partial Frontend Integration

Instead of completely separating the frontend, you embed React components into an existing Bitrix template via mount points:

// In the Bitrix catalog component template
$catalogData = json_encode($arResult['ITEMS']);
?>
<div id="react-catalog"
     data-items="<?= htmlspecialchars($catalogData) ?>"
     data-currency="RUB">
</div>

<script src="/local/js/dist/catalog.bundle.js"></script>
<script>
  window.BitrixCatalog && window.BitrixCatalog.mount(
    document.getElementById('react-catalog'),
    <?= $catalogData ?>
  );
</script>

// catalog.bundle.js — built independently with Webpack/Vite
import { createRoot } from 'react-dom/client';
import { CatalogApp } from './CatalogApp';

window.BitrixCatalog = {
    mount(container, initialData) {
        const root = createRoot(container);
        root.render(<CatalogApp initialData={initialData} />);
    }
};

This approach lets you develop a React frontend with a full toolchain (TypeScript, hot reload, tests) without touching the rest of the Bitrix site.

Example: Product Catalog on React

Suppose you need to replace the standard Bitrix catalog component with an SPA that offers instant filtering. We create an API endpoint that returns products in JSON. The React application fetches the data and renders on the client. The server side stays on Bitrix — infoblocks, prices, stock. This reduces page load time by 40–60% and increases conversion by 15–25%.

Build Configuration (Vite)

// vite.config.js for decoupled Bitrix components
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
    plugins: [react()],
    build: {
        outDir: '../public/local/js/dist',
        lib: {
            entry: './src/index.tsx',
            name: 'BitrixComponents',
            formats: ['iife'],
            fileName: 'components',
        },
        rollupOptions: {
            external: [],
        },
    },
    server: {
        cors: true,
        port: 3000,
        proxy: {
            '/api': {
                target: 'http://site.local',
                changeOrigin: true,
            }
        }
    },
});

In development mode, the Vite dev server runs on localhost:3000 and the Bitrix site on site.local. API requests from the dev server are proxied through Vite proxy. After building, the bundle is automatically synced with the server.

Component Implementation Timeline Comparison

What Is Included in the Work

• Audit of the current Bitrix site architecture and identification of candidates for decoupling
• Development of an API layer (REST/GraphQL) between Bitrix and the new frontend
• Implementation of 2–3 components using the "island" pattern (catalog, cart, user account)
• Setup of CI/CD for automatic frontend building and deployment
• Integration of an Event Bus for state synchronization
• Documentation on mount points and API
• Performance testing (before/after measurements)

Work Process

1. Analysis — we study the existing site, load, and bottlenecks. Determine which pages to replace first.
2. Design — choose the stack (React/Vue), design the API, architect components.
3. Implementation — write code in parallel with your team. Weekly demos.
4. Testing — load testing, regression on Bitrix functionality.
5. Deployment — roll out gradually, monitor errors. 24-hour rollback capability.

Estimated Timelines

From 2 weeks for a single component to 2 months for a full turnkey migration. The cost is determined individually after an audit — get in touch, and we will evaluate your project.

Typical Mistakes in Decoupled

• Fully copying the design into React — you lose performance due to unnecessary re-renders.
• Missing bundle versioning — the browser caches old scripts. Use hashes: catalog.a1b2c3.js.
• Syncing state via HTTP instead of Event Bus — unnecessary delays.
• Forgetting SEO: if the SPA does not serve HTML, search engines will not see the pages. Use SSR or prerendering.
• Not setting up a proxy for development — the frontend cannot access the Bitrix API.

We have 10+ years of experience with Bitrix, 1C-Bitrix certifications, and over 50 successful projects. We provide a contractual guarantee on all work. Order an audit of your project — we will choose the optimal decoupled architecture. Get a consultation on implementation today.

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.