Building a dependable service-worker offline fallback

A service worker can intercept every request within its scope. The safest first offline feature is a narrow, versioned fallback with explicit caching rules and a tested update path.

Choose a limited offline promise

State which public pages or tasks remain available and which must show a clear connection error. Do not imply that a submitted form is complete when its request has only been retained in the browser.

Precache stable essentials

Cache a small offline document and required local assets during install, failing the install if that set is incomplete. Use versioned cache names and retain the current worker until the new set is ready.

Route by request type

Use network-first or cache-first strategies only for matching destinations and methods. Never cache authenticated HTML or API responses by a broad pathname rule, and do not turn a server error into a permanent cached success.

Coordinate updates

Allow existing pages to continue under their current worker or provide an explicit refresh prompt. Test two tabs, an interrupted install, a changed asset manifest and rollback to the previous release.

Observe and clear safely

Record fallback use without storing sensitive URLs, and expire runtime entries by policy. On activation, delete only cache names owned by this application and preserve unrelated origin storage.