Часто клієнти звертаються до нас із запитом на мобільну присутність без публікації в App Store і Google Play. Або у них уже є веб-сайт на React/Vue/Angular, і потрібно додати офлайн-режим, push-сповіщення та іконку на домашньому екрані — без переписування всього з нуля. Реальна PWA — це Service Worker з правильною стратегією кешування, Web App Manifest з коректними параметрами для кожної платформи, і HTTPS без винятків. Пропустити будь-який із цих трьох компонентів — отримати додаток, який не встановлюється або працює некоректно в офлайні. Замовте оцінку вашого проекту за 1 день — зв'яжіться з нами.
Де зазвичай ламається PWA?
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 досі не підтримується — це потрібно враховувати при проектуванні офлайн-сценаріїв. Наприклад, альтернативою може бути ручне надсилання даних при відновленні з'єднання.
| Стратегія кешування | Застосування | Застарівання даних | Підходить для |
|---|---|---|---|
| CacheFirst | Статичні ресурси | Ні | Шрифти, іконки, JS-бандли з хешами |
| StaleWhileRevalidate | Швидке відображення | Так | HTML-сторінки, зображення |
| NetworkFirst | Завжди свіжі | Так | API-запити, дані користувача |
| NetworkOnly | Без кешу | Ні | Форми, авторизація |
Обмеження на iOS
Apple планомірно обмежує PWA: до версії 16.4 push-сповіщення в PWA не працювали взагалі. Зараз працюють, але тільки якщо додаток додано на головний екран через Safari — не з Chrome, не з Firefox. Квота сховища IndexedDB на iOS — 50 МБ за замовчуванням, проти гігабайтів на Android. Ресурси, що кешуються, потрібно рахувати заздалегідь. Якщо плануєте push-сповіщення, обов'язково використовуйте VAPID-ключі та враховуйте, що на iOS потрібне встановлення через Safari.
Чому PWA краще за нативне для деяких сценаріїв?
PWA розробляється в 3-5 разів швидше за нативний додаток і коштує в 2-3 рази дешевше. Оновлення відбуваються автоматично, без перевірок магазинів. Для інформаційних порталів, новинних сайтів і корпоративних сервісів PWA часто виявляється ефективнішим: займає менше місця на пристрої, не вимагає встановлення з магазину, а конверсія у встановлення (через beforeinstallprompt) може досягати 60%. За даними Google, PWA збільшують конверсію на 36% при коректній реалізації. Джерело: Google Developers Крім того, PWA оновлюється в 10 разів швидше, ніж нативний додаток, і має на 20% менше відмов. Однак для додатків із глибокою інтеграцією в систему (камера, Bluetooth, NFC) нативний додаток залишається безальтернативним.
Як будуємо PWA: покрокова інструкція
- Аудит — перевірка HTTPS, Core Web Vitals, поточного Service Worker (якщо є).
- Конфігурація — використовуємо Workbox 7.x через
vite-plugin-pwa. РежимgenerateSWавтоматично створює precache-маніфест із бандла. - Маніфест —
name,short_name,start_urlз параметром?source=pwa,display: standalone,theme_color,background_color, іконки 192×192 і 512×512, плюсmaskableваріант для Android. - Service Worker — налаштовуємо стратегії: StaleWhileRevalidate для статики, NetworkFirst для API, CacheFirst для незмінних ресурсів.
- Push-сповіщення — реєструємо VAPID-ключі, підписка через
PushManager.subscribe(). - Тестування — налагодження в Lighthouse, Chrome DevTools (Application → Service Workers → Offline) і на реальних пристроях.
Як досягти високої конверсії встановлення?
Chrome показує банер «Додати на головний екран» при виконанні критеріїв: HTTPS, валідний маніфест, зареєстрований SW з fetch-обробником. Lighthouse перевіряє всі умови. Для самостійного контролю використовуємо beforeinstallprompt event: перехоплюємо його через event.preventDefault(), відкладаємо і показуємо власний UI в потрібний момент, потім викликаємо prompt(). Це дає контроль над тим, коли і кому пропонувати встановлення. На iOS встановлення тільки вручну через Share → «На екран «Додому»» — жодних автоматичних промптів.
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) }); Порівняння PWA та нативних додатків
| Критерій | PWA | Нативний додаток |
|---|---|---|
| Розробка | 2–4 тижні | 2–6 місяців |
| Вартість | від 20 000 грн | від 60 000 грн |
| Оновлення | автоматичні | через магазини |
| Офлайн | обмежена | повна |
| Push-сповіщення | так (з обмеженнями iOS) | так |
| Встановлення | без магазинів | App Store / Google Play |
Що входить у роботу
На етапі аудиту перевіряємо продуктивність (Core Web Vitals), HTTPS-конфігурацію, поточний Service Worker якщо є. Потім розробляємо Service Worker зі стратегіями кешування під конкретні маршрути, створюємо маніфест, іконки всіх розмірів і splash screens для iOS. Якщо потрібні push-сповіщення — налаштовуємо Web Push і тестуємо офлайн-сценарії в Chrome DevTools та на реальних пристроях. У середньому додавання PWA до готового сайту займає 3–7 днів, а повна розробка з нуля — 2–4 тижні. Наша компанія виконала понад 30 PWA-проектів з гарантією сумісності та сертифікованими розробниками.
Підсумок перевіряємо через Lighthouse PWA audit — усі пункти мають бути зеленими. Ми займаємося PWA понад 5 років, і кожен проект проходить таке тестування. Наш досвід включає інтеграцію з Firebase і Supabase для push-сповіщень і фонової синхронізації.
Типові помилки при впровадженні PWA:
- Ігнорування інвалідації кеша — користувачі бачать застарілий контент.
- Відсутність
maskableіконки — на Android іконка з білим фоном. - Push-сповіщення без перевірки підтримки на iOS.
- Використання лише CacheFirst для API — втрата актуальності даних.
Строки
Додавання PWA до готового веб-додатка: 3–7 днів. Розробка PWA з нуля з офлайн-логікою та push-сповіщеннями: 2–4 тижні. Вартість розраховується після аналізу поточного стеку та вимог до офлайн-функціональності. Оцінимо ваш проект за 1 день — зв'яжіться з нами для консультації.
За даними Google, PWA збільшують конверсію на 36% при коректній реалізації.