Разработка PWA-приложения на 1С-Битрикс: кэширование, push, офлайн

Разработка PWA-приложения на базе 1С-Битрикс — это способ превратить сайт в прогрессивное веб-приложение с offline-доступом и push-уведомлениями. Стандартный модуль pwa в Битриксе генерирует базовый manifest.json и Service Worker, но не умеет версионировать кеш и не обрабатывает сложные сценарии: каталоги с тысячами товаров, авторизованных пользователей, интеграцию с composite. Мы дорабатываем Service Worker, настраиваем стратегии кеширования и обеспечиваем зелёный Lighthouse. Результат — экономия бюджета на нативной разработке и рост конверсии.

Какие проблемы решает PWA на Битриксе?

Штатный модуль pwa в Битриксе генерирует /manifest.json и регистрирует /sw.js, но не управляет версионированием кеша и не обрабатывает сложные сценарии офлайн-работы каталога. Для интернет-магазина с десятками тысяч товаров стандартный Cache First не подходит — нужны кастомные стратегии: Stale While Revalidate для API, Network First с fallback для HTML. Мы решаем эти задачи, адаптируя Service Worker под конкретный шаблон и бизнес-логику.

Другая проблема — взаимодействие с модулем composite. Композитный HTML кешируется Service Worker, и при обновлении контента (цены, остатки) пользователи видят устаревшие данные. Версионирование кеша через CACHE_VERSION устраняет это, а также правильное исключение динамических URL.

Как мы внедряем PWA на Битрикс?

Аудит текущего сайта

Оцениваем влияние composite, проверяем поддержку iOS, считаем Lighthouse-баллы. Выявляем узкие места: неверные start_url, отсутствие иконки 512×512, несовместимость стратегий кеширования. Подробнее о PWA можно узнать в Wikipedia.

Настройка Service Worker

Кастомную логику пишем в /local/templates/main/sw-custom.js и подключаем через importScripts(). Не модифицируем /sw.js напрямую — он перегенерируется модулем. Используем три стратегии:

• Cache First для статики (/bitrix/js/, /bitrix/css/, /upload/)
• Network First для HTML, исключая URL с sessid и AJAX-запросы к bitrix/services/main/ajax.php
• Stale While Revalidate для API-ответов каталога — отдаём из кеша, параллельно обновляя

Версионирование кеша

В manifest.json добавляем кастомное поле sw_version. При деплое инкрементируем, а Service Worker при активации очищает старые кеши:

const CACHE_VERSION = 'v1.4';
self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(keys =>
      Promise.all(keys.filter(k => k !== CACHE_VERSION).map(k => caches.delete(k)))
    )
  );
});

Почему версионирование кеша критично для PWA?

Без версионирования пользователи увидят устаревший контент даже после обновления сайта. Service Worker продолжает отдавать старые файлы, пока кеш не истечёт. Версионирование гарантирует, что после деплоя все получат свежие ресурсы — критично для интернет-магазинов с часто меняющимися ценами.

PWA или нативное приложение: что выбрать?

PWA разрабатывается в 3-5 раз быстрее нативного приложения и занимает в 10 раз меньше места. Для каталога, корпоративного сайта, новостного портала достаточно PWA. Для приложения с Bluetooth, NFC нужен нативный клиент.

Этапы и сроки внедрения

Этапы работ:

1. Аудит (2–3 дня) — проверка шаблона, влияния composite, Lighthouse.
2. Настройка модуля и Service Worker (3–5 дней) — manifest.json, стратегии кеширования, offline-страница, push-подписка.
3. Тестирование (2–3 дня) — Android (Chrome, Samsung Internet), iOS (Safari), десктоп; Lighthouse на каждом этапе.
4. Запуск и мониторинг (1–2 дня) — деплой, проверка метрик, алерты на ошибки Service Worker.

Сроки ориентировочно:

Стоимость рассчитывается индивидуально — свяжитесь с нами для консультации и оценки экономии.

Что входит в разработку PWA?

• Аудит и рекомендации
• Настройка manifest.json и кастомного Service Worker
• Реализация push-уведомлений через модуль pull
• Создание offline-страницы
• Документация и обучение администраторов
• Гарантийная поддержка 30 дней

Типичные ошибки при внедрении PWA

• iOS Safari не поддерживает Background Sync, Badge API, полноценные push без Home Screen.
• Обновление Service Worker — даже с skipWaiting() новая версия применяется только при следующем открытии страницы.
• Размер кеша ограничен: Chrome выделяет до 80% свободного места, Safari — 50MB на origin. Кешировать весь каталог на 10 000 товаров не получится — только критические ресурсы.
• Модуль composite с CDN может генерировать HTML с абсолютными URL CDN-домена — Service Worker не перехватит запросы к другому origin. Проверяем scope в register().

Получите консультацию — мы поможем определить оптимальный маршрут внедрения PWA на вашем проекте. Закажите аудит и оценку стоимости уже сегодня.

Как правильно проектировать инфоблоки?

Мы видим десятки проектов, где неправильная структура инфоблоков превращает сайт в тормоз. Типичный сценарий: заказчик просит «каталог товаров». Разработчик создаёт один инфоблок catalog, закидывает туда 15 свойств. Через полгода — 40 свойств, 8 из которых используются только для одной категории. Фильтр тормозит, таблица b_iblock_element_property разрослась до миллионов строк, CIBlockElement::GetList выполняется 3 секунды. Последствия — падение конверсии, потеря клиентов, дополнительные затраты на оптимизацию. В одном проекте после рефакторинга каталога время генерации страницы снизилось с 4,2 до 0,8 секунды, а стоимость поддержки сократилась на 250 000 рублей в год — за счёт устранения избыточных запросов и агентов.

Наш подход: проектируем инфоблоки до первой строки кода. Отдельные инфоблоки под сущности (товары, категории, бренды), свойства-справочники через highload-блоки, торговые предложения для SKU. Это закладывает производительность на годы вперёд. Если хотите получить предварительный аудит вашей схемы инфоблоков — свяжитесь с нами, разберём типовые ошибки и дадим рекомендации бесплатно.

Почему 1С-Битрикс выгоднее альтернатив?

Выбор CMS диктуется не предпочтениями, а бизнес-задачами. Вот ключевые аргументы:

• Нативный обмен с 1С — модуль catalog.import.1c обеспечивает двусторонний обмен товарами, ценами, остатками и заказами через CommerceML. Без сторонних модулей. Это в 5 раз быстрее, чем разработка собственного обмена на OpenCart или WordPress. Подробнее о формате — в Wikipedia. Экономия на интеграции составляет в среднем 150 000–300 000 рублей по сравнению с кастомными решениями.
• Проактивная защита — модуль security включает WAF, контроль целостности файлов, защиту от SQL-инъекций, двухфакторную аутентификацию. Для проектов с требованиями ФСТЭК — сертифицированное решение.
• Модульная архитектура — подключаем только нужные модули: iblock, catalog, sale, search. Меньше модулей — меньше запросов к БД на каждый хит.
• Регулярные патчи — вендор выпускает security-патчи, закрывая уязвимости быстрее, чем open-source проекты (среднее время исправления CVE — 2 недели). Официальная документация по модулям — dev.1c-bitrix.ru.

Что дают HL-блоки и как мы ускоряем каталог

Highload-блоки — это альтернатива расширенным свойствам инфоблоков, когда список значений может расти до тысяч записей. Типичный пример: производители, страны, цвета. Если хранить их как свойства-списки в инфоблоке, каждая фильтрация вызывает полное сканирование таблицы b_iblock_property_enum. С HL-блоками выборка идёт по индексу — время ответа фильтра снижается с 1–2 секунд до 50 мс. Мы используем HLB компонент и кастомные запросы через Bitrix\Highloadblock\DataManager. Это особенно критично для каталогов с 100 000+ товарами.

Из нашей практики — проект интернет-магазина с 500 000 товаров. Стандартный фильтр по бренду выполнялся 4 секунды. Сервер не выдерживал нагрузку в 50 одновременных запросов — страницы падали. Мы перевели справочник брендов в HL-блок, добавили тегированное кэширование на 15 минут и настроили агент для сброса кэша при изменении. После доработки время фильтрации составило 120 мс, средний LCP страницы — 1,8 секунды. Проект работает стабильно без сбоев.

Что входит в разработку сайта на 1С-Битрикс

Каждый проект включает полный комплект документации и артефактов, исключающий потерю знаний после передачи.

• Техническое задание — user stories, диаграммы инфоблоков, схемы интеграций.
• Исходный код в Git — с историей коммитов, тегами релизов, правилами ветвления.
• Административная документация — описание кастомных компонентов, инструкции по разворачиванию, перечень агентов и событий.
• Обучение сотрудников — до 3 часов вебинара: панель управления, работа с заказами, настройка цен. Записываем, чтобы можно было пересмотреть.
• Доступ к staging на время разработки — тестируете сами до деплоя на продуктив.
• Гарантийная поддержка — исправление ошибок кода в течение 30 дней после запуска. Постгарантийные абонентские пакеты с SLA (реакция 2 часа, решение 8 часов).

Наш процесс и технологии

Стек: вёрстка mobile-first, тестируем на физических устройствах (iPhone, iPad, Android). Используем BrowserStack для Safari на iOS. Производительность — LCP < 2,5 с, FID < 100 мс, CLS < 0,1. Включаем композитный сайт (composite), CDN, тегированное кэширование, WebP/AVIF, lazy loading. SEO — Schema.org через JSON-LD, автогенерация sitemap.xml модулем seo, canonical и hreflang для мультиязычных версий. robots.txt закрываем /bitrix/ от индексации. CI/CD — Git, автодеплой через GitLab CI, staging. Миграции базы — модуль sprint.migration с версионированием.

Процесс работы:

1. Аналитика — изучаем конкурентов, собираем требования, рисуем прототипы в Figma. На выходе — ТЗ с user stories.
2. Дизайн — UI/UX с дизайн-системой. Компоненты переиспользуются.
3. Разработка — пишем компоненты с кастомными шаблонами в local/templates/. Бизнес-логику выносим в модули local/modules/.
4. Тестирование — функциональное, кроссбраузерное, нагрузочное (до 1000 запросов). Критичные баги исправляем до запуска.
5. Запуск — деплой на прод, мониторинг через UptimeRobot, алерты в Telegram. Устраняем первые 48 часов.

Интеграции, мультиязычность и редизайн

• Полная локализация через языковые файлы lang/ и механизм SITE_ID. hreflang для каждой версии. Региональные версии с разными ценами и контентом — определение по IP (main.geo) или ручной выбор. Мультидоменность — единое управление несколькими доменами.

• Редизайн без потери позиций: аудит производительности (PageSpeed, WebPageTest), SEO (Screaming Frog). Новый шаблон в local/templates/ с сохранением URL-структуры. 301-редиректы только если URL меняется существенно. Обновление ядра, переход на D7 ORM, реструктуризация инфоблоков, миграция через sprint.migration с Git.

Гарантия и поддержка

Мы работаем с 1С-Битрикс 12+ лет, реализовали 500+ проектов. В штате сертифицированные разработчики. Фиксированная стоимость в договоре — без сюрпризов. Гарантийный период покрывает ошибки кода. После — абонентские пакеты с SLA (время реакции — 2 часа, решение — 8 часов). Мониторинг доступности 24/7, алерты в Telegram. Получите консультацию и предварительный расчёт: свяжитесь с нами через форму на сайте или напишите в чат — ответим в течение часа. Закажите разработку под ключ — мы спроектируем инфоблоки, интегрируем 1С и разгоним каталог. Если уже есть сайт на другой CMS — закажите аудит производительности и миграцию на Битрикс.