The service worker engine is the underlying machinery that powers PWA installability, offline support, and push notifications. Enabling it is a global decision — once on, every page registers the service worker on load.
What Turning It On Does
- The site serves a
/sw.jsfile with browser-friendly caching headers. - Every page registers the service worker via JavaScript on load.
- The worker installs, activates, and starts handling navigation requests.
- From then on, the worker can serve cached assets, deliver push notifications, and run background sync.
Sub-Toggles
- Offline page caching: Cache page shells so the app loads when the network is unavailable. Required for PWA install on iOS.
- Push notifications: Allow the service worker to receive Web Push events.
- Background sync: Defer failing requests until the network is back.
- Periodic background sync: Optionally pre-fetch fresh content even when the app isn't open (Chrome only).
Operational Considerations
- Service workers are sticky — once installed, they survive even if you turn the engine off. Use the “Force unregister” action to evict.
- Updates to the service worker propagate slowly (browser caches it aggressively). Bump its embedded version string when shipping changes.
- HTTPS is required. The platform refuses to enable the engine on plain-HTTP origins.
Worked Examples
- SaaS rollout: Engine on, offline + push enabled, background sync off. Users get install prompts and notifications.
- Field-service rollout: All sub-toggles on, plus periodic sync to pre-fetch each technician's day in the morning.
- Internal-only tool: Engine on, offline on, push off — users don't want noisy notifications.
- Pre-launch staging: Engine off — avoid serving stale cached content during the test cycle.