Offline & Service Workers: Caching Without Breaking Users

What you’ll learn

• What service workers do (and don’t do)
• Offline caching strategies and when they make sense
• The #1 hard problem: cache invalidation

---

30‑second interview answer

A service worker is a script that runs separately from the page and can intercept network requests, enabling offline support and advanced caching. The common strategies are cache-first for immutable assets and network-first (with fallback) for dynamic content. The biggest risk is serving stale or broken content, so you need careful versioning and update flows—and many apps should avoid service workers unless offline is a real requirement.

---

What a service worker enables

• Offline pages
• Faster repeat visits (when caching is correct)
• Background sync (advanced)

But it also adds complexity.

---

Common caching strategies

Cache-first (good for hashed assets)

• try cache
• fallback to network

Network-first (good for dynamic content)

• try network
• fallback to cache

Stale-while-revalidate

• return cached response immediately
• update cache in the background

---

Pitfalls (real world)

• Users stuck on old versions
• Cache poisoning bugs
• Hard-to-debug “it works for me” issues

Service worker updates are not instant. You need an update UX plan.

---

Production rule of thumb

• Use service workers only when offline/poor-network UX is a real product need.
• Cache immutable assets aggressively.
• Keep dynamic caching conservative.

---

Quick recap

• Service workers intercept requests.
• Caching strategies must match content type.
• Invalidation and updates are the hard part.