A service worker is a JavaScript file that the browser runs independently of any open web page. It has no access to the visible page, but it sits in a powerful position: between the application and the network. Every request a page makes within its scope passes through it. It can let the request through unchanged, answer it from a cache, redirect it or generate its own response. It also receives push messages, even when the application is not open. Without service workers, Progressive Web Apps as we know them would not exist.
Where the service worker sits
Think of a service worker as a programmable proxy inside the browser. A page requests a stylesheet, an image or data from an API; the event reaches the service worker first, which decides — according to rules the developers define — where the answer comes from. Because it has so much control, browsers require an encrypted HTTPS connection; the only exception is local development. A service worker also applies only to a specific path range of the site, its scope.
The lifecycle: register, install, activate
The page registers the service worker on the first visit. The browser downloads the script and fires the install event — the typical moment to pre-cache the application's essential files. Then comes activate, where old caches are cleaned up. Only after that does the service worker take control of requests, by default from the next page load.
Important in production: if the script changes by even a single byte, the browser installs the new version but only activates it once no page using the old version remains open. That prevents two versions from answering requests at the same time, but in practice it means users sometimes see an outdated application for longer than expected. The new version can be activated immediately on purpose, but this must suit the application so that an old page does not suddenly meet new files.
Caching strategies compared
The central design decision is how the service worker uses the cache. Cache first serves a stored response immediately and only asks the network if nothing is stored — ideal for immutable files such as versioned scripts and fonts. Network first asks the server and falls back to the cache only without a connection — suitable for content that must be current. Stale-while-revalidate serves the stored version at once and refreshes it in the background for next time, a good compromise where a short delay in freshness is acceptable.
In a well-built application these strategies are not applied wholesale but per type of request. Static files, page shells, data APIs and images each get their own rules.
Push messages and background work
Because the service worker runs independently of the page, it can receive push messages and display them as notifications. This has long been common on Android and desktop browsers; on iOS, installed web apps can receive push since iOS 16.4. User consent is mandatory, both technically through the browser and under data protection law. More advanced background features, such as resending data once a connection returns, are not available in every browser, so a robust application checks on next launch whether data is still waiting to be sent.
Service workers in modern web frameworks
In projects using Next.js or similar frameworks, the service worker is rarely written by hand. Build tools generate the list of files to pre-cache and add version identifiers. That removes much of the error potential, but it does not replace the decision about which content should be available offline at all. Server-rendered pages are particularly delicate: cached too aggressively, a user sees content that is no longer valid or a page that does not match the currently loaded application. A proven approach is to cache static files permanently, load pages from the network, and show a dedicated offline page explaining what can be done without a connection.
Typical production mistakes
The most common mistake is a service worker that caches too much. Responses containing personal data or depending on authentication do not belong unchecked in a shared cache. Missing versioning is just as problematic: if caches are not named and cleaned up on activation, old files accumulate and users see a mix of old and new application.
A second mistake concerns expectations of durability. Browsers may remove stored data under storage pressure, and Safari clears storage for sites the user has not interacted with for a while unless the site is installed as a web app. A cache is therefore an accelerator and a bridge across dead zones, not a reliable data store.
Inspecting and debugging
The developer tools of mainstream browsers show which service worker is registered, its state and what sits in the caches. They let you simulate going offline, unregister old versions and clear storage. For quality assurance a fixed test routine pays off: first visit, second visit offline, release of a new version, revisit with an old page still open. Most issues users later report already show up in this simple run.
Service workers and data protection
A service worker can store content on the device, which is relevant under data protection law. If personal data is cached, it belongs in the data protection concept: which data, for how long, and how it is removed on logout. In sensitive applications, for example in healthcare, locally stored data is additionally encrypted and deleted after synchronisation.
How we use service workers
At Innopulse every PWA we build has a service worker — but never as a default configuration copied from a template. We define the strategy per request type, version caches consistently and explicitly test the update case, because in practice it causes the most problems. If you are planning an offline-capable web app, these decisions belong in the concept, not in the last week of development.