Коли додаток не відкривається без інтернету, користувач іде до конкурентів
PWA перетворює сайт на надійний додаток, який працює навіть в офлайні, надсилає push-повідомлення та встановлюється на головний екран. Розробка PWA додатків — це впровадження Service Worker, налаштування кеш-стратегій та інтеграція Web Push. На відміну від нативних додатків, вам не потрібні дві команди під iOS та Android — один код працює у всіх сучасних браузерах. Замовте аудит вашого проекту на PWA-сумісність — ми безкоштовно оцінимо потенціал та терміни.
Як Service Worker керує мережевими запитами?
Service Worker — це JavaScript-проксі між браузером та мережею. Працює в окремому потоці, перехоплює запити та вирішує, звідки їх віддавати: з кешу, з мережі або комбінацією. Розглянемо три базові стратегії на реальних сценаріях.
| Стратегія кешування | Використання | Поведінка при офлайн |
|---|---|---|
| Cache First | статика (CSS/JS з content hash) | віддається з кешу, миттєво |
| Network First | API, замовлення, новини | спочатку мережа, при помилці — кеш |
| Stale While Revalidate | контент соцмереж, стрічка сторінок | одразу кеш, потім оновлення |
Cache First застосовується для активів з хешем в імені — файл ніколи не зміниться, можна кешувати назавжди. Stale While Revalidate оптимальна для контенту, де допустима невелика затримка актуалізації. Workbox від Google автоматизує версіонування кешу та інвалідацію — без нього коректний Service Worker вимагатиме 300+ рядків коду з нетривіальними edge cases. Vite + vite-plugin-pwa генерує Service Worker з конфігу, включаючи precaching статики.
import { VitePWA } from 'vite-plugin-pwa';
export default {
plugins: [
VitePWA({
registerType: 'autoUpdate',
includeAssets: ['favicon.ico'],
manifest: { /* name, icons, start_url, display */ },
workbox: {
globPatterns: ['**/*.{js,css,html,ico,png,svg}'],
runtimeCaching: [
{ urlPattern: /^https?:\/\/api\./,
handler: 'NetworkFirst',
options: { cacheName: 'api-cache' }
}
]
}
})
]
};
Як офлайн-режим реалізується на практиці?
«Працює офлайн» для різних продуктів означає різне. Ось три типові сценарії.
- Офлайн-читання (новинні сайти, документація): Service Worker кешує сторінки при першому візиті, стратегія Stale While Revalidate + Background Sync для синхронізації після відновлення з'єднання.
- Офлайн-редагування (нотатки, завдання): IndexedDB зберігає локальні дані, Background Sync API ставить операції в чергу — браузер синхронізує сам, навіть якщо вкладка закрита. Обмеження: Background Sync підтримується тільки в Chromium.
- Офлайн-форма: користувач натиснув «Надіслати» без інтернету — дані не втрачаються, а ставляться в чергу та надсилаються автоматично. Для медичних та страхових форм це критично.
Проблема, про яку часто забувають: конфлікти при синхронізації. Якщо користувач А редагував запис офлайн, а користувач Б змінив його онлайн — потрібна стратегія вирішення (last-write-wins, three-way merge або показ конфлікту користувачеві). Ми опрацьовуємо ці сценарії на етапі проектування.
Як працюють Web Push-повідомлення?
Web Push доставляє повідомлення через браузер + Push Service (FCM для Chrome/Edge, APNs для Safari). Користувач надає дозвіл → браузер підписується на Push Service → ви отримуєте endpoint та ключі → надсилаєте повідомлення → Push Service доставляє в браузер. Реалізація через бібліотеку web-push (Node.js) або аналог для вашого бекенду. VAPID-ключі генеруються один раз, підписка зберігається в базі даних.
На поточний момент iOS (починаючи з версії 16.4) підтримує Web Push тільки для встановлених PWA, Chrome/Firefox/Edge — повна підтримка без встановлення. Частота та релевантність повідомлень безпосередньо впливають на відтік підписників — A/B тестування часу надсилання та формулювань стандартна практика.
Чому варто обрати PWA замість нативних додатків?
Економія на розробці під дві платформи — до 60% бюджету. Один код, єдина бізнес-логіка, автоматичне оновлення без магазинів. Ми виконали понад 30 PWA-проектів для e-commerce, фінтеху та корпоративних систем — гарантуємо сумісність з останніми версіями браузерів та відмінні показники Core Web Vitals (LCP, CLS, INP). PWA збільшує конверсію в середньому на 36% (дані Google). Сертифіковані спеціалісти з досвідом 7+ років у веб-розробці.
Що входить у розробку PWA під ключ?
| Етап | Результат | Термін |
|---|---|---|
| Аудит поточного додатку | Звіт PWA‑score, рекомендації | 1–2 дні |
| Проектування офлайн‑сценаріїв | Документація, прототип | 2–3 дні |
| Розробка Service Worker + маніфест | Код, автоматичне тестування | 5–10 днів |
| Інтеграція Web Push (опціонально) | Бекенд‑ендпоінт, підписка | 3–5 днів |
| Тестування на реальних пристроях | Звіт, правки | 3–5 днів |
| Деплой та документація | Доступи, інструкція, гарантія 1 місяць | 1–2 дні |
App Shell архітектура та precaching критичних ресурсів при першому встановленні дають миттєве завантаження оболонки додатку навіть при повільному з'єднанні.
Процес роботи та терміни
- Аудит поточного додатку (Lighthouse PWA score, аналіз сценаріїв).
- Визначення цінних офлайн-сценаріїв.
- Налаштування Service Worker через Workbox та реалізація маніфесту.
- Інтеграція Web Push (якщо потрібно).
- Тестування на реальних пристроях — Chrome DevTools, Safari Web Inspector.
- Деплой, документація, навчання команди.
Орієнтовні терміни: базова PWA (маніфест + Service Worker + кеш статики) — 1–2 тижні поверх готового додатку; Web Push — 1–2 тижні; офлайн-редагування з IndexedDB та Background Sync — 3–6 тижнів залежно від складності даних.
Вартість розраховується індивідуально після аудиту. PWA-проект зазвичай обходиться в 2–3 рази дешевше нативного додатку під обидві платформи. Додаткову економію дає відсутність витрат на публікацію в App Store та Google Play. Зв'яжіться з нами для консультації — ми безкоштовно оцінимо ваш проект та запропонуємо оптимальну стратегію впровадження.
Посилання для поглибленого вивчення
- MDN Web Docs: Service Worker API
- W3C Push API Specification
- Wikipedia: Progressive Web Application
- Wikipedia: Service Worker