Understand why customers see different versions
A service worker sits between a controlled web page and selected network requests. Depending on the app design, it can serve cached pages or assets and make parts of an experience work with weak connectivity. That also means a deployment does not instantly replace what every open tab uses. Browser documentation describes an updated worker installing in the background and then waiting while an older worker still controls open pages. The waiting state protects consistency across a running page. For a customer midway through a booking or order, this behaviour can be helpful, provided the old page and server remain compatible.
The browser checks for worker updates through its lifecycle, including navigation to an in-scope page and events after an interval described by MDN. Do not promise that publishing a new JavaScript file will update every device at once. Some customers may be offline, some may keep a tab open, and some may never have installed a worker. These are distinct states to test. Record the exact worker script path, scope and registration behaviour first; a team cannot reason about which journeys are affected if it assumes every public page is controlled.
A browser reload is not the same as a safe update. Documentation explains that refreshing a controlled page can still leave the old worker in control during navigation, because the old page remains alive until the replacement arrives. Meanwhile, a newly activated worker can alter how subsequent requests are handled for a page loaded under the older code. Plan for that mixed-version interval. Do not put a bare Refresh now button beside a checkout form without deciding what happens to unsaved fields, submitted requests and the customers next step.
Choose an update strategy from the customer journey
The simplest default is often to let a waiting worker activate after old controlled tabs close. This avoids taking control midway through a task, but it may leave a long-lived tab on older assets. Decide whether that is acceptable by inspecting what the worker caches. If the app precaches HTML or relies on matching sets of versioned assets, Chrome Workbox guidance says a reload prompt may make sense. If navigation is network-first and most resources update at runtime, the need may be different. The decision comes from the apps actual caching strategy and the consequences of an old client, not a generic demand for instant freshness.
An intentional update prompt should say what is happening and leave the customer in control when interruption matters. For a long form, save a draft through a verified application mechanism or wait until the transaction completes. If no reliable save exists, defer the reload and explain that the update can be applied later. Prompt text should be available to keyboard and assistive-technology users, and it must not cover the action the customer is taking. Only offer an automatic reload where the current work can be safely resumed. A technical event is not permission to discard a persons work.
Calling skipWaiting asks the installed worker to activate without waiting for old tabs to disappear. Calling clients.claim in activation can make an active worker take control of eligible pages. These methods are useful but do not themselves migrate page state or guarantee that old JavaScript will understand new cached assets. The web.dev lifecycle guidance explicitly warns that skipWaiting can result in a new worker handling later fetches from a page loaded under the old one. Use the methods only after checking that the release tolerates mixed versions or after the user has agreed to a controlled reload.
Keep asset and server versions compatible
Name caches by the content they hold and the release rules that govern them. An install step should finish obtaining required assets before a new worker is considered ready; an activation step can remove caches that are no longer needed. But deleting every old asset at activation can break an open page that still requests a lazy-loaded file. Check whether the old page names immutable versioned files, whether they remain available on the server, and when it is safe to clear them. Treat cache cleanup as a dependency decision, not housekeeping to run aggressively on every deploy.
The server side has its own compatibility window. If a customer leaves an old booking form open, its eventual submission may reach a newly deployed API. The team should decide whether that request remains accepted, receives a clear recoverable error, or requires migration. Likewise, a new page should not accidentally call an endpoint that was removed while an old worker still serves cached HTML. Record the combinations the release supports: old page with new server, new page with new server, and an offline return. These are business journey tests, not just worker installation tests.
Avoid using service-worker caches as an undefined home for private customer information. Decide explicitly which responses can be stored, how long they remain useful, and how a person can recover from stale content. A static help page differs from an account dashboard or checkout result. This article focuses on update continuity; the separate HTTP and private-response policy still needs its own review. In update testing, clear and inspect browser storage only in controlled test profiles, then repeat with an existing profile that already has the old worker and caches. A clean install alone cannot expose upgrade defects.
Rehearse a booking release
Consider a service business with an appointment form that customers may leave open while checking availability with a colleague. A release changes the form layout and the worker precache. At noon, one customer has a partially completed old form, another opens the site for the first time, and a third returns from an offline connection. The release plan lets the old form continue until submission, preserves server support for its payload, and shows an update prompt only after the first customer reaches a safe stopping point. The new visitor receives current assets; the returning visitor gets a clear recovery path if offline data cannot be synchronized. This is a hypothetical test case, not an observed outcome.
Walk each person through an observable test. On the old tab, enter harmless sample data, deploy the update in staging, observe the waiting worker, then submit exactly once and check the recorded booking. On a new profile, open the same route and confirm it loads the current release. On the offline profile, follow the apps promised offline behaviour and reconnect; check whether messages, data and actions remain understandable. If a prompt is used, test accepting it, dismissing it, switching tabs, and returning later. Record which step is supposed to reload and whether unsaved input survives.
A failed rehearsal should identify the broken contract. If the old form cannot submit to the new API, retain the old endpoint or supply a migration and recovery message before release. If the new worker activates but the old page requests a removed file, keep that versioned file available until old clients can finish. If users are trapped with stale HTML, revise the caching and update prompt, then repeat the upgrade test from an already installed profile. Unregistering a worker in a developers browser may hide the problem; it does not repair customers existing installations.
Define a release acceptance record
For each release, record the old and new worker identifiers, script scope, cached asset set, supported page and API combinations, prompt behaviour and the test profiles used. Confirm that a waiting update eventually becomes active under the chosen strategy, and that a user can identify the current version after any requested reload. Include an owner and a path for customer support to recognize stale-version reports. This evidence is more useful than the statement that the worker file changed on the server. It shows whether a real customer task can reach a safe end across the transition.
Use the result to decide whether immediacy is worth the interruption. A critical defect may justify a carefully controlled prompt and early activation once old pages are protected; a routine visual change may wait for the normal lifecycle. Neither choice should be presented as universally correct. If the application has no service worker, there is no reason to add one solely to follow this process. The business outcome is a reliable customer journey, with cache and update machinery serving that outcome rather than deciding it for the owner.
A support report needs enough context to distinguish an update failure from an ordinary network fault. Offer a safe way for staff to learn the visible app version, active or waiting worker state and time of the last successful synchronization without exposing private customer details. If a customer says the page looks old, ask which task they are doing before advising a reload. A reload that fixes an old logo but loses an unfinished form is a poor resolution. Feed repeated stale-version reports back into the next release test: they may reveal a long-lived tab, a cache rule or a prompt that customers cannot see.
Before you proceed
- Did we test an existing controlled tab as well as a clean visitor?
- Can the old form complete safely against the new server?
- If we prompt a reload, is unfinished customer work preserved or clearly deferred?
