The service worker lifecycle: install, wait, activate, and update safely
How a service worker registers, installs, waits and activates, what scope means, the trade-offs of skipWaiting and clients.claim, and how to show a "new version available" prompt so users are never stuck.
Comes up in: Web fundamentals, Frontend system design
Learn#
Rohan ships a fix to his PWA, but users keep seeing the old bug for days. His new service worker installed fine, then sat in “waiting”.
A service worker is a script the browser runs between your pages and the network. It can answer requests from a cache, even offline. Its lifecycle has fixed steps: the page registers it; it installs (usually caching files); it waits if an older version still controls open pages; it activates (usually cleaning old caches); then it handles fetch events.
Its scope is the URL path it controls, by default the folder sw.js lives in. Serve it from the root to control the whole site.
Activation waits on purpose: pages loaded by version 1 could break if version 2 swaps their cached files mid-session. The safe pattern is to show a prompt, then switch:
// sw.js
self.addEventListener("message", (event) => {
if (event.data?.type === "SKIP_WAITING") self.skipWaiting();
});
// page
navigator.serviceWorker.addEventListener("controllerchange", () => location.reload());State
- active: v1 (controls 2 tabs)
- installing: v2
Console
empty
Version 1 controls the open tabs. You deploy version 2; the browser fetches sw.js, sees it changed, and starts installing v2.
Read the steps as text
- Version 1 controls the open tabs. You deploy version 2; the browser fetches sw.js, sees it changed, and starts installing v2.
- v2's install event caches the new files. It finishes and becomes "installed", then waits.
- v2 waits because the tabs were loaded by v1. Switching mid-session could mix old pages with new cached files.
- The page shows "New version available — Refresh". On click, it asks v2 to skipWaiting; v2 activates and the page reloads once.
Predict#
Predict first
A user has one tab of your site open and presses Reload. A new service worker is waiting. Does it activate?
During a reload, the old page is still open while the new one starts, so the old worker keeps control. Closing every tab (or navigating away and back) lets the new one activate. This is why “just refresh” often does not work.
Interview angle#
Say it like this — about 30 seconds
“A service worker registers, installs, usually caching assets, then waits if an older version still controls open pages. It activates when no page uses the old one, cleans old caches, and then handles fetch events within its scope. It waits so open pages are not switched mid-session. To avoid users stuck on old versions, I detect a waiting worker, show a refresh prompt, post SKIP_WAITING, and reload on controllerchange. Calling skipWaiting automatically is simpler but can break open tabs.”
Follow-up Describe the service worker lifecycle. Why does a new one wait?
Follow-up How do you avoid users stuck on an old version?
Follow-up What does clients.claim() do?
Practice#
On your own
Write the code behind a “New version available” prompt. The tests use fake registrations built on EventTarget.
Done when
- A worker already waiting at start triggers
onReadyonce. - A new worker that reaches “installed” after
updatefoundtriggersonReady. - Nothing triggers on a first install (no controller yet).
applyUpdateposts{ type: "SKIP_WAITING" }to the worker.
Remember#
Try to answer each card before you open it. Then add them to your reviews.
Name the service worker lifecycle steps in order.
Register, install, waiting, activate, then fetch handling.
Why does a new service worker wait?
So pages loaded by the old version are not switched mid-session.
What does self.skipWaiting() do?
Activates the waiting worker without waiting for old pages to close.
What is a service worker's default scope?
The folder its script is served from.
Go deeper
Four layers. Stop at the one your interview needs; each ends with a quick check.
The core ideaEvery round
The browser checks sw.js for changes on navigation and at least every 24 hours, comparing it byte by byte. Serve it with Cache-Control: no-cache so a CDN does not hide your update Source: web.dev: The service worker lifecycle.
Check yourself: Why must sw.js be served without long caching?
The browser checks it for updates; a cached copy hides new versions.
How it works underneathSenior rounds
The registration fires updatefound when a new worker starts installing; that worker’s statechange moves through installing, installed, activating, activated. navigator.serviceWorker.controller is null on a first visit, which is how you tell a first install from an update.
Check yourself: Which event tells a page that a new worker is installing?
updatefound on the registration.
Edge cases and trapsWhere people slip
skipWaiting skips the wait; clients.claim takes control of uncontrolled pages at once. Together they make updates instant but can break pages that load code chunks from the old build.Check yourself: Why is clients.claim risky?
It takes over pages that loaded without the new worker, which may expect different files.
In productionStaff-level answers
Check yourself: On which origins can you register a service worker?
HTTPS origins, plus localhost for development.
Finished the five steps? Mark it, and its cards join your reviews.
Last checked 2026-11-01. Spot a mistake? Use “Report an error” below — fixes are listed on the corrections page.
Interview questions this answers
- Describe the service worker lifecycle. Why does a new service worker wait?
- How do you avoid users being stuck on an old version because of a service worker?