Разработка мобильной версии сайта на 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С. Гарантируем совместимость с актуальными версиями платформы и модулей. Progressive Web Apps, React Native, Flutter.

Закажите предварительную оценку: пришлём архитектурный план и сроки за 2 рабочих дня. Получите консультацию разработчика по выбору технологии — заполните форму на сайте или позвоните нам.