Service Workers

Enabling the Service Worker Engine

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.js file 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.

Offline Cache for Pages and Resources

The offline cache is the bag of pages, scripts, images and API responses the service worker keeps locally so that when the network is gone the user can still navigate, read, and even edit certain things.

What's Cached by Default

• App shell: The HTML skeleton common to every page.
• CSS and JS bundles: All the static assets the app needs to render.
• Fonts and icons: Web fonts and the icon set.
• Logo and branding images.
• Recent navigations: The last N pages the user visited.
• Selected API responses: Configurable per endpoint (e.g. user profile, list of today's jobs).

Cache Strategies per Asset Type

• Static assets: Cache-first — serve from cache, network only on miss.
• API responses: Network-first with cache fallback — try fresh data, fall back to cached on failure.
• Pages: Stale-while-revalidate — serve cached version immediately, refresh in background.
• Mutations (POST/PATCH/DELETE): Never cached; queued for retry when offline.

Cache Eviction

• Total cache size capped (default 50MB).
• Oldest entries evicted first when cap reached.
• Pinned items (logo, app shell) protected from eviction.
• User can manually clear cache from app settings.

Worked Examples

• Field engineer on building site: Walks into basement, loses signal. Today's job list still visible (API response cached on morning sync); they can read job details and tick off completed steps; saves queue up and sync when signal returns.
• Plane traveller: Loads the app before take-off. In-flight they can still browse cached training videos and notes; everything new syncs on landing.
• Brief network drop: User in the lift loses connection for 30 seconds. App keeps working from cache; user doesn't notice.
• Reading list: User flagged 5 docs for offline reading; service worker pre-fetched them at the previous online session.