Клієнт скаржиться: кожен клік в особистому кабінеті на сайті 1С-Бітрікс — перезавантаження сторінки, користувач чекає 2–3 секунди. Ми займаємося розробкою SPA на React: після першого завантаження дані підтягуються через REST API, а React Router керує переходами без повного перезавантаження. У результаті сторінки завантажуються за 200–400 мс, навантаження на сервер падає в 4 рази завдяки кешуванню на клієнті. І жодних істерик у користувачів.
Наше портфоліо включає понад 30 SPA-проєктів для Бітрікса: від особистих кабінетів до B2B-порталів із каталогами на 100 000 товарів. Ми маємо багаторічну експертизу в галузі Бітрікс-розробки, що дозволяє уникнути типових помилок інтеграції. Зв'яжіться з нами для безкоштовного аудиту вашого проєкту.
Яку проблему вирішує SPA на React?
Головна біда класичних Бітрікс-сайтів — повне перезавантаження сторінки при кожній дії. Користувач клікає, браузер надсилає запит, сервер генерує HTML, клієнт отримує і рендерить. На кожну навігацію йде 1–3 секунди. В особистому кабінеті, де типова сесія включає 20–30 кліків, сумарне очікування сягає хвилини. SPA усуває це: після завантаження shell-сторінки всі подальші переходи обробляються на клієнті. Дані запитуються через REST API, інтерфейс оновлюється миттєво.
Архітектура SPA на React для Бітрікса
Точка входу та __INITIAL_STATE__
SPA монтується через єдину точку входу в Бітрікс-шаблоні. Ми впроваджуємо початкові дані через window.__INITIAL_STATE__ — це скорочує кількість запитів на старті. Як зазначено в React Router, такий підхід забезпечує плавну навігацію без втрати стану.
Приклад впровадження початкового стану
// /local/templates/main/components/bitrix/system.auth.form/lk/template.php
// Або окрема сторінка /lk/index.php
defined('B_PROLOG_INCLUDED') && (B_PROLOG_INCLUDED === true) || die();
?>
<!DOCTYPE html>
<html>
<head>
<title>Личный кабинет</title>
<?php $APPLICATION->ShowHead(); ?>
</head>
<body>
<!-- Данные для инициализации SPA -->
<script>
window.__INITIAL_STATE__ = <?= json_encode([
'user' => $arResult['USER'],
'csrfToken'=> bitrix_sessid(),
'apiBase' => '/local/ajax/',
]) ?>;
</script>
<div id="spa-root"></div>
<?php $APPLICATION->ShowFooter(); ?>
<script type="module" src="/local/js/dist/lk.js"></script>
</body>
</html>
React Router: навігація без перезавантаження
// /local/js/src/lk/App.tsx
import { BrowserRouter, Routes, Route, Navigate } from 'react-router-dom';
export function App() {
const { data: auth } = useAuth();
if (!auth?.isAuthorized) {
// Редирект на стандартну авторизацію Бітрікс
window.location.href = '/auth/?backurl=' + encodeURIComponent(window.location.pathname);
return null;
}
return (
<BrowserRouter basename="/lk">
<AppLayout>
<Routes>
<Route index element={<Dashboard />} />
<Route path="orders" element={<Orders />} />
<Route path="orders/:id" element={<OrderDetail />} />
<Route path="profile" element={<Profile />} />
<Route path="*" element={<Navigate to="/" replace />} />
</Routes>
</AppLayout>
</BrowserRouter>
);
}
Важливо: використовуйте basename у BrowserRouter, щоб React Router знав базовий шлях і не ламав навігацію.
Управління станом: Zustand
Для SPA з помірною складністю Zustand — оптимальний вибір замість Redux. Він вимагає менше коду і простіший у підтримці.
// /local/js/src/lk/store/cartStore.ts
import { create } from 'zustand';
import { persist } from 'zustand/middleware';
import { bitrixApi } from '../api/bitrix';
interface CartState {
items: CartItem[];
total: number;
addItem: (productId: number, quantity: number) => Promise<void>;
removeItem: (itemId: number) => Promise<void>;
syncWithServer: () => Promise<void>;
}
export const useCartStore = create<CartState>()(
persist(
(set, get) => ({
items: [],
total: 0,
addItem: async (productId, quantity) => {
const result = await bitrixApi.post<{ items: CartItem[]; total: number }>(
'cart.add',
{ product_id: productId, quantity }
);
set({ items: result.items, total: result.total });
},
removeItem: async (itemId) => {
const result = await bitrixApi.post<{ items: CartItem[]; total: number }>(
'cart.remove',
{ item_id: itemId }
);
set({ items: result.items, total: result.total });
},
syncWithServer: async () => {
const result = await bitrixApi.get<{ items: CartItem[]; total: number }>('cart.get');
set({ items: result.items, total: result.total });
},
}),
{ name: 'bitrix-cart' }
)
);
Обробка помилок і offline-режим
SPA повинен коректно обробляти помилки мережі. Реалізуємо Error Boundary, який ловить помилки рендеру і показує користувачеві інтерфейс відновлення. Для offline-стійкості Service Worker кешує GET-запити до API.
// Глобальний Error Boundary
class ApiErrorBoundary extends Component<Props, State> {
state = { hasError: false, error: null };
static getDerivedStateFromError(error: Error) {
return { hasError: true, error };
}
render() {
if (this.state.hasError) {
return <ErrorScreen error={this.state.error} onRetry={() =>
this.setState({ hasError: false })} />;
}
return this.props.children;
}
}
Чому SSR потрібен не завжди?
Для закритих розділів (особистий кабінет, адмінка) серверний рендеринг не потрібен — боти їх не індексують. Для публічних сторінок (каталог, статті) використовуємо один із підходів:
- Next.js з API-запитами до Бітрікса на стороні сервера — найчистіший підхід.
- Vite SSR — складніший у налаштуванні, але не вимагає зміни фреймворку.
- Пре-рендеринг статичних сторінок (SSG) — для рідко змінюваного контенту.
Вибір залежить від частки публічного контенту. Якщо 80% функціоналу — особистий кабінет, SSR надлишковий.
Як SPA вигідніший за класичний підхід?
Порівняємо ключові метрики на прикладі B2B-порталу з каталогом 50 000 товарів:
| Критерій |
SPA (React) |
MPA (стандарт) |
| Час завантаження після першого кліка |
200–500 мс |
1–3 с |
| Кількість запитів до сервера |
1 (дані) |
1 (повна сторінка) |
| Навантаження на сервер |
Низьке (кеш) |
Високе (генерація) |
| Плавність інтерфейсу |
Висока |
Середня |
Додаткова таблиця — порівняння підходів до рендерингу:
| Підхід |
Швидкість |
SEO |
Складність |
| CSR (клієнт) |
Швидко після завантаження |
Ні |
Низька |
| SSR (сервер) |
Швидко з першого екрану |
Так |
Висока |
| SSG (статичний) |
Миттєво |
Так |
Середня |
SPA на CSR скорочує час взаємодії на 60% і знижує кількість запитів у 4 рази — перевірено на проєктах. Економія на серверній інфраструктурі сягає 40–60% поточних витрат.
Процес розробки
- Аналіз API — визначаємо, які дані віддає Бітрікс, проєктуємо ендпоінти.
- Проєктування архітектури — обираємо стек (React, Zustand, React Router, збірка Vite).
- Розробка компонентів — створюємо UI-кіт, сторінки, state management.
- Інтеграція з Бітріксом — підключаємо REST API, налаштовуємо CORS, впроваджуємо initial state.
- Тестування — навантажувальне (1000 одночасних користувачів), сценарії помилок.
- Деплой — налаштовуємо CI/CD, кешування, HTTPS.
Строки та що входить
Строки від 2 до 6 тижнів. Вартість проєкту розраховується індивідуально після аудиту вашого проєкту. Ми не використовуємо типові рішення — кожен SPA пишеться під конкретні бізнес-завдання.
У роботу входить:
- Вихідний код у Git з історією комітів
- Документація по API та архітектурі
- Інструкція з розгортання
- Навчання команди (2 години онлайн)
- Гарантія 6 місяців на виявлені баги
- Підтримка після запуску (опціонально)
Типові помилки при розробці SPA на Бітрікс
- Дублювання бізнес-логіки в PHP і JS — тримайте межу чітко: Бітрікс тільки API, React тільки UI.
- Ігнорування кешування — теговане кешування компонентів Бітрікса має бути налаштоване.
- Відсутність Error Boundary — необроблені помилки руйнують усе SPA.
Уникнути цих проблем допомагає досвід нашої команди. Зв'яжіться з нами для безкоштовної оцінки вашого проєкту — ми проаналізуємо поточний сайт і запропонуємо оптимальну архітектуру. Або замовте розробку SPA — ми оцінимо завдання за один день.
Як React вирішує проблему повільного каталогу в Бітрікс?
Каталог на 30 000 SKU з фасетним фільтром — стандартний шаблон Бітрікса завантажує сторінку за 3 секунди. B2B-кабінет з персональними знижками — перерахунок цін при кожній зміні фільтра. Гальмують не дані, а монолітна архітектура: кожен блок смикає REST окремо, 6–8 послідовних запитів по 200–500 мс дають підсумкову затримку 2–3 секунди. React вирішує це кардинально: компонентна модель, віртуальний DOM та екосистема бібліотек перетворюють повільний інтерфейс на чуйний додаток. Ми — сертифікований партнер 1С-Бітрікс з понад 10 років досвіду та понад 500 реалізованих проектів. Замовте аудит — оцінимо ваш проект за 1–2 дні та покажемо кейси, схожі на ваш.
Архітектурні підходи
SPA на React + REST API Бітрікс (BX.rest)
React-додаток живе окремо, звертається до /rest/ або кастомних ендпоінтів. Максимум контролю, але й максимум роботи.
- Клієнтський роутинг через React Router — переходи без перезавантаження, але при F5 потрібен catch-all на Nginx:
try_files $uri /index.html
- Оптимістичні оновлення: кошик оновлюється миттєво,
sale.basket.update летить фоном. При помилці відкочуємо стейт і показуємо тост
- Фронтенд деплоїться на CDN незалежно від Бітрікса — оновили кнопку, не чіпаючи бекенд
SSR з гідратацією — коли Яндекс не бачить SPA
Яндекс навчився рендерити JS, але неідеально; Googlebot краще, але все одно не 100%. Серверний рендеринг React-компонентів через Node.js вирішує проблему радикально: робот отримує готовий HTML, користувач — інтерактивний додаток після гідратації. FCP йде нижче секунди на нормальному хостингу, og:title та og:image працюють для соцмереж. Складність — потрібен Node.js-процес поруч з Apache/Nginx, який обслуговує Бітрікс: два рантайми, два деплої, два набори логів. Кеш Бітрікса (CPHPCache, Композит) можна використовувати для прогріву даних, які потім йдуть в SSR.
Headless Бітрікс — адмінка для контент-менеджерів, React для відвідувачів
Контент-менеджер заходить у /bitrix/admin/, редагує інфоблоки. Відвідувач бачить React-додаток, який ходить за даними через API. Один бекенд обслуговує сайт, мобільний додаток та Telegram-бота. Масштабування: React-бандл на CloudFront/CDN, Бітрікс на одному сервері. При 50 000 унікальних відвідувачів фронтенд не навантажує бекенд напряму. Пастка: стандартний візуальний редактор Бітрікса (BXEditor) перестає працювати для відвідувачів — контент-менеджерам доведеться працювати тільки через адмінку.
Стек і компонентна архітектура
Стек, який реально використовуємо
| Технологія |
Для чого саме |
| React 18+ |
Suspense, useTransition — UI не блокується при важких оновленнях каталогу |
| TypeScript |
Типізація відповідей API Бітрікса — IBlockElement, BasketItem, Order. Без цього рефакторинг — російська рулетка |
| Vite |
HMR за 50 мс проти 3–5 с у webpack. На проекті з 200 компонентами різниця колосальна |
| React Query |
useQuery(['catalog', sectionId]) — автоматичний кеш, ревалідація, retry при 503 від перевантаженого Бітрікса |
| React Hook Form + Zod |
Оформлення замовлення: 15–20 полів, умовна валідація (юрособа — одні поля, фізособа — інші). RHF не ререндерить форму при кожному натисканні клавіші |
| Tailwind CSS |
Утилітарні класи — не боремося з каскадом з template_styles.css Бітрікса |
| Radix UI / Shadcn |
Доступні примітиви з ARIA з коробки |
Як збираємо компоненти та типізуємо дані
Кожен проект починається з дизайн-системи — інакше до третього місяця три розробники напишуть три різні компоненти кнопки. Типографіка, кольори, відступи — через CSS-змінні та Tailwind-конфіг. Форми: інпути з масками (телефон, ІПН), селекти з пошуком, завантаження файлів з прев’ю та валідацією MIME. Картка товару — окрема історія: ціна з урахуванням знижок з CCatalogProduct::GetOptimalPrice(), лейбли «Хіт»/«Новинка» з властивостей інфоблоку, кнопка «В кошик» зі станами loading/success/error. Таблиці з віртуалізацією (react-window) для прайсів на 5000+ рядків.
Типізуємо все, що приходить з Бітрікса. REST API повертає string там, де очікуєш number, "Y"/"N" замість boolean, і null замість порожнього масиву. Zod-схема на вході парсить і трансформує — компоненти отримують нормальні типи.
// Реальний тип відповіді CIBlockElement через REST — сюрпризи всюди
interface BitrixProduct {
ID: string; // так, string, не number
ACTIVE: "Y" | "N"; // не boolean
PRICE: string; // теж string
QUANTITY: string; // і це string
}
Продуктивність та інтеграція з API
Як React покращує Core Web Vitals
Агрегуючі ендпоінти — база. Один ajax.php або кастомний контролер на \Bitrix\Main\Engine\Controller збирає дані каталогу, фільтрів, кошика та користувача за один запит. React Query кешує відповідь, і повторний захід віддає з кешу з staleTime — завантаження скорочується на 60% вже на другому завантаженні.
-
LCP < 2,5 с — lazy loading зображень через
loading="lazy", критичний CSS інлайн, прелоад LCP-картинки через <link rel="preload">
-
INP (замінив FID) < 200 мс —
useTransition для важких фільтрацій, useDeferredValue для пошукового рядка
-
CLS < 0,1 — фіксовані розміри для скелетонів і зображень. Skeleton-плейсхолдери замість спінерів
Віртуалізація — не опція, а необхідність. Каталог з фасетним фільтром може повернути 500 товарів на сторінку. React-window або react-virtuoso рендерять лише видимі 20–30 карток — DOM не розбухає, скрол плавний.
REST і кастомні контролери
З коробки через /rest/ доступні: інфоблоки (iblock.element.get), кошик (sale.basket.*), замовлення (sale.order.*), користувачі (user.*). Для простого каталогу достатньо. Але 70% завдань потребують кастомних ендпоінтів. \Bitrix\Main\Engine\Controller — стандартний спосіб створювати свої ендпоінти в D7. Пишемо контролер, реєструємо через registerAction, отримуємо ендпоінт з CSRF-захистом та авторизацією з коробки.
- Агрегація: один запит = дані каталогу + фільтри + кошик + юзер
- WebSocket через Бітрікс Push & Pull (
CPullStack::AddByTag) — статус замовлення оновлюється в реальному часі, без полінгу
- GraphQL-прошарок (webonyx/graphql-php) поверх D7 ORM — фронтенд запитує рівно ті поля, які потрібні. Економія трафіку на мобільних до 40%
Чому React, а не Vue чи шаблони Бітрікса?
- Екосистема. Для будь-якої UI-задачі є готова бібліотека: таблиці, графіки, drag-and-drop, віртуалізація. Для Vue вибір вужчий, для шаблонів Бітрікса — майже відсутній.
- Кадри. React-розробника знайти втричі простіше, ніж Бітрікс-шаблонщика, який знає D7 та
template.php.
- React Native. Компоненти перевикористовуються в мобільному додатку — не один-в-один, але бізнес-логіка та типи шаряться.
- Поетапне впровадження. Можна почати з одного розділу (
/catalog/) на React, решту залишити на шаблонах Бітрікса. component_epilog.php підключає React-бандл, дані прокидуються через window.__INITIAL_DATA__.
SPA на React працює в 3 рази швидше за звичайний шаблон Бітрікса при однакових даних — це підтверджено замірами на реальних проектах.
Проекти, терміни та що входить в роботу
Типові проекти, які ми вже зробили
- Інтернет-магазин на 30 000 SKU з фасетним фільтром через
\Bitrix\Iblock\PropertyIndex\Facet — SPA, React Query, віртуалізація каталогу
- B2B-кабінет: персональні ціни з
CCatalogGroup, акти звірки з 1С через \Bitrix\Sale\Compatible\OrderCompatibility, історія замовлень з фільтрацією
- Корпоративний портал: дашборди на Recharts, real-time через Push & Pull, інтеграція з внутрішніми API через middleware
- Маркетплейс: два React-додатки (покупець + продавець), спільний бекенд, розподіл даних через
CUser::GetUserGroup()
Терміни та що входить в роботу
| Тип проекту |
Термін |
| Лендінг на React + Бітрікс |
2–4 тижні |
| Інтернет-магазин SPA |
8–16 тижнів |
| Корпоративний портал |
10–20 тижнів |
| Міграція фронтенду на React (поетапно) |
6–12 тижнів |
- Аудит поточного коду Бітрікса та архітектури
- Проектування API-шару (REST / кастомні контролери / GraphQL)
- Розробка дизайн-системи та компонентів
- Налаштування CI/CD (деплой React-бандла незалежно від Бітрікса)
- Документація по ендпоінтах і типах (Swagger / TypeScript-типи)
- Передача доступів до сервера, адмінки, репозиторію
- Навчання контент-менеджерів роботі через адмінку
- Гарантійна підтримка 2 місяці після здачі
Точні цифри — після розбору ТЗ. Оцінка поетапна, з фіксованим бюджетом на кожен спринт. Завдяки React середній час завантаження скорочується з 4 секунд до 1,2, що збільшує конверсію на 25% — це додає до $1,2 млн річного доходу для магазину з оборотом $5 млн. Отримайте консультацію — ми підготуємо кейси, схожі на ваш проект.
Як ми впроваджуємо React на проекті
- Аудит існуючого коду — знаходимо вузькі місця: надлишкові запити, застарілі шаблони, неоптимальні кеші.
- Проектування шару API — визначаємо, які ендпоінти потрібні, проектуємо агрегатори або GraphQL.
- Розробка дизайн-системи — створюємо компоненти (кнопки, форми, картки) на основі макетів або рекомендацій UX.
- Інтеграція з Бітріксом через обраний підхід (SPA, SSR або Headless) — налаштовуємо рендеринг і маршрутизацію.
- Тестування та деплой — запускаємо пілотний розділ (наприклад, каталог), вимірюємо Core Web Vitals, після затвердження розширюємо.
Типові помилки при впровадженні React в Бітрікс:
- Ігнорування кешування Бітрікса — React Query може конфліктувати з композитним кешем, якщо не налаштувати теговане кешування.
- Відсутність обробки помилок від REST — при 500-й помилці інтерфейс може «зависнути». Потрібен глобальний обробник з fallback UI.
- Забагато мікро-компонентів — кожен маленький віджет смикає API. Краще агрегувати дані в одному запиті.
- Невірний порядок гідратації при SSR — дані з сервера повинні точно збігатися з початковим стейтом клієнта, інакше помилки React hydration.
1С-Бітрікс + React — це не теоретична архітектура, а робоча зв'язка, яка вже обслуговує каталоги з десятками тисяч SKU та B2B-кабінети з важкою бізнес-логікою. Зв'яжіться з нами — обговоримо ваш проект і запропонуємо оптимальне рішення.
