Service Worker

Ordinary page JavaScript only runs while the tab is open. Once the user closes the tab or loses connectivity, the app can no longer intercept requests, prepare data ahead of time, or continue background work. In that structure, offline experience and background behavior remain severely limited. Simple storage is not enough either. Even if files are stored somewhere in the browser, something still needs to decide which requests should prefer cached data, when the network should be retried, and how failed requests should be replayed later. That requires an execution model that sits outside the page itself.

As expectations grew for the web to behave more like a native app, people began to want browser experiences that could work offline and receive notifications in the background. AppCache was an early attempt, but cache invalidation and version handling were so brittle that it proved hard to trust in production. Service Worker emerged from that failure as an event-driven script rather than a static cache manifest. It lets developers place policy logic between the page and the network on top of a browser-managed background execution model.

A Service Worker begins when the page calls `register()` for a script. The browser installs and activates that script, and for pages inside its scope it can deliver fetch events to the Service Worker before the network is touched. When the Service Worker receives such an event, it decides whether to answer from cache, go to the network first, or combine the two. Static assets can be precached during installation, while API responses can use different runtime strategies depending on the request. The critical point is that the Service Worker has a lifecycle separate from any individual page. It has no DOM, but the browser can wake it for events such as push notifications and background sync even when no page is currently open.

Service Worker and Web Worker both execute off the main thread, but their purpose and location differ. A Web Worker is a tool for letting the currently open page offload heavy computation to another thread. A Service Worker behaves more like a browser-side proxy that controls requests and cache between the page and the network. So if the problem is large JSON parsing or image processing, Web Worker is the right fit. If the problem is offline caching, push notifications, or request retry policy, Service Worker is the right fit. Both lack direct DOM access, but they solve very different classes of problems.

Service Worker is the practical core of a PWA. By precaching an app shell, the product can keep showing the basic UI when connectivity disappears, and on repeat visits it can serve static assets immediately while refreshing content in the background. In production, version management is the hardest part. If stale caches linger too long, new deployments do not show up. If caches are invalidated too aggressively, the offline experience collapses. Changing cache names and activation logic without a plan can easily leave users with mismatched asset versions. Service Worker is also not a general-purpose background runtime for everything. Long-running computation and direct UI manipulation are out of scope, and the browser only lets it run within specific events and lifetimes. The important design question is what belongs in cache policy and what should remain ordinary application logic.