The Service Worker Life Cycle

Understand the service worker life cycle to use server workers more efficiently.

We'll cover the following

A service worker goes through many phases during its lifecycle.

The service worker registration

The first step is registering a service worker for the web application during the runtime. From here, the lifecycle of a service worker starts, and the browser initiates its installation in the background.

Registration is done by calling navigator.serviceWorker.register() and passing the URL of the service worker JavaScript file.

Press + to interact
// Register the service worker
navigator.serviceWorker.register('/sw.js')

This registers the service worker but does not immediately activate it.

The lifecycle events

Some events are related to the service worker’s lifecycle—for example, activation and installation.

We can hook into these lifecycle events and execute some code—for example, caching assets after the service worker is installed.

A service worker has the following lifecycle events:

  • The install event
  • The activate event

The install event

After successful registration, the install event gets triggered, which is the right moment for the service worker to perform initial setups like caching the application’s static assets. Later, when the application requests these assets, we can handle these requests from the service worker’s fetch event and respond with the cached assets. It provides a faster and offline-first experience to users.

Press + to interact
self.addEventListener('install', event => {
  // Perform install steps like caching resources 
});

Every service worker receives an install event only once. When a service worker is updated, the browser will consider it a different service worker, and the new service worker will have its own install event.

The activate event

After installation finishes, the service worker will be in an installed state, waiting to be activated. Activation happens the next time pages are not opened from the origin using that service worker.

The service worker will transition to an activating state and fire an activate event. Any clean up of old caches or setup needed when the new version activates can be done here.

Press + to interact
self.addEventListener('activate', event => {
  // Remove old cached resources, claim clients, etc
});

The service worker can now control pages and handle functional events like fetch. Also, the page that registers the service worker will not be controlled until the next reload.

The idle state

Once the service worker is activated, it enters the idle mode. As a service worker is a background process, it handles events only when triggered.

After entering the idle mode, the service worker will listen for functional events like fetch, push, etc. Therefore, it can control the subsequent page loads and navigation. Multiple pages/tabs can be opened under the control of a single activated service worker instance.

Updating a service worker

When we change an existing service worker, the browser updates the old one. This process can be tricky because several pages might use the old service worker. So, to maintain consistency, the new service worker versions are first put in the waiting state before being activated, so old versions can finish handling existing pages until they unload or navigate away. The browser must wait until all instances of the old service workers are closed.