Getting a service worker registered and visible

A service worker file does nothing until it is registered from your page code. Even an empty service-worker.js needs a call to navigator.serviceWorker.register() to take effect. The sample project already loads register-sw.js via a <script> tag in index.html; that file is where the registration logic belongs.

Two practical considerations shape the registration code. First, service worker support is not universal, especially in older browsers, so the registration call should be guarded by a check for navigator.serviceWorker. Second, once registered, the browser runs the worker script and may begin downloading assets based on the install and activate handlers. To avoid competing with page rendering, defer registration until after the window.load event. A general-purpose registration block that accounts for both points looks like this:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/service-worker.js');
  });
}

With registration in place, the service-worker.js file can hold whatever logic your implementation needs. For this exercise, the goal is simply to observe the service worker lifecycle, so populate the file with logging that writes to the DevTools console on key events:

self.addEventListener('install', (event) => {
  console.log('Inside the install handler:', event);
});

self.addEventListener('activate', (event) => {
  console.log('Inside the activate handler:', event);
});

self.addEventListener(fetch, (event) => {
  console.log('Inside the fetch handler:', event);
});

Observing the worker in DevTools

Open the live version of the sample project, then press Control+Shift+J (or Command+Option+J on Mac) to open DevTools. The Console tab should show messages confirming that the service worker was installed and activated:

Shows service worker is installed and activated.

Next, open the Applications tab and select the Service Workers panel. It will display the active service worker with source URL service-worker.js, note the number of controlling clients (open tabs), and provide controls like Unregister and stop for debugging.

Shows service worker details in service worker panel.

Exercising the update flow

Service worker updates follow a specific pattern, and it is worth understanding before you rely on it in production. When a returning visitor hits a URL within the worker's scope, the browser requests the latest service-worker.js automatically. If the script differs from the installed version, the new worker is given a chance to install, activate, and eventually take control.

To simulate this, make any change to the sample's worker file. For instance, replace the following string:

self.addEventListener('install', (event) => {
  console.log('Inside the install handler:', event);
});

with:

self.addEventListener('install', (event) => {
  console.log('Inside the UPDATED install handler:', event);
});

Then reload the live page with the DevTools Application tab open. The Service Workers panel will now show two entries:

Shows two versions of service worker installed.

The previously activated worker remains in control of the current page. The newly installed version sits below it in the waiting state. It stays there until every open tab controlled by the old worker is closed. That default keeps a new worker's changed behavior—for example, a fetch handler returning responses incompatible with older versions of the app—from taking effect while the old version might still be in use.

With registration and lifecycle observation covered, you have the foundation to move on to caching strategies and more involved service worker logic.