Lesson 0002 · ~12 minutes

Registration, scope & first lifecycle

One skill: explain register() → install → activate → control for the first service worker, including scope and why the registering page often is not controlled yet.

1. Register is a page-side call

From a secure page (HTTPS or localhost), feature-detect and register the worker script. The API is navigator.serviceWorker.register():

if ("serviceWorker" in navigator) {
  window.addEventListener("load", () => {
    navigator.serviceWorker
      .register("/sw.js")
      .then((reg) => console.log("scope:", reg.scope))
      .catch((err) => console.error(err));
  });
}

• The script URL is resolved against the origin, not “relative to this .js file” the way module imports often feel.
• No service worker on insecure origins (except loopback for development) — secure context is a hard gate.
• Jeff Posnick’s registration guidance: prefer registering after load so install/precache bandwidth does not fight first-paint resources on slow mobiles.

2. Scope is about the script’s path

A service worker only controls clients under its scope. Default scope is ./ relative to the service worker file URL (lifecycle article, Learn PWA):

• /sw.js → can cover the whole origin path tree from /
• /app/sw.js → default scope /app/ — pages under /marketing/ are out of reach

You can pass { scope: "..." }, but you cannot claim a wider scope than the browser allows for that script location. Practical rule: put the SW script at the highest path you need to control (often site root for a whole SPA).

3. First lifecycle: install → activate

Once register() succeeds at downloading and parsing the script, the browser runs the lifecycle. For the first service worker (no previous version), Jake Archibald’s model is:

// sw.js
self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open("static-v1").then((cache) =>
      cache.addAll(["/", "/styles.css", "/app.js"])
    )
  );
});

self.addEventListener("activate", (event) => {
  // first SW: often nothing; updates clean old caches here
});

If the promise passed to waitUntil during install rejects, installation fails and that service worker never controls anything. That is intentional: you can treat precached assets as install-time dependencies (lifecycle).

4. Registered ≠ controlling this tab

This is the #1 first-visit confusion:

• Registration succeeded → browser is managing the SW for that scope.
• This page is controlled → navigator.serviceWorker.controller is non-null; page fetches go through the SW.

Archibald’s dog/cat demo: the first load still hits the network for a subresource even after activate, because the document itself did not load under the SW. Refresh, and both document and subresources go through fetch handlers.

5. Practice

Choose the best answer. Options matched for length. Immediate feedback.

6. What to remember

• register(scriptURL) + secure context + feature detect.
• Scope defaults from the SW file path — place the script where coverage needs to be.
• Install + waitUntil: succeed together or discard the SW.
• First page often uncontrolled until refresh; clients.claim() is opt-in, not free magic.

Primary source (read next)

web.dev — The service worker lifecycle (Jake Archibald) Read the “first service worker” sections (install, activate, scope, control, clients.claim). Skip or skim “Updating” until lesson 3 if short on time. Secondary: Service worker registration (when to call register).