Разработка Progressive Web App (PWA) для мобильных устройств

Часто клиенты обращаются к нам с запросом на мобильное присутствие без публикации в 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 до сих пор не поддерживается — это нужно учитывать при проектировании офлайн-сценариев. Например, альтернативой может быть ручная отправка данных при восстановлении соединения.

Какие ограничения существуют на 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%. Однако для приложений с глубокой интеграцией в систему (камера, Bluetooth, NFC) нативное приложение остаётся безальтернативным.

Как строим PWA: пошаговая инструкция

1. Аудит — проверка HTTPS, Core Web Vitals, текущего Service Worker (если есть).
2. Конфигурация — используем Workbox 7.x через vite-plugin-pwa. Режим generateSW автоматически создаёт precache-манифест из бандла.
3. Манифест — name, short_name, start_url с параметром ?source=pwa, display: standalone, theme_color, background_color, иконки 192×192 и 512×512, плюс maskable вариант для Android.
4. Service Worker — настраиваем стратегии: StaleWhileRevalidate для статики, NetworkFirst для API, CacheFirst для неизменяемых ресурсов.
5. Push-уведомления — регистрируем VAPID-ключи, подписка через PushManager.subscribe().
6. Тестирование — отладка в 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 и нативных приложений

Что входит в работу

На этапе аудита проверяем производительность (Core Web Vitals), HTTPS-конфигурацию, текущий Service Worker если есть. Затем разрабатываем Service Worker со стратегиями кэширования под конкретные маршруты, создаём манифест, иконки всех размеров и splash screens для iOS. Если нужны push-уведомления — настраиваем Web Push и тестируем офлайн-сценарии в Chrome DevTools и на реальных устройствах. В среднем добавление PWA к готовому сайту занимает 3–7 дней, а полная разработка с нуля — 2–4 недели.

Итог проверяем через 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% при корректной реализации.