Розробка 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 секунди, а вартість підтримки значно скоротилася — за рахунок усунення надлишкових запитів та агентів.

Наш підхід: проектуємо інфоблоки до першого рядка коду. Окремі інфоблоки під сутності (товари, категорії, бренди), властивості-довідники через HL-блоки, торгові пропозиції для SKU. Це закладає продуктивність на роки вперед. Якщо хочете отримати попередній аудит вашої схеми інфоблоків — зв'яжіться з нами, розберемо типові помилки та надамо рекомендації.

Чому 1С-Бітрікс вигідніший за альтернативи?

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

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

Що дають HL-блоки і як ми прискорюємо каталог

Highload-блоки — це альтернатива розширеним властивостям інфоблоків, коли список значень може зростати до тисяч записів. Типовий приклад: виробники, країни, кольори. Якщо зберігати їх як властивості-списки в інфоблоці, кожна фільтрація викликає повне сканування таблиці b_iblock_property_enum. З HL-блоками вибірка йде по індексу — час відповіді фільтра знижується з 1–2 секунд до 50 мс. Продуктивність HL-блоків у 8 разів вища за властивості-списки інфоблоків. Ми використовуємо 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 — замовте аудит продуктивності та міграцію на Бітрікс.