Service Worker Registration

Service worker registration connects a worker script to a registration and determines the URL scope for which that registration can control pages. Calling `navigator.serviceWorker.register()` begins or updates the worker's lifecycle, with installation and activation handled asynchronously.

Registration is normally performed with `navigator.serviceWorker.register('/sw.js')`. The method returns a `Promise` that resolves to a `ServiceWorkerRegistration` object, which represents the registration and exposes information such as its active, installing, and waiting workers.

The registration's `scope` determines which document URLs the service worker is eligible to control. If no `scope` option is supplied, the default scope is generally the directory containing the worker script. For example, `/app/sw.js` normally has a default scope of `/app/`.

Registration does not mean the worker immediately controls every matching page. The worker progresses through lifecycle states such as installing, waiting, and activating. A newly installed worker generally becomes active after the browser's lifecycle rules allow it to do so, commonly after older controlled clients have been released.

A registration can also be called again when the application starts. The browser can compare the worker script with its current version and perform an update when appropriate. Developers should therefore treat registration as an operation that establishes or updates a registration rather than as a one-time imperative installation step.

An explicit `scope` can narrow or otherwise change the default scope, subject to the browser's service-worker scope security rules. If an application needs a scope extending beyond the worker script's directory, the server may need to provide an appropriate `Service-Worker-Allowed` response header.

Key points

• `navigator.serviceWorker.register()` returns a Promise for a `ServiceWorkerRegistration`.
• The registration associates a worker script with a scope.
• Without an explicit scope, the default scope is based on the worker script's directory.
• Registration starts or updates the service worker lifecycle; control of pages is a later lifecycle step.
• A broader-than-default scope can require the `Service-Worker-Allowed` response header.

Interview questions

What does `navigator.serviceWorker.register()` do?

It registers a service worker script with the browser and associates that script with a scope. The method returns a Promise that resolves to a `ServiceWorkerRegistration`. The browser can then install, activate, and update the worker according to its lifecycle rules. Registration itself does not mean the current page is immediately controlled by the new worker.

How is a service worker's scope determined?

The scope determines which document URLs the worker is eligible to control. If no scope is specified, the default is generally the directory containing the worker script. Developers can provide a `scope` option when registering the worker. Security rules can restrict scopes that extend beyond the worker script's directory.

Does registering a service worker immediately make it control the current page?

No. Registration and control happen at different points in the service worker lifecycle. A new worker normally needs to install and activate before it can control clients, and an existing page may remain associated with the previous controller until a relevant navigation or lifecycle mechanism occurs. The `clients.claim()` API can change control behavior after activation, but it does not eliminate the registration and activation lifecycle.

What happens when `register()` is called again for an already registered service worker?

The browser can reuse the existing registration and check whether the worker script needs an update. If the relevant script has changed, an updated worker can enter the lifecycle alongside the currently active worker. This allows applications to call registration code during startup without manually implementing their own version comparison. The exact update-check timing and caching behavior follow the browser's service worker update algorithm.