Web Workers and Service Workers Explained

By Rahul — Google Frontend Engineer

As a Staff Engineer, one of the most common performance bottlenecks I see is a "frozen" UI. Because JavaScript is single-threaded, your beautiful 120Hz animations share the same "Main Thread" as your complex data processing. If you spend 200ms calculating a data visualization, the browser cannot draw a single frame, leading to a janky, unresponsive experience.

To build truly "Google-scale" apps, you must treat the Main Thread as a sacred space for UI only, and offload everything else to Workers.

1. Web Workers: The Computational Workhorse

Web Workers are your secondary CPU cores for the browser. They allow you to run long-running scripts without interrupting the user's interaction.

The Real-World Impact

Imagine an app like Google Sheets. When you update a cell that triggers a recalculation across 10,000 rows, doing that on the main thread would freeze the scroll. By moving that logic to a Web Worker, the user can keep typing while the background thread crunches the numbers.

Real-World Stories: Computation in the Background

1. Photopea (Online Image Editor): This app is a masterclass in Web Workers. Every heavy filter (Gaussian blur, Sharpen) runs in a separate worker. You see a loading bar, but the UI remains fluid—you can still move the window or click menus.

2. VS Code (Web Version): Ever wonder why the editor doesn't freeze when you open a 50MB log file? The syntax highlighting and "IntelliSense" logic are handled by Web Workers, keeping the typing experience lag-free.

3. Figma: While they use WebAssembly (Wasm) for their engine, they leverage workers to handle the serialization of massive document trees so that "Saving to Version History" doesn't hitch the framerate.

2. Service Workers: The Programmable Proxy

Service Workers are fundamentally different. They don't just "run code"; they sit between your app and the internet. They are the backbone of Progressive Web Apps (PWAs).

Real-World Stories: The Offline Revolution

1. Starbucks PWA: Starbucks saw a massive increase in conversions by using Service Workers to cache their menu. Users on spotty subway Wi-Fi can still browse drinks and add to their cart; the Service Worker syncs the order once the connection returns.

2. Twitter Lite: Twitter used Service Workers to implement "Data Saver" mode. The worker intercepts image requests and serves low-res versions from the cache or prevents them from loading entirely based on user settings.

3. Hulu: They use Service Workers to pre-cache the "Next Episode" thumbnail and metadata. By the time you finish your current show, the next one appears to load instantly because the data is already in the local cache.

3. The Lifecycle Mastery (Staff-Level Detail)

Understanding when these workers live and die is what separates a Senior from a Staff engineer.

Service Worker Lifecycle: The "Waiting" Trap

A common bug in production is the "New Version Not Loading." When you update sw.js, the browser installs the new one, but it stays in a Waiting state if any tabs are still open with the old version.

• The Fix: Use self.skipWaiting() in the install event or prompt the user with a "New version available - Refresh" notification.

Web Worker Lifecycle: Disposal

Web Workers are page-bound. If the user closes the tab, the worker dies.

• Staff Tip: Always manually terminate workers using worker.terminate() if you no longer need them before the page closes to prevent memory "bloat" during a long session.

4. Deep Comparison: Which Worker When?

5. Convincing the Staff: The "Performance Budget"

If your "Total Blocking Time" (TBT) in Lighthouse is over 300ms, you have a Main Thread problem. As a lead, your recommendation should be:

1. Is it a CPU-intensive loop? Move it to a Web Worker.

2. Is it a repetitive Network request? Cache it with a Service Worker.

3. Is it UI-related (DOM)? It must stay on the Main Thread.

Real-World Story 4: The Hashing Headache

A security firm I consulted for was calculating SHA-256 hashes for file uploads. For a 1GB file, the UI would freeze for 4 seconds. By moving the SubtleCrypto logic into a Web Worker, we kept the "Upload Progress" animation at a silky-smooth 60FPS while the worker did the heavy lifting.

Real-World Story 5: Push Notifications (The Persistence)

Service Workers allow apps like Facebook or Slack to send you a notification even if the website isn't open. The OS "wakes up" the Service Worker, it runs a small bit of logic to show the notification, and then goes back to sleep. This is the only way to achieve "native-like" behavior on the web.

Summary for Leadership

• Web Workers solve for User Latency (fluidity).

• Service Workers solve for Network Latency (reliability).

• Neither can touch the DOM, so your state management (like Redux or Zustand) needs to handle the asynchronous postMessage bridge.