How Service Workers Live Their Lives

2019-07-09PWAs3 min read

Today, I got more familiar with the Service Worker life cycle and learned why my serviceWorker.js refuses to update when I change the code. I assume you're familiar with basic service worker concepts. If not, check them out here

Service Worker life cycle

Like everything in JavaScript, service workers are asleep most of the time. Code runs when an event is fired.

A typical service Worker goes through these stages

  • Parsed
  • Installing
  • Installed
  • Activating
  • Waiting
  • Activated
  • Redundant

Aside: I was so delighted when I found a diagram that fit this life cycle most from Ire Aderinokun's site.

The service worker lifecycle from Ire's blog
The service worker lifecycle from Ire's blog


This is when the web page registers the service worker. Since a service worker is JavaScript, the browser has to convert it to format it can easily execute.

Installing & Installed

After being parsed, the service worker enters the installing stage. Here, we can listen for the installation event like so;

self.addEventListener("install", event => {
  console.log("Install event fired")

The installation stage happens once in a service worker lifetime, so it's a great time to cache files the service worker depends on. It's very common to abort the installation of the service worker if the caching fails. We don't want to ever install a service worker without required files. This code adds offline.html in the cache during installation

self.addEventListener("install", event => {
  event.waitUntil("assets-cache").then(cache => {

event.waitUntil ensures the code block doesn't finish until the promise is resolved or rejected (the file is added to the cache or not). creates a cache with the passed argument as the name. If the file is added successfully, the promise is resolved and the service worker moves to the installed stage. If it isn't, the promise is rejected and the service worker does not install (moves to the redundant stage).

Activating & Activated

The service worker is now installed and is getting ready to control the page. We can listen to the activate event and do a few things before moving to the activated stage. One of those things is clearing old cache since we won't be needed data from it anymore.

Install and activate events can only happen once in a service worker lifetime. A service worker can't control a page if it wasn't activated before the page was loaded. This means if a service worker can't control a page the first time it's loaded, this is because it was parsed after the page loaded. It only has control over the page when it is reloaded (the parsed version is now available before anything loads).


More like hell for service workers. All service workers that get replaced or don't activate successfully are sent to this state. They never come backšŸ˜¢.

Replacing old service workers

If the code in the service worker changes, the browser orders a re-installation of the new service worker. The new service worker is parsed, installed and moves to the waiting state.

It doesn't take control of the page until the user closes all browser tabs controlled by the existing service worker. This way, one tab doesn't change the state while others operate with the old one. When all tabs have been closed, the waiting service worker moves to the active state.

This is more difficult and complicated than it sounds. There's still a lot I'm still discovering about service workers and I'll update this article as I learn more.

Thanks for readingšŸ˜Š.