Offline web refers to the techniques that allow a website or web application to load, display content and accept user actions without a network connection, then synchronize when connectivity returns. On the mobile web it addresses a basic reality of phones: connections drop in elevators, trains and rural areas, and slow or unstable networks are common even in cities.
The core building block is the service worker, a script that sits between the page and the network and decides how each request is answered. Combined with the Cache Storage API and IndexedDB, it lets a web app behave much like an installed native app, which is why offline support is a central feature of progressive web apps.
How offline web works with service workers
Offline web works by intercepting network requests in a service worker and answering them from local storage when the network is unavailable or slow. The service worker runs in the background, separately from the page, and can respond to every request made within its scope, typically the site’s origin or a path under it.
A service worker has a defined lifecycle. During the install event it usually pre-caches the app shell, the minimal HTML, CSS, JavaScript and icons needed to render the interface. During activation it removes outdated caches. Afterward, its fetch handler decides for each request whether to use the cache, the network or both.
Service workers run only in secure contexts over HTTPS, with localhost allowed for development, because their ability to intercept traffic would otherwise be dangerous.
| Technology | Role | Typical content |
|---|---|---|
| Service worker | Intercepts and answers requests | Routing logic and caching strategy |
| Cache Storage API | Stores request and response pairs | HTML, CSS, scripts, images, fonts |
| IndexedDB | Stores structured data locally | Records, drafts, queued changes |
| Background Sync | Retries queued work when online | Form submissions and uploads |
| Web app manifest | Describes the installable app | Name, icons, start URL, display mode |
Caching strategies for the offline web
The behavior of an offline-capable site depends mainly on its caching strategy, chosen separately for each type of resource. A single strategy for everything usually produces either stale content or poor offline coverage.
| Strategy | How it answers | Best suited for |
|---|---|---|
| Cache first | Cache, falling back to network | Versioned scripts, styles, fonts, icons |
| Network first | Network, falling back to cache | News pages, account data, frequently changing HTML |
| Stale while revalidate | Cache immediately, update in background | Avatars, non-critical API responses |
| Network only | Always the network | Payments, logins, real-time actions |
| Cache only | Only the pre-cached copy | App shell files installed with the worker |
Network-first requests should use a short timeout of a few seconds before falling back to the cache. Without one, a weak but technically available connection, often called lie-fi, can leave the user waiting far longer than a true offline state would.
Offline web compared with related mobile web concepts
Offline web support is closely tied to PWA installation, Add to home screen and mobile web push, but each concept solves a different problem. Offline capability makes the app work without a network; installation and home screen shortcuts make it easy to open; push brings the user back.
| Capability | Main purpose | Depends on a service worker |
|---|---|---|
| Offline web | Working without a connection | Yes |
| PWA installation | Standalone app window and launcher icon | Required by some browsers, not all |
| Add to home screen | Shortcut from the home screen | No for a basic shortcut |
| Mobile web push | Notifications when the site is closed | Yes |
| HTTP caching | Reusing responses via cache headers | No |
The older Application Cache manifest was the first offline web mechanism but proved inflexible and error-prone. It has been removed from modern browsers and fully replaced by service workers.
Designing an offline-first mobile experience
Good offline web design treats the network as an enhancement rather than a requirement, an approach known as offline-first. The interface reads and writes local data first and synchronizes with the server whenever possible.
- Show a clear offline indicator and explain which actions are still available.
- Provide a custom offline page instead of the browser’s default error screen.
- Queue user actions in IndexedDB and send them when connectivity returns.
- Resolve sync conflicts deliberately, for example by timestamp or by asking the user.
- Version caches and delete old ones during service worker activation.
Not every site needs full offline functionality. A content site may only need recently viewed pages and an offline page, while a field-service or note-taking app needs complete local data and reliable synchronization.
Limitations and pitfalls of the offline web
The main limitations of offline web apps come from browser storage policies and platform differences. Browsers allocate storage per origin, often as a share of free disk space, and can evict cached data under storage pressure unless the site has been granted persistent storage.
| Problem | Cause | Fix |
|---|---|---|
| Users see an old version after release | Service worker serves stale cache | Version assets and prompt to reload |
| Offline data disappears | Browser evicted site storage | Request persistent storage, sync early |
| Background sync never runs on iOS | API not supported in that browser | Retry sync when the app is reopened |
| Huge storage use | Unbounded runtime caching | Limit entries and set expiration |
Safari has historically cleared script-writable storage for sites that a user has not visited for several weeks, unless the site is installed to the home screen. Offline-capable apps on iOS should therefore treat local data as a cache that may vanish, not as permanent storage.
In plain words
Offline web means a website keeps working when the internet disappears. The site saves the important parts on the phone while you are online. Later, without a signal, it shows those saved parts instead of an error page.
It is like downloading a map before a trip into the mountains. You can still find your way without coverage. Anything you do offline, such as writing a note, is kept and sent automatically when the connection comes back.
A real-world example
A public transport company runs a mobile web app for timetables and digital tickets. Many riders lose their connection in underground stations, which used to leave them unable to show a ticket to an inspector.
The development team adds a service worker that pre-caches the app shell, stores purchased tickets in IndexedDB and uses a network-first strategy with a three-second timeout for timetables. When a rider opens the app underground, the interface loads instantly from the cache, the valid ticket is displayed offline, and the last downloaded timetable appears with a note showing when it was updated.
Purchases still require a connection, so the buy button is disabled offline with a short explanation. After launch, complaints about missing tickets in the underground drop sharply.