How offline works: service workers and caching
The engine behind offline is the service worker — a script the browser runs separately from your page. It sits between your app and the network, intercepting requests. When you're offline, it serves cached files and data instead of failing.
On the first visit it caches your app's shell (the HTML, CSS, JavaScript, and icons). After that the app can open instantly without a network round trip, because it's loading from the device.
- Service worker intercepts every network request and can answer from cache
- App shell is cached on first load, so relaunches are instant
- Static assets, API responses, and images can each be cached differently
- IndexedDB stores structured data locally for the app to read and write
- A clear 'you're offline' state keeps users oriented, not confused
Caching strategies for your data
Offline isn't one setting — it's a set of choices per type of content. A pricing table can be served cache-first for speed. A live inventory count should be network-first, falling back to the last known value. User-created content should be saved locally and queued.
For actions taken offline (a form submitted, a note written, an order started), background sync holds the request and replays it once the connection returns, so nothing the user did gets lost.
- Cache-first for stable assets that rarely change
- Network-first with fallback for data that should be fresh when possible
- Stale-while-revalidate to show something instantly, then update
- Local queue plus background sync for actions taken while offline
- Cache versioning so updates roll out cleanly without stale files
What offline can and can't do
Offline-capable does not mean magic. The app can only show data it has already cached, and it can't complete an action that genuinely requires a live server response in the moment (a real-time payment authorization, for instance).
The realistic goal is graceful degradation: the app stays usable, the user keeps working, and anything that needs the server is queued and clearly marked as pending. We scope exactly which flows need to survive offline in a free consultation.
- Works with data already cached — it can't fetch what it's never seen
- Server-dependent actions get queued and marked pending, not silently dropped
- Storage limits vary by browser and device; large media needs planning
- iOS can evict cached data if storage is tight — design for that
- Best fit: field tools, forms, reading, dashboards, and note-taking
More on progressive web apps
Frequently asked questions
Does an offline web app work with zero connection at all?
Yes, for anything it has already cached — the app opens, shows saved data, and can accept input with no signal. What it can't do is retrieve brand-new data it never downloaded or complete a live server transaction until the connection returns.
What happens to data a user enters while offline?
It's saved locally right away, and any action that needs the server is queued. When the connection comes back, background sync replays those requests automatically. We also show a clear pending state so users know what's synced and what isn't.
Is offline support worth it for my app?
It depends on where and how your users work. Field teams, warehouses, transit, and spotty-signal environments benefit enormously; a desktop-only internal tool may not need it. We'll help you decide which flows justify the extra engineering in a free consultation.