Service Worker Registration: Claiming Your Control Scope

Why it exists

Browsers need a way to run background scripts that persist beyond a single page view to enable features like offline support and push notifications. The registration process is the explicit, secure mechanism for a website to request this capability and define the boundaries of the script's control.

The mental model

Think of registering a service worker as hiring a security guard for your website. The scriptURL you provide is the guard's instruction manual (the JS file). The scope option is the map of the pages and paths the guard is allowed to patrol. By default, the guard can only patrol the directory their office is in. To let them patrol the whole site, you need special permission from management (the Service-Worker-Allowed HTTP header).

How it works

When you call navigator.serviceWorker.register('sw.js', { scope: '/' }), the browser downloads sw.js. It then checks if the requested scope is permitted. The default maximum scope is the directory containing the worker script. If sw.js is in /scripts/, requesting a scope of / will fail unless the server sends the sw.js file with the HTTP header Service-Worker-Allowed: /. Once registered successfully, the worker begins its lifecycle (installing, activating) and can intercept network events for pages within its scope. This process only works on secure contexts (HTTPS).

When to use it

Use this on application startup to enable any Progressive Web App (PWA) features. This is the entry point for caching strategies for offline mode, intercepting network requests, handling push notifications, and performing background sync operations. You register the worker once, and the browser manages its lifecycle and updates.

When not to use it

Do not use service workers for tasks tied to a specific web page's DOM or lifecycle. If your logic only needs to run while a tab is open, a regular script is simpler. Service workers run in the background and cannot directly access the DOM of the pages they control; they communicate with pages via messages.

One canonical example

To make an entire site offline-capable, place your service worker script at the root (e.g., /sw.js) and register it from your main app script: if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js').then(reg => console.log('SW registered!', reg)).catch(err => console.log('SW registration failed:', err)); }. This uses the default scope, which correctly resolves to / because the script is at the root.