The Service Worker Lifecycle: Register, Install, Activate
A service worker is a background proxy that lets your app work offline. Its lifecycle—register, install, activate—governs how it takes control of pages. The biggest footgun: a new worker waits for old clients to close before activating, delaying updates.
Why it exists
Web apps traditionally failed completely without an internet connection. Service workers were created to solve this by providing a robust mechanism to intercept network requests and control asset caching, enabling reliable offline-first experiences similar to native apps.
The mental model
A service worker is like a proxy server that lives inside the user's browser, but one you can program with JavaScript. It sits between your web page and the network. It can't touch the DOM, but it can hijack network requests, check a cache, and decide whether to serve a cached response or let the request go to the network.
How it works
The lifecycle has three main stages. First, REGISTRATION: Your page's JavaScript calls navigator.serviceWorker.register() to tell the browser where the service worker file is. Second, INSTALLATION: The browser downloads and runs the worker script. The install event fires, which is your chance to cache essential assets like HTML, CSS, and JS (the "app shell"). Third, ACTIVATION: After a successful install, the worker waits until it can safely take control. Once no older service worker is controlling any pages, the new worker becomes active, and the activate event fires. This is your chance to clean up old caches.
When to use it
Use a service worker when you want to build a Progressive Web App (PWA) with an offline-first strategy. It's essential for making your app load reliably and instantly, even on flaky networks, by serving a cached shell and then fetching fresh data. It's also the foundation for features like background sync and push notifications.
When not to use it
Don't use a service worker if your site is a simple, static document that doesn't need offline capabilities. The lifecycle adds complexity, and improper cache management can lead to users getting stuck with outdated content. It's overkill for sites that don't benefit from an app-like experience. Also, service workers require HTTPS, so they can't be used on insecure origins.
One canonical example
A news PWA uses a service worker. On the first visit, the worker is registered and, during its install phase, it caches the main page layout, CSS, and JavaScript. When the user re-opens the app offline, the activated service worker intercepts the request for the main page and serves the cached layout immediately. It then tries to fetch new articles from the network; if it fails, it can show a "You are offline" message within the already-loaded app shell instead of the browser's default error page.
Interview question
What is a key challenge when deploying an updated service worker with new features or bug fixes?
- a.Users might temporarily lose offline capabilities while the new worker is waiting to activate.
- b.The old service worker might permanently block the new worker from ever becoming active.
- c.The new service worker might fail to install if essential assets are missing from its cache.
- d.The updated features or fixes may not be immediately available to users with active tabs controlled by the old worker.Correct
Why? this is the answer
The card highlights that 'a new worker waits for old clients to close before activating, delaying updates.' This means users with open tabs controlled by the previous worker won't see the new version until those tabs are closed. Option A is incorrect because the old service worker continues to provide offline functionality until the new one takes over.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #service worker
- #pwa
- #web apis
- #offline
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles