Service Workers are widely underused despite being available in all major browsers since 2018. Through case studies from Slack, Mux, and the author's own experience, the post demonstrates three practical use cases beyond offline support: Slack achieved ~50% faster boot times by caching assets and Redux state with deploy-keyed cache buckets; Mux used a service worker to intercept and rewrite HLS video manifests to filter out low-resolution renditions; and the author solved Vite's chunk-not-found 404 errors after deploys by caching old assets in the service worker and polling for new versions. The post also highlights that libraries like Partytown and Mock Service Worker already use service workers under the hood. Common reasons teams avoid them include lifecycle complexity, cache invalidation horror stories, and the misconception that they're only for offline support. Workbox is recommended to simplify implementation.

β€’18m read timeβ€’From neciudan.dev
Post cover image
Table of contents
What a service worker actually is πŸ”—Use case one: boot performance and offline support πŸ”—Use case two: the proxy can rewrite anything πŸ”—My use case: the deploy that breaks every lazy-loaded route πŸ”—So why is nobody using them? πŸ”—It’s hard to write Service Workers πŸ”—References πŸ”—
820 Impressions