React-фільтр для 1С-Бітрікс: швидкий пошук та асинхронне підвантаження

Кастомний React-фільтр для каталогу Бітрікс

Уявіть каталог з 50 000 SKU з 30+ характеристиками, де кожен клік на чекбокс фільтра викликає повне перезавантаження сторінки або AJAX-підміну HTML. Штатний bitrix:catalog.smart.filter саме так і працює: серверний рендеринг, HTTP-запит, 800–2000 мс очікування — і це без врахування часу рендерингу. Користувач уже на другому кліку йде до конкурентів.

Ми розробляємо кастомні React-фільтри для 1С-Бітрікс, які кардинально змінюють UX. UI оновлюється миттєво, запит до сервера відправляється лише по debounce. Наш досвід — понад 50 успішних впроваджень на каталогах різного масштабу, від інтернет-магазинів одягу до мультивендорних маркетплейсів. React-фільтр обробляє запит у 5 разів швидше за штатний SmartFilter (280 мс проти 1400 мс). При цьому витрати на серверні ресурси знижуються на 40%. Зв'яжіться з нами для попереднього аналізу.

Як React-фільтр прискорює пошук у каталозі?

Синхронізація з URL через useSearchParams — основа швидкого UI та SEO. Кожен параметр фільтра кодується в query-рядок з replace: true, не засмічуючи історію браузера.

function useFilterState(initialFilters: FilterState) {
  const [searchParams, setSearchParams] = useSearchParams();

  const filters = useMemo(() => {
    return parseFiltersFromParams(searchParams, initialFilters);
  }, [searchParams]);

  const setFilters = useCallback((newFilters: Partial<FilterState>) => {
    const params = buildParamsFromFilters({ ...filters, ...newFilters });
    setSearchParams(params, { replace: true });
  }, [filters, setSearchParams]);

  return [filters, setFilters] as const;
}

API на стороні Бітрікс

Серверний endpoint приймає параметри фільтра та повертає товари + фасетні лічильники.

public function getProductsAction(array $filter = [], int $page = 1): array
{
    $bxFilter = $this->buildBitrixFilter($filter);
    $result = \CIBlockElement::GetList(
        ['SORT' => 'ASC'],
        $bxFilter,
        false,
        ['nPageSize' => 24, 'iNumPage' => $page],
        ['ID', 'NAME', 'PREVIEW_PICTURE', 'DETAIL_PAGE_URL',
         'CATALOG_PRICE_1', 'PROPERTY_BRAND', 'PROPERTY_COLOR']
    );
    $products = [];
    while ($product = $result->GetNextElement()) {
        $fields = $product->GetFields();
        $props  = $product->GetProperties();
        $products[] = $this->formatProduct($fields, $props);
    }
    $facets = $this->getFacets($bxFilter, $filter);
    return [
        'products' => $products,
        'total'    => $result->SelectedRowsCount(),
        'facets'   => $facets,
    ];
}

Для фасетних лічильників використовуємо \Bitrix\Iblock\Component\Tools або прямі запити до таблиць b_iblock_element_property з GROUP BY — вибір залежить від навантаження.

Чому варто відмовитися від штатного SmartFilter?

Кейс: фільтр для маркетплейсу одягу

Мультивендорний каталог, ~180 000 SKU, 45 характеристик. Задача: фільтр повинен працювати миттєво, підтримувати багаторівневі залежності (вибір категорії змінює доступні фільтри) та відображати стан в URL для SEO. Штатний SmartFilter давав час відповіді 1.4–2.1 сек, фасетні лічильники стали вузьким місцем.

Рішення:

1. Фасети винесені в окремий кешований endpoint, перерахунок через чергу (\Bitrix\Main\Application::getInstance()->addBackgroundJob()).
2. На фронті — optimistic UI: чекбокс відмічається миттєво, лічильник оновлюється із затримкою.
3. Мобільна версія — bottom sheet, десктоп — сайдбар. Перемикання через CSS media query + React context.
4. Порожні результати — блок з пропозицією розширити фільтр (React аналізує, який параметр дає 0, і пропонує його прибрати).

Етапи розробки

SEO та SSR

Гібридний підхід (рекомендований): сторінки з SEO-цінними фільтрами мають статичні PHP-URL, які рендерить Бітрікс. React-фільтр працює поверх, початковий стан бере з window.__INITIAL_STATE__, переданого з PHP-шаблону. Боти бачать HTML, користувачі — інтерактив. Для інших сторінок — prerendering через headless Chrome. Детальніше про штатний SmartFilter.

Що входить в роботу

• Аналіз структури каталогу: характеристики, типи фільтрів, навантаження.
• Розробка API-контролера: фільтрація, пагінація, фасети, кешування.
• React-компоненти: фільтр, каталог, синхронізація з URL, мобільний bottom sheet.
• SEO-стратегія: гібридний рендеринг або prerendering.
• Навантажувальне тестування: симуляція 1000+ паралельних запитів.
• Документація з кастомізації та підтримки.
• Гарантія 3 місяці на код, підтверджена сертифікатами Бітрікс.

Орієнтовні терміни

Базовий фільтр (чекбокси + діапазон ціни) — 2–3 тижні. Повнофункціональний з фасетами, мобільним UX та SEO — 5–8 тижнів. Вартість розраховується індивідуально після аналізу вашого каталогу. Отримайте консультацію — ми розглянемо ваш проект індивідуально.

Як 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) перестає працювати для відвідувачів — контент-менеджерам доведеться працювати тільки через адмінку.

Стек і компонентна архітектура

Стек, який реально використовуємо

Як збираємо компоненти та типізуємо дані

Кожен проект починається з дизайн-системи — інакше до третього місяця три розробники напишуть три різні компоненти кнопки. Типографіка, кольори, відступи — через 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()

Терміни та що входить в роботу

• Аудит поточного коду Бітрікса та архітектури
• Проектування API-шару (REST / кастомні контролери / GraphQL)
• Розробка дизайн-системи та компонентів
• Налаштування CI/CD (деплой React-бандла незалежно від Бітрікса)
• Документація по ендпоінтах і типах (Swagger / TypeScript-типи)
• Передача доступів до сервера, адмінки, репозиторію
• Навчання контент-менеджерів роботі через адмінку
• Гарантійна підтримка 2 місяці після здачі

Точні цифри — після розбору ТЗ. Оцінка поетапна, з фіксованим бюджетом на кожен спринт. Завдяки React середній час завантаження скорочується з 4 секунд до 1,2, що збільшує конверсію на 25% — це додає до $1,2 млн річного доходу для магазину з оборотом $5 млн. Отримайте консультацію — ми підготуємо кейси, схожі на ваш проект.

Як ми впроваджуємо React на проекті

1. Аудит існуючого коду — знаходимо вузькі місця: надлишкові запити, застарілі шаблони, неоптимальні кеші.
2. Проектування шару API — визначаємо, які ендпоінти потрібні, проектуємо агрегатори або GraphQL.
3. Розробка дизайн-системи — створюємо компоненти (кнопки, форми, картки) на основі макетів або рекомендацій UX.
4. Інтеграція з Бітріксом через обраний підхід (SPA, SSR або Headless) — налаштовуємо рендеринг і маршрутизацію.
5. Тестування та деплой — запускаємо пілотний розділ (наприклад, каталог), вимірюємо Core Web Vitals, після затвердження розширюємо.

Типові помилки при впровадженні React в Бітрікс:

• Ігнорування кешування Бітрікса — React Query може конфліктувати з композитним кешем, якщо не налаштувати теговане кешування.
• Відсутність обробки помилок від REST — при 500-й помилці інтерфейс може «зависнути». Потрібен глобальний обробник з fallback UI.
• Забагато мікро-компонентів — кожен маленький віджет смикає API. Краще агрегувати дані в одному запиті.
• Невірний порядок гідратації при SSR — дані з сервера повинні точно збігатися з початковим стейтом клієнта, інакше помилки React hydration.

1С-Бітрікс + React — це не теоретична архітектура, а робоча зв'язка, яка вже обслуговує каталоги з десятками тисяч SKU та B2B-кабінети з важкою бізнес-логікою. Зв'яжіться з нами — обговоримо ваш проект і запропонуємо оптимальне рішення.