After a new deploy of an Angular app using @angular/service-worker, why do returning users see the old version first?

## What the Angular service worker caches `@angular/service-worker` is Angular's pre-built service worker. The build generates **`ngsw.json`**, a manifest listing every file the configuration in `ngsw-config.json` covers, with a content hash for each. The worker (`ngsw-worker.js`) caches those files and serves them from its cache, acting like a CDN edge inside the user's browser. The key concept is the **application version**: the set of files from one build. Any change to any covered file changes its hash in `ngsw.json`, and the worker treats the whole set as a new version. Versioning the files as a group matters because they refer to each other: - `index.html` references specific bundle filenames; - the main bundle references lazy chunks whose names include build hashes; - mixing an old `index.html` with a new bundle, or an old bundle with a missing chunk, breaks the app. ## Why the old version appears first On a returning visit the flow is: 1. The browser asks for the page; the service worker answers **from the cached version immediately**. It deliberately does not wait for the network, because speed is the point. 2. While initializing, and on navigation requests, the worker requests **`ngsw.json`** (with a cache-busting query parameter) to check for updates. 3. If the manifest differs, it **downloads and caches the new version in the background**. 4. The **next load or reload** of the app is served from the new version. So the first visit after a deploy shows the previous build, and the one after that shows the new build. Nothing is broken; this is the designed trade-off between instant loading and immediate freshness. ## The per-tab guarantee The Angular worker promises that **a running tab keeps running the same version**. A tab opened after the update gets the newest version, so two tabs can run different builds at once. This is a stronger guarantee than a plain web deployment, where a running app can request a lazy chunk that the server has already replaced. The version of a running tab changes only in a few cases: | Cause | Kind | |---|---| | The page is reloaded or refreshed | Normal | | The app calls `SwUpdate.activateUpdate()` | Normal, explicit | | The current version fails hash validation | Error | | The worker enters safe mode after an error | Error | Old versions are cleaned up once no tab uses them. ## Getting users onto the new version sooner Waiting for the next visit is fine for many apps. When it is not, the app injects **`SwUpdate`**: - `versionUpdates` emits `VERSION_READY` once the new version is downloaded and ready; - the usual response is to **prompt the user and reload** the page; - `checkForUpdate()` asks the worker to check now, for long-lived tabs that rarely reload. ## Common misunderstandings - **"The deploy failed."** The worker is serving the cached version by design; check the server log for the `ngsw.json` request. - **"Users must close every tab."** That is the browser's rule for installing a new worker *script*. The Angular worker's own script rarely changes between builds; your app versions are switched inside the same worker, on reload. - **"Hard refresh fixes it for everyone."** It fixes one browser; the real fix for users is an update prompt or simply their next load. - **Testing with `ng serve` in development.** The service worker is normally enabled only for production builds (`enabled: !isDevMode()` is the usual option), so local testing uses a production build served by a static server. ## Checking what a client is running The Angular worker exposes a debug page at `ngsw/state` under the app's path. It shows: - the **driver state**, `NORMAL` or one of the degraded states; - the **latest manifest hash** the worker knows about; - when the **last update check** ran; - each cached **version** with the **clients** (tabs) using it. Comparing that hash with the `ngsw.json` currently on the server tells you immediately whether a client has seen the new version yet, which is far more reliable than asking a user to describe what is on screen. The browser's own developer tools also show that requests are served from the service worker rather than the network. ## Interview summary Say that the worker serves the installed version first, checks `ngsw.json`, downloads the new version in the background and switches on the next load, and that each running tab keeps its version so the shell and lazy chunks always match.