The fix is live – but not for everyone: auditing service worker updates

A bug is fixed, the deployment is green, and everything looks correct in your own browser. Yet some users keep reporting the same problem hours or even days later. Then someone clears site data and the issue disappears.

That is not mysterious browser behavior. On a site with a service worker, there is another persistent delivery layer alongside HTTP caches and CDNs. It can intercept requests and return responses from the Cache Storage API. If its update lifecycle and caching rules are not deliberately designed, different users can genuinely be running different frontend versions.

Deployment and delivery are separate events

Putting a new bundle on the server does not mean an installed service worker is replaced immediately.

The Service Workers specification models installing, waiting, and active workers within a registration. When the browser finds a new worker version, it can install it in the background and then leave it waiting. By default, activation waits until clients using the previous worker are gone. Long-lived tabs can therefore keep the previous version around much longer than a release engineer expects.

This is intentional. The lifecycle is designed to avoid two worker versions casually controlling the same application at once. For products whose users keep tabs open all day, however, that safety mechanism needs to be part of the release design.

Separate the three caching layers

Troubleshooting becomes much easier when three layers are treated separately:

1. HTTP and CDN caching: governed by response headers such as Cache-Control, revalidation, and any intermediary cache.
2. Service worker updating: the browser checks the worker script for changes and manages its installation and activation state. The registration itself persists until explicitly unregistered.
3. Cache Storage: the service worker can create named caches containing HTML, JavaScript, CSS, images, or API responses. Those entries do not disappear simply because a new deployment happened.

Purging a CDN therefore does not necessarily fix stale data already held by a user's service worker cache.

Seven questions for a useful audit

1. Is a service worker still registered?

This sounds obvious, but it is a common handover problem. A previous PWA implementation, an old framework plugin, or an abandoned offline feature can leave a registration behind. The W3C specification explicitly treats service worker registrations as persistent until they are unregistered.

Do not inspect only the current repository. Inspect the registrations that browsers actually have and the scopes they control.

2. Which worker is active and which one is waiting?

A release process should make it possible to observe whether a registration has an installing, waiting, or active worker. A waiting worker is not merely an implementation detail: it can directly explain why the new deployment exists on the server while an existing tab continues to behave like the old release.

For SaaS products, reproduce this with multiple tabs rather than testing only a fresh page load.

3. How does an update take control?

skipWaiting() can ask a waiting worker to activate immediately. clients.claim() can let the newly active worker take control of existing clients.

Both are useful, but immediate takeover is not automatically the best policy. A document may still be running JavaScript from the old release while the new worker begins serving different assets or applying different API caching logic. Depending on the application, that mixed-version window can create subtle failures. For products with forms or unsaved state, a controlled “New version available” prompt followed by a reload can be safer than an invisible switch.

4. Are caches and assets versioned?

A new worker should be able to identify old cache generations and remove them deliberately. MDN recommends cleaning obsolete caches during the activate event.

Pay particular attention to cached HTML that references build artifacts. If an old HTML document points to JavaScript chunks that a deployment has replaced or removed, users can see intermittent chunk-loading errors even though the current release works perfectly in a clean browser.

5. Which strategy is used for HTML, assets, and APIs?

“Cache first” has very different consequences for immutable hashed assets than it does for HTML or API responses. Chrome's service worker guidance, for example, describes network first as useful when the newest online response should be preferred while a cached response remains available as an offline fallback.

An audit should therefore answer more than whether caching exists. It should document what is cached, for how long, and with which fallback strategy.

6. Can the worker script itself update reliably?

Service worker registrations expose updateViaCache, which controls when the HTTP cache may be consulted while updating the worker and imported scripts. Its default mode is imports.

ServiceWorkerRegistration.update() can also trigger an update check. MDN documents that the worker script is fetched again and a new worker is installed when the script is not byte-for-byte identical to the current one.

This does not replace sound cache headers. It does show that the worker update path itself deserves explicit testing.

7. Has anyone tested a real multi-tab release?

The most useful release test is rarely “reload once and see whether it works.”

A stronger test looks like this: open the old release in two tabs, deploy the new release, navigate one tab, observe the update state, leave the second tab open, then test activation and reload behavior. Finally inspect Cache Storage, the active worker, and the asset versions actually loaded by the page.

That exposes lifecycle bugs a fresh incognito window will never reveal.

Common red flags

Signals of service worker update drift include:

• Support regularly recommends a hard reload or clearing site data.
• Bugs affect long-standing users but cannot be reproduced in fresh incognito sessions.
• A new worker remains in waiting indefinitely.
• Old cache names accumulate across many releases.
• HTML is cached aggressively while referenced JavaScript chunks are replaced or deleted during deployments.
• skipWaiting() and clients.claim() were copied from boilerplate without testing version compatibility.
• PWA functionality was removed, but existing registrations were never migrated or unregistered.
• There is no visible release identifier that support and engineering can use to determine what version a user is actually running.

A more operationally robust rollout pattern

For many web applications, a conservative model is easier to operate: cache hashed static assets for a long time; give HTML and critical API data a deliberately fresh strategy; version cache names; clean old generations during activation; detect waiting workers; and provide a controlled reload path when an important update is ready.

If you activate immediately, test whether an old document remains compatible with the new worker. If you require a reload, account for unsaved user state first.

The goal is not one universal caching strategy. The goal is behavior that is defined, testable, and observable in production.

What Website-Pflichtencheck would inspect

A technical Website-Pflichtencheck goes beyond visible frontend errors or a Lighthouse score. For sites using service workers, we can inspect registration and scope, active and waiting workers, Cache Storage contents, cache versioning and cleanup, strategies for HTML and static assets, multi-tab update behavior, and whether a previous release can continue to be served after a deployment.

If users report problems your team cannot reproduce internally, this layer is worth checking. A repeatable update test is usually more useful than another round of “please clear your cache.”

Sources

• W3C: Service Workers — https://www.w3.org/TR/service-workers/
• MDN: Using Service Workers — https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers
• MDN: ServiceWorkerRegistration.update() — https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/update
• MDN: ServiceWorkerRegistration.updateViaCache — https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/updateViaCache
• Chrome for Developers: Handling service worker updates with immediacy — https://developer.chrome.com/docs/workbox/handling-service-worker-updates