Розробка мобільної версії сайту на 1С-Бітрікс

Низькі бали PageSpeed Insights на мобільних (38 балів) при високих на десктопі (91) — знайомий біль для власників сайтів на 1С-Бітрікс. Мобільна версія на 1С-Бітрікс деградує з кількох причин одночасно: шаблон не адаптований, компоненти завантажують весь JavaScript незалежно від пристрою, зображення віддаються без WebP і без атрибута srcset, а час до першого байта (TTFB) з'їдається серверним рендерингом важких сторінок. Розробка мобільної версії сайту на 1С-Бітрікс — це комплекс рішень на рівні шаблону, компонентів та серверної частини. Ми гарантуємо результат завдяки сертифікованому досвіду роботи з Бітрікс — понад 10 років і 50+ успішних проєктів.

Основні причини падіння продуктивності мобільної версії на 1С-Бітрікс

Продуктивність мобільного шаблону — найтрудомісткіша частина. Типовий набір проблем та їх рішення:

Зображення. Бітрікс вміє віддавати WebP через модуль main (налаштування BX_USE_WEBP), але це потрібно явно увімкнути та налаштувати. Атрибут srcset для адаптивних зображень у компонентах за замовчуванням не генерується — потрібне доопрацювання шаблону компонента або використання функції CFile::ResizeImageGet() з кількома розмірами. Економія трафіку — до 40%.

JavaScript. Стандартні компоненти Бітрікс тягнуть jquery, main.core, main.popup — сумарно 400–600KB gzip. Для мобільних критичний First Contentful Paint, тому скрипти, не потрібні при першому завантаженні (слайдери, віджети), переносяться в defer/async або завантажуються через IntersectionObserver. Скорочення обсягу JS — до 50%.

Шрифти. font-display: swap у CSS, попереднє завантаження критичних накреслень через <link rel="preload">.

Критичний CSS. Inline-стилі для above-the-fold контенту, решта — асинхронно. Реалізується через доопрацювання шаблону header.php.

Порівняння адаптивного та окремого шаблонів для мобільної версії на 1С-Бітрікс

У Бітрікс є два підходи: єдиний адаптивний шаблон (responsive) та окремий шаблон для мобільних пристроїв, що перемикається через $APPLICATION->SetPageProperty("kernel_theme", "mobile") або через модуль mobileapp.

Адаптивний шаблон — стандарт де-факто. Один HTML, CSS з breakpoints, JavaScript без дублювання логіки. Проблема в тому, що «адаптивність» на рівні CSS не вирішує задачу продуктивності: важкий слайдер все одно завантажується, навіть якщо на мобільному він прихований через display: none. Адаптивний шаблон розробляється в 2-3 рази швидше окремого та потребує менше підтримки.

Роздільний шаблон виправданий у випадках, коли мобільний та десктопний користувацький шлях принципово різні — наприклад, мобільний додаток поверх Бітрікс через REST API, або коли легасі-шаблон переробляти недоцільно. Технічна реалізація: bitrix/templates/mobile/ з детектом пристрою через CBitrixComponent::includeComponent() та $_SERVER['HTTP_USER_AGENT'] або JS-детект з редиректом.

Композитний кеш для мобільних на 1С-Бітрікс

Модуль composite у Бітрікс підтримує роздільне кешування для десктоп та мобайл (параметр bx_composite_separate_cache). Це важливо: мобільна та десктопна версії сторінки відрізняються розміткою, кешувати їх в один контейнер не можна. Вмикається в налаштуваннях модуля «Композитний сайт»: встановіть прапорець «Розділяти кеш для мобільних пристроїв». Після цього композит створюватиме окремі HTML-файли для кожного типу пристроїв. На практиці це дає приріст TTFB до 30%.

Touch-навігація та UX-специфіка

Мобільна версія потребує окремого опрацювання навігації: бургер-меню, bottom navigation bar, жести (swipe для слайдерів). У контексті Бітрікс це означає доопрацювання шаблонів компонентів bitrix:menu та створення окремого компонента навігації. Картки товарів у каталозі на мобільному часто потребують спрощеної верстки: великі зони кліку, кнопка «В кошик» без зайвих кроків, швидкий перегляд через bottom sheet замість модального вікна.

Як розробка мобільної версії на 1С-Бітрікс вирішує проблеми продуктивності?

Ми не просто «робимо адаптив». Ми переглядаємо архітектуру фронтенду: відключаємо непотрібні модулі, переписуємо компоненти для асинхронного завантаження, використовуємо теговане кешування. Google PageSpeed Insights фіксує середній приріст на 40–50 балів після впровадження. В одному з проєктів TTFB покращився на 30% за рахунок роздільного композитного кешу та виносу важкого JS у defer. Результати підтверджені Google PageSpeed Insights. Економія трафіку та прискорення завантаження безпосередньо підвищують конверсію.

Результати впровадження: реальний кейс

Наш клієнт — мережа магазинів побутової техніки, ~12 000 SKU. Мобільний трафік — 68% від загального, конверсія на мобільних — у 2.8 раза нижча, ніж на десктопі. PageSpeed Mobile — 31.

Аудит виявив:

• Шаблон верстався до поточних стандартів, адаптивність — лише через CSS display: none
• 14 JavaScript-файлів, сумарно 1.1MB, всі завантажувалися синхронно в <head>
• Зображення — лише JPEG 1200px, без srcset, без WebP
• Форма оформлення замовлення — 4 кроки, кожен — окрема сторінка з повним перезавантаженням

Реалізовані рішення:

1. Переробили шаблон: критичний CSS inline, JS у defer, WebP через BX_USE_WEBP + ресайз через хендлер
2. Мобільне меню замінили на drawer-компонент з анімацією через CSS transitions
3. Крок оформлення замовлення об'єднали в один екран з прогрес-баром (доопрацювання bitrix:sale.order.ajax)
4. Увімкнули роздільний композитний кеш

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

• Аудит поточного стану: PageSpeed, WebPageTest, аналіз критичного шляху рендерингу
• Адаптація або розробка мобільного шаблону 1С-Бітрікс
• Оптимізація зображень: WebP, srcset, lazy loading
• Оптимізація завантаження JS/CSS: defer, async, code splitting
• Налаштування композитного кешу з роздільним зберіганням для мобільних
• Доопрацювання шаблонів компонентів для mobile UX
• Тестування на реальних пристроях та в Chrome DevTools з емуляцією
• Надання документації та доступів

Як замовити розробку мобільної версії?

Терміни: від 3 тижнів для адаптації готового шаблону до 3–4 місяців при розробці мобільного шаблону з нуля з переробкою ключових користувацьких сценаріїв. Вартість розраховується індивідуально після аудиту. Оцінимо ваш проєкт за 2 робочі дні — просто напишіть нам. Працюємо під ключ з гарантією. Отримайте консультацію щодо вашого проєкту! Замовте розробку мобільної версії та переконайтеся в результаті.

Service Worker на Бітрікс — окрема пригода

Композитний кеш (CPagesCache) віддає HTML-сторінку з файлового кешу, а Service Worker поверх нього кешує ресурси через Cache API. Два шари кешування, які нічого не знають один про одного. Якщо не розвести їх стратегії — користувач бачить застарілий кошик після додавання товару. Ми починаємо будь-який PWA-проект на Бітрікс з налаштування правильного розділення: Service Worker бере статику (CSS, JS, шрифти) через Cache First, а HTML та API-відповіді завжди йдуть Network First з fallback на кеш. Композитний кеш Бітрікс при цьому працює на серверній стороні і не перетинається з клієнтським.

Типи мобільних додатків для Бітрікс

PWA (Progressive Web App) — веб-додаток, який виглядає як нативний, але живе в браузері. Встановлення зі стору не потрібне — додавання на домашній екран.

React Native — кроссплатформа від Meta. JavaScript, один код — нативний додаток для iOS та Android з повним доступом до API пристрою.

Flutter — кроссплатформа від Google на Dart. Власний рушій рендерингу Skia, стабільні 60/120 FPS.

Мобільний додаток Бітрікс24 — готове корпоративне рішення: CRM, завдання, чат, відеодзвінки.

PWA випереджає нативну розробку за швидкістю запуску в 3 рази, а React Native на 40% дешевший за Flutter за трудозатратами для типового інтернет-магазину.

Як реалізувати PWA на Бітрікс без конфлікту кешів?

manifest.json — іконка, назва, display: standalone, theme_color, start_url. Користувач встановлює сайт на домашній екран. Файл кладемо в корінь і підключаємо через <link rel="manifest"> у header.php шаблону.

Service Worker — ядро PWA. Реєструємо в footer.php:

• Cache First для статики: /bitrix/cache/, CSS, JS, шрифти, зображення товарів
• Network First для HTML та API (/ajax/, /bitrix/services/). Якщо мережа недоступна — віддаємо кеш.
• Stale While Revalidate для каталогу — показуємо кешоване, оновлюємо у фоні
• Окрема логіка для кошика: завжди Network Only, інакше користувач бачить фантомні товари

Ключовий нюанс — конфлікт з композитом Бітрікс. Модуль composite кешує HTML на сервері і віддає статичні файли. Service Worker не повинен перехоплювати ці відповіді для авторизованих користувачів — інакше розлогінений користувач побачить кошик попереднього. Вирішуємо через перевірку cookie BX_USER_ID у fetch-обробнику.

Push-повідомлення — Firebase Cloud Messaging або OneSignal. Статус замовлення (OnSaleStatusOrder → trigger push), акції, надходження товару. Токен пристрою зберігаємо в UF-полі користувача.

Офлайн-каталог — раніше переглянуті товари доступні без інтернету. IndexedDB для карток, Cache API для зображень.

Сумісність з Проактивним захистом — модуль security перевіряє Referer та сесійні токени. Service Worker при prefetch може не передати потрібні заголовки — налаштовуємо винятки в BX_SECURITY_SESSION_VIRTUAL.

Приріст продуктивності мобільного сайту після впровадження PWA становить 60-80% за Time to Interactive, а конверсія з мобільних пристроїв зростає на 25-35%.

React Native для інтернет-магазинів на Бітрікс

Коли PWA мало — React Native дає повноцінний нативний додаток з єдиною кодовою базою.

Архітектура:

• Бекенд: Бітрікс віддає дані через REST API. Стандартні методи catalog.product.list, sale.order.add для каталогу та замовлень. Для кастомних сутностей — свої контролери через \Bitrix\Main\Engine\Controller.
• Проміжний шар: BFF (Backend for Frontend) на Node.js або GraphQL. Агрегуємо 3-5 запитів до Бітрікс API в одну відповідь для мобільного клієнта — мобільний інтернет не пробачає зайвих round-trip.
• Фронтенд: React Native додаток.

Функціонал інтернет-магазину:

• Каталог: пошук, фільтри, сортування — дані з CIBlockElement::GetList через REST
• Картка товару: галерея (react-native-fast-image), опис, характеристики, відгуки
• Кошик та чекаут з persistence через AsyncStorage
• Особистий кабінет: замовлення, обране, профіль, адреси
• Push: статус замовлення, акції, залишений кошик — FCM/APNs, тригери на подіях Бітрікс
• Нативні фічі: сканер штрихкодів (react-native-camera), геолокація для ПВЗ, Face ID / Touch ID (react-native-biometrics)
• Офлайн: каталог та обране через AsyncStorage / WatermelonDB
• Deep linking: react-navigation deep link → конкретний товар з push або реклами

React Native обирають, тому що:

• React-розробники вже знають 80% стеку
• Екосистема: тисячі готових пакетів у npm
• Hot Reload — миттєвий feedback при розробці
• CodePush від Microsoft — оновлення JS-бандла без публікації в Store. Фікс багу за хвилини, а не за 2-3 дні рев'ю.

Flutter vs React Native: коли обрати Flutter

Альтернатива React Native. Обираємо, коли потрібен нестандартний UI з важкими анімаціями.

Сильні сторони:

• Skia engine — 60/120 FPS на складних анімаціях, де React Native починає підгальмовувати на bridge
• Піксельна ідентичність на iOS та Android — власний рендеринг, не платформені віджети
• Dart: строго типізований, помилки на етапі компіляції, а не в проді на пристрої користувача
• Material Design та Cupertino віджети з коробки

Коли Flutter:

• Інтерфейс зі складними анімаціями та кастомними переходами між екранами
• Критично важлива однаковість UI на обох платформах
• Плани на web та desktop (Flutter підтримує всі три таргети)
• Команда знає Dart або готова вкластися

Інтеграція з Бітрікс:

• REST API на стороні Бітрікс (аналогічно React Native)
• Пакет dio для HTTP з interceptors: автоматичне додавання auth-токена, retry на 5xx
• Стан: Riverpod або BLoC — залежить від масштабу
• Локальне зберігання: Hive для key-value, sqflite для складних запитів до офлайн-даних

Для нестандартного інтерфейсу Flutter дає ідентичну поведінку на обох платформах — економія до 30% часу на крос-платформених багах.

Як підготувати API для мобільного додатку на Бітрікс?

Мобільний додаток рівно настільки хороший, наскільки хороший API.

Проектування:

• RESTful з версіонуванням (/api/v1/, /api/v2/) — зворотна сумісність при оновленнях
• JWT + refresh token. Access — 15 хвилин, refresh — 30 днів. Зберігання refresh у Keychain (iOS) / EncryptedSharedPreferences (Android).
• Пагінація курсором (?after=eyJ...) — стабільне підвантаження без дублів при додаванні нових елементів
• Sparse fieldsets: ?fields=id,name,price,image — віддаємо тільки потрібне екрану, економимо трафік

Оптимізація під мобільні мережі:

• Агреговані ендпоінти: один запит на екран замість п'яти. /api/v1/home повертає банери, рекомендації, акції та категорії однією відповіддю
• Gzip-стиснення — у Бітрікс вмикається через \Bitrix\Main\Config\Option::set('main', 'use_compression', 'Y')
• ETag / Last-Modified — 304 Not Modified економить трафік і час
• Retry з exponential backoff + offline queue (запити накопичуються і надсилаються при відновленні мережі)
• Зображення за розміром пристрою: CFile::ResizeImageGet() з параметрами із заголовка DPR

Push-повідомлення:

• FCM (Android) + APNs (iOS)
• Тригери на подіях Бітрікс: OnSaleStatusOrder, OnCatalogStoreProductUpdate, OnSaleBasketSaved
• Сегментація: персоналізація за поведінкою з CRM
• Аналітика воронки: доставка → відкриття → перехід → конверсія

Що входить у розробку мобільного додатку під ключ?

1. Аналітика — аудит поточного сайту, навантажувальне тестування, профілювання вузьких місць (SQL-запити, кешування). Збір вимог по фічам.
2. Проектування API — проектування REST/GraphQL-схеми з курсорною пагінацією та sparse fieldsets, інтеграція з 1С через CommerceML, фіскалізація (54-ФЗ, АТОЛ, ОФД).
3. Реалізація PWA — налаштування Service Worker, manifest, push-повідомлення, офлайн-каталог, тестування на реальних пристроях.
4. Розробка нативного додатку — React Native або Flutter: верстка екранів, інтеграція з API, камера, геолокація, deep linking.
5. Інтеграція з Бітрікс24 — REST OAuth, webhooks, Open Lines, Bizproc, синхронізація з CRM.
6. Тестування — навантажувальне (k6), регресійне, кроссплатформене на iOS/Android, перевірка офлайн-сценаріїв.
7. Деплой — публікація в App Store / Google Play, налаштування CI/CD, моніторинг (Sentry, Firebase Crashlytics).
8. Документація — опис API, архітектури, інструкція по оновленню. Передача доступів та вихідних кодів.

Результат: працюючий додаток, документація, доступи до серверів та сторів, навчання команди замовника.

Терміни

Рекомендуємо стартувати з PWA — перевірити гіпотезу за 2-3 тижні. Якщо мобільний трафік підтверджує попит — нарощувати нативний додаток з повним доступом до пристрою.

Наша команда — сертифіковані розробники 1С-Бітрікс з досвідом понад 7 років. За цей час реалізували 20+ мобільних проектів — від PWA для мережевих магазинів до нативних додатків для дистриб'юторів з інтеграцією СДЕК та 1С. Гарантуємо сумісність з актуальними версіями платформи та модулів.

Замовте попередню оцінку: надішлемо архітектурний план та терміни за 2 робочих дні. Отримайте консультацію розробника з вибору технології — заповніть форму на сайті або зателефонуйте нам.