I want the benefits of a service worker (faster repeat visits, offline resilience, PWA installability) but I know a badly designed one can serve stale content forever and be nearly impossible to get rid of. Design and implement a service worker caching strategy for my app: 1. Inventory my asset types and pick a strategy per type: - Fingerprinted static assets (hashed filenames from my build): cache-first, immutable, safe to cache forever. - HTML documents: network-first with a cache fallback, so users get fresh content but something loads offline. - API/data responses: decide deliberately. Usually network-only or a short stale-while-revalidate; caching user data client-side has privacy implications, especially on shared devices. - Images: cache-first with a sensible cap on cache size so it doesn't grow without bound. 2. Implement cache versioning: every deploy gets a new cache name, and activation deletes old caches, so users don't run stale assets against new code (the classic 'site broken until hard refresh' bug). 3. Handle updates explicitly: when a new service worker is waiting, either activate it safely or prompt the user to refresh. Don't leave users stranded on an old version silently. 4. Give myself an escape hatch: a documented way to unregister the service worker remotely (a 'kill switch' version that clears caches and unregisters) in case a bad one ships. 5. Test the failure modes: offline behavior, first visit, repeat visit, deploy rollover, and what happens when the cache fills. Don't cache authenticated API responses by default. Don't cache opaque third-party responses without a reason. The deliverable is the service worker with per-type strategies, the versioning and update flow, the kill switch, and a test checklist I can run through on each deploy.