Skip to content
Devgo

Service worker

A script the browser runs in the background, separate from the page, that can intercept network requests, cache, and enable offline and push. The basis of PWAs. Outlives page loads; powerful but must be carefully versioned.

When to use
  • Offline support, PWAs, push notifications, app-shell caching.
  • Performance via caching.
When not to
  • Sites that must always show fresh content.
  • Without a strategy for cache updates.

Definition

A is an event-driven worker that the browser installs and runs off the main thread. It intercepts fetch events to serve from cache (offline), handle push notifications, and background sync. It's a programmable proxy in the browser.

Why it exists

Web apps couldn't work offline or get push notifications. Service workers give the web installable, offline-capable, push-enabled app capabilities, closing the gap with native apps.

How it works

Register a ; on install, pre-cache assets. On fetch, intercept and serve cache-first/network-first/etc. Updates ship a new worker that waits to activate. Push events wake it. Lives across page loads.

Scaling limits

Versioning and are notoriously hard (users stuck on old caches). It runs off the main thread, so no access. Storage quotas limit caches. Aggressive caching can serve stale content.

Cost shape

Free (client-side). The cost is the operational complexity of cache versioning and updates.

Alternatives

  • HTTP caching (Cache-Control) — Simpler, server-controlled, no offline/push.
  • Native app — More capabilities, more cost.

Failure modes

  • Stale caches from bad versioning.
  • Serving stale critical updates.
  • Storage quota exhaustion.

, , ,