Service Worker Global Scope

A service worker executes in its own global context rather than inside a page's `window`. This worker global scope provides service-worker-specific APIs and lets the worker handle events independently of a particular document.

The service worker global scope is the execution environment for a service worker script. Unlike page JavaScript, it does not have access to the DOM or a page's `window` object. The global object exposed to the worker is commonly referred to as `self`.

Service workers are event-driven. Instead of continuously running like page code, the browser starts the worker when it needs to dispatch an event such as `install`, `activate`, `fetch`, or `message`. Code in the global scope can register listeners for these events.

The worker global scope exposes APIs appropriate for background network and lifecycle work. For example, `self.addEventListener('fetch', ...)` can intercept requests, while `caches` can access the Cache API. APIs that depend on a document, such as direct DOM manipulation, are not available.

A service worker's global scope is separate from every controlled page. A worker can therefore serve multiple pages within its registration scope, and its lifetime is managed by the browser rather than by the lifetime of an individual page.

Key points

• A service worker runs outside a page's `window` and DOM.
• `self` refers to the service worker's global scope.
• The worker is primarily event-driven, handling events such as `install`, `activate`, and `fetch`.
• The global scope provides worker-compatible APIs such as `caches` and `fetch`.
• A service worker's lifetime is controlled by the browser, so it can be stopped and restarted between events.

Interview questions

What does `self` mean inside a service worker?

`self` refers to the service worker's global scope. It is the worker-side counterpart to the page's global object and is commonly used to register event listeners. For example, `self.addEventListener('fetch', handler)` listens for intercepted requests. It does not refer to the controlled page's `window`.

Can a service worker use `window` and manipulate the DOM?

No. A service worker does not run in a document context, so `window` and DOM APIs such as `document.querySelector()` are unavailable. Communication with a page must instead use mechanisms such as `postMessage` and `MessageChannel`. This separation allows the worker to operate independently of a particular page.

What is the service worker global scope?

It is the global execution context in which a service worker script runs. It is separate from the page's `window` and does not provide direct DOM access. The global object is available through `self`. The browser manages the worker's lifecycle and invokes it to handle relevant events.

Why can a service worker be stopped and later started again?

Service workers are event-driven and their lifetime is controlled by the browser. The browser can terminate an idle worker to reclaim resources, then start it again when another relevant event occurs. Consequently, developers should not rely on in-memory state surviving between events. Persistent state should be stored in browser-managed mechanisms such as IndexedDB or Cache Storage when appropriate.

How does the service worker global scope relate to controlled pages?

The service worker has its own execution context, while controlled pages have their own document globals. A single service worker registration can control multiple documents within its scope, so the worker is not equivalent to any one page's JavaScript environment. Communication between the contexts is explicit rather than direct DOM access. This separation is fundamental to features such as request interception, caching, and background event handling.