Wiki · Concept · Last reviewed June 25, 2026

Service Workers

Service workers are event-driven browser workers that can mediate network requests, cache responses, and receive functional events outside the lifetime of a visible page.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser API, service workers, offline, agents, fetch, caches, audit trails

Definition

Service workers are a web-platform mechanism for registering JavaScript worker code against an origin and scope. MDN describes them as event-driven workers that sit between web applications, the browser, and the network, enabling offline experiences, request interception, cache control, push notifications, and background synchronization. They run in a worker context, without DOM access, and are available only in secure contexts such as HTTPS, with localhost treated as secure for development.

The W3C Service Workers specification defines the core as a worker that wakes to receive events when another destination would be inappropriate or absent. As reviewed on June 25, 2026, the latest W3C technical report was a Candidate Recommendation Draft dated June 22, 2026, so precise claims should treat it as a living work in progress rather than a finished recommendation.

How It Works

A page registers a service worker script through navigator.serviceWorker.register(). The resulting registration has a scope URL, storage key, and installing, waiting, and active worker slots. The W3C specification describes service worker events as lifecycle events such as install and activate, functional events such as fetch, and messaging events.

MDN's lifecycle guide describes a common path: the browser fetches and registers the worker code, runs it in ServiceWorkerGlobalScope, fires install, waits for older controlled pages before activation, then lets the active worker control later page loads within scope. The fetch event can intercept explicit requests and page subresource loads. A handler can answer with a cached response, synthesize a response, pass through to the network, or return an error through respondWith().

Agent Context

Service workers are quiet infrastructure for the agentic web. A visible page may close while a registered worker remains eligible to receive push, sync, payment, fetch, or message events. That makes them useful for offline-first tools, collaborative editors, mailbox-like interfaces, dashboards, and browser agents that need resilience across reloads.

The same persistence changes accountability. If an agent queues work, refreshes cached state, handles a push message, or intercepts navigation through a service worker, the action may not be visible as a normal button click. The review problem is no longer only what the page showed. It is what the origin registered, which scope it controlled, and what events the browser later delivered.

Governance Use

A governed service worker treats registration as operational authority. The worker can shape what a user sees when offline, decide whether a request reaches the network, replay queued work, update local caches, and serve old or synthetic content. Agent systems should therefore record service worker scope, script URL, version or content digest, update behavior, cache names, functional events used, and the user-facing feature each event supports.

Service workers should also be part of incident review. A stale worker can keep serving old logic after the page code changes. A compromised origin can install worker logic that persists beyond one visit. A poorly governed cache can preserve content the user or institution expected to expire. Clear update, unregister, cache deletion, and user reset paths are part of the safety surface.

Limits

A service worker is not a general background process, consent record, server transaction log, or proof that a user approved later work. The W3C specification ties a worker's lifetime to event execution, and says a user agent may terminate workers when they have no event to handle or when abnormal operation is detected. Systems should not assume a continuously running local daemon.

Service workers also do not solve trust by themselves. They can make a web application more reliable, but they can also mediate what counts as "the page," "the network," or "the current version." Governance should treat them as delegated browser infrastructure, not invisible plumbing.

Minimum Evidence Record

For agent-mediated service worker behavior, record the origin, top-level site where relevant, scope URL, script URL, worker type, registration time, activation time, update check time where available, cache names touched, functional event type, request class or message class, user-facing task, downstream network action, and any explicit user confirmation. Do not log raw tokens, full private messages, or unnecessary cached content merely to prove that an event occurred.

Source Discipline

Use the W3C Service Workers specification for normative lifecycle, registration, scope, event, update, and lifetime claims. Use MDN for developer-facing summaries of secure-context restrictions, service worker concepts, common lifecycle explanations, cache behavior, and fetch event examples. Use the W3C GitHub repository for development context, issue tracking, and editor-facing history, not as proof that a specific browser has implemented a feature.

Spiralist Reading

Spiralism reads service workers as the web's small backstage crew: not the actor on the page, not the server in the distance, but the local mechanism that keeps a promise alive between them. It can make a fragile web app feel humane when the network fails.

The danger is that backstage authority becomes unaccountable. If software can remember, intercept, and retry after the visible page is gone, the user deserves a record of what was kept alive and why.

Sources

Return to Wiki