Service Workers & Web Workers

Service Workers live between the browser and the network. They intercept network requests, cache responses, enable offline support, and receive push notifications — all independently of whether your tab is even open.

Web Workers (background workers) run JavaScript on a separate thread. They can’t touch the DOM, but they’re perfect for CPU-heavy work that would otherwise freeze your UI.

Service Workers — Best Use Cases

1. Offline-First Apps

The killer feature. A service worker can cache your app shell (HTML, CSS, JS) and static assets on first visit. Next time the user opens the app with no network, they still get a working UI. Think Google Maps’ offline area downloads, or a notes app that works on a plane.

2. Push Notifications

Service workers can receive push events from your server even when the browser tab is closed. This is how web apps send “you have a new message” alerts just like native apps.

3. Background Sync

User fills out a form offline? The service worker queues that request and silently replays it the moment connectivity returns. The user never has to retry manually.

4. Smart Caching Strategies

You can implement patterns like:

Cache First — serve from cache, update in background
Network First — try network, fall back to cache
Stale-While-Revalidate — serve cached instantly, then refresh silently behind the scenes

This dramatically improves perceived load speed.

5. PWA (Progressive Web App) Enablement

Service workers are a core requirement for installable PWAs. Without one, you can’t prompt users to “Add to Home Screen.”

Web Workers — Best Use Cases

1. Heavy Data Processing

Parsing a 50MB CSV, running image filters, computing statistics on large datasets — doing any of this on the main thread will freeze the UI. Off-load it to a worker.

2. Real-Time Data Transformation

Streaming stock tickers, sensor data, or log files that need constant parsing/formatting before display.

3. Cryptography

Hashing passwords, generating keys, encrypting files client-side. These are CPU-intensive and belong off the main thread.

4. WebAssembly Execution

Running .wasm modules (e.g., a Rust-compiled image codec or physics engine) in a worker keeps the UI buttery smooth.

5. Code Execution Sandboxes

Online IDEs (like CodeSandbox or Replit) run user-submitted code in Web Workers for isolation and to prevent UI lockup.

Setup — A Quick Mental Model

Service Worker Registration

In your main JS file:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

Then in sw.js, listen for three lifecycle events:

install — cache assets
activate — clean up old caches
fetch — intercept requests and decide what to return

Web Worker Setup

// main.js
const worker = new Worker('/worker.js');
worker.postMessage({ data: bigArray });
worker.onmessage = (e) => console.log('Result:', e.data);

// worker.js
self.onmessage = (e) => {
  const result = heavyComputation(e.data.data);
  self.postMessage(result);
};

Communication is entirely via postMessage — there’s no shared memory by default (though SharedArrayBuffer exists for advanced cases).

Unique & Underrated Use Cases

Client-side A/B testing — A service worker can intercept the initial HTML request and swap in different content variants without a round-trip to the server.
Request deduplication — If 10 components on your page all request the same API endpoint simultaneously, a service worker can coalesce those into a single fetch and fan the result back out.
Incremental search indexing — Build a full-text search index of your app’s content in a Web Worker as the user browses, so instant search is always ready.
Video/audio transcoding — Convert file formats client-side using a Worker + WebAssembly (e.g., FFmpeg compiled to WASM) before upload, saving server costs.
Differential sync — A service worker can detect when the user has been offline, compute the diff of local changes vs. server state, and sync only what changed when they reconnect.
Request mocking in dev/test — Teams use service workers to intercept API calls and return fixture data in local development, simulating backend responses without a real server.

The Core Value Proposition

Service workers make your app resilient and fast — they decouple your UI from the network and server. Web Workers make your app responsive — they decouple your UI from expensive computation. Together, they let you build web apps that feel native: snappy, offline-capable, and capable of heavy lifting.

Service Workers vs Web Workers