How a web app prepares for a lost connection
A service worker is a small JavaScript program that a browser runs separately from a web page. After the app is opened and the worker is installed, it can keep a chosen set of files—such as the app’s interface, styles, and icons—in a local cache on the device. The next time the page asks for one of those files, the worker can answer from that cache instead of waiting for the network.
This changes what “offline” means: the app is not magically reaching the internet. It is reusing material it already saved. If the needed page or data was never cached, the app may still be unable to show it.
The request-by-request decision
When a page requests a file, the browser gives the service worker a chance to handle that request. The worker’s code can choose to fetch a fresh copy online, use a cached copy, or try the network first and fall back to the cache if the connection fails. Developers choose these rules based on the kind of content: an app shell can often be reused, while rapidly changing information may need an online check.
That choice involves a tradeoff. Serving saved content makes the app load quickly and remain usable during an outage, but the saved version can become stale. Apps therefore need a way to update their cached files as new versions are released.
Offline use has limits
A service worker can also help an app save user actions—such as a draft or a request to send later—so they can be retried when the connection returns, if the app is built to support that behavior. But it cannot guarantee that every feature works without a network: live search, current account data, and other server-dependent tasks still require a connection or a prepared fallback.
The practical result is continuity, not a second internet: a well-designed app can keep its essential interface available and postpone some work until the device reconnects.
