Розробка Progressive Web App (PWA) для мобільних пристроїв
Клієнт хоче мобільне присутність без публікації в App Store та Google Play. Або у них вже є веб-сайт на React/Vue/Angular, та потрібно додати офлайн-режим, push-повідомлення та іконку на домашньому екрані — без переписування всього з нуля. PWA закриває цей запит, але «просто додати manifest.json» — це не PWA.
Реальна PWA — Service Worker з правильною стратегією кешування, Web App Manifest з коректними параметрами для кожної платформи, та HTTPS без винятків. Пропустити будь-яку з цих трьох компонентів — отримати застосунок, який не встановлюється або працює некоректно в офлайні.
Де зазвичай ломається
Service Worker та стратегії кешування. Найчастіша помилка — кешувати все підряд з CacheFirst без інвалідації. Користувач відкриває оновлене застосунку, а бачить старої версії, тому що sw.js видає ресурси з застарілого кешу. Workbox вирішує це через StaleWhileRevalidate для статики та NetworkFirst для API-запитів, але потрібно чітко розділити, що кешувати агресивно (шрифти, іконки, JS-бандли з хешами), а що завжди запрошувати свіже (дані користувача, інвентар, контент).
Окрема історія — фонова синхронізація через Background Sync API. Користувач відправив форму в офлайні, Service Worker перехопив запит та поклав у SyncManager. Коли зв'язок відновилася — запит пішов. Виглядає просто, але registration.sync.register('sync-orders') працює тільки в Chrome/Android. На iOS Safari Background Sync до сих пір не підтримується — це потрібно враховувати при проектуванні офлайн-сценаріїв.
iOS Safari та його обмеження. Apple планомірно ограничує PWA: до iOS 16.4 push-повідомлення в PWA не працювали взагалі. Тепер працюють, але тільки якщо застосунок додано на домашній екран через Safari — не з Chrome, не з Firefox. Квота сховища IndexedDB на iOS — 50 МБ за замовчуванням, проти гігабайтів на Android. Кешовані ресурси потрібно рахувати заздалегідь.
Як будуємо PWA
Основа — Workbox 7.x, вбудований у Vite через vite-plugin-pwa. Конфігурація generateSW закриває 80% кейсів: плагін автоматично створює precache-маніфест із бандла та реєструє Service Worker. Для складних сценаріїв — режим injectManifest з ручним sw.js.
Маніфест для коректної встановлення на обох платформах вимагає мінімум: name, short_name, start_url з параметром ?source=pwa, display: standalone, theme_color, background_color, та набір іконок — 192×192 та 512×512 у PNG, плюс варіант maskable для Android Adaptive Icons. Без maskable іконка на Android показується з білим фоном у колі — виглядає непрофесійно.
Push-повідомлення через Web Push Protocol: VAPID-ключі генеруються один раз, публічний ключ передається клієнту при підписці через PushManager.subscribe(). На сервері — бібліотека web-push для Node.js або аналог. Subscription об'єкт з endpoint, p256dh та auth зберігається в базі — саме він потрібен для відправлення.
// Реєстрація підписки
const subscription = await registration.pushManager.subscribe({
userVisibleOnly: true,
applicationServerKey: urlBase64ToUint8Array(PUBLIC_VAPID_KEY)
});
Installability. Chrome показує баннер «Додати на головний екран» при виконанні критеріїв: HTTPS, валідний маніфест, зареєстрований SW з fetch-обробником. Lighthouse перевіряє всі умови. На iOS встановлення тільки вручну через Share → «На екран «Домой»» — ніяких автоматичних промптів.
Для вимірювання конверсії встановлень використовуємо подію beforeinstallprompt: перехопимо її, відкладаємо через event.preventDefault(), показуємо власний UI у потрібний момент, потім викликаємо prompt(). Це дає контроль над тим, коли та кому пропонувати встановлення.
Що входить у роботу
Аудит існуючого фронтенду — продуктивність (Core Web Vitals), HTTPS-конфігурація, поточний Service Worker якщо є. Розробка SW зі стратегіями кешування під конкретні маршрути. Маніфест, іконки всіх розмірів, splash screens для iOS. Push-повідомлення якщо потрібні. Тестування офлайн-сценаріїв у Chrome DevTools (Application → Service Workers → Offline) та на реальних пристроях.
Результат перевіряємо через Lighthouse PWA audit — всі пункти повинні бути зеленими.
Терміни
Додавання PWA до готового веб-застосунку: 3–7 днів. Розробка PWA з нуля з офлайн-логікою та push-повідомленнями: 2–4 тижні. Вартість розраховується після аналізу поточного стеку та вимог до офлайн-функціональності.