Offline-first для PWA — с чего начать

Сеть на стройке падает раз в час. В метро её просто нет. Делаем так, чтобы приложение жило, даже когда соединения нет.

Offline-first для PWA — с чего начать

Offline-first — это подход, когда приложение умеет работать без сети по умолчанию, а не как «опция». Особенно нужен на мобильных PWA для цеха, склада, выездных бригад.

Offline-first для PWA — с чего начать
Базовая схема offline-first: всё пишется локально, потом отправляется.

Что значит offline-first на практике

  • Все критичные данные — в локальном хранилище. Сеть нужна только для синхронизации, не для отображения
  • Действия пользователя пишутся в очередь сразу. Если есть сеть — улетают; если нет — ждут
  • UI никогда не показывает спиннер «нет соединения». Показывает значок «не синхронизировано» — действие уже сохранено локально

Стек для PWA

  • Service Worker — кеширует статику и API-ответы. Без него offline вообще не работает
  • IndexedDB — основное хранилище для структурированных данных. Не localStorage (5MB лимит и синхронный API)
  • Cache API — для статики и больших ответов. Работает в паре с Service Worker
  • Background Sync API — отложенная отправка очереди при появлении сети

С чего начать

  1. Снимите список критичных пользовательских сценариев — что должно работать без сети
  2. Спроектируйте схему данных под локальное хранилище. Ключи, индексы, версии
  3. Напишите Service Worker с базовой стратегией cache-first для статики
  4. Сделайте локальную очередь действий с retry
  5. Добавьте UI-индикаторы статуса синхронизации

Что часто забывают

  • Конфликты при синхронизации — два устройства поправили одну запись. Нужна стратегия: last-write-wins, merge или manual resolve
  • Истечение токенов авторизации в оффлайне. Нужна refresh-логика, которая отрабатывает при возвращении сети
  • Размер хранилища. Браузер выкидывает данные, если занято много — `navigator.storage.persist()` помогает
  • Время на первоначальную загрузку. Первый раз сеть нужна — иначе нечего кешировать