PWA and Offline

Service Worker Cache Strategies by Shell, Articles, and APIs

Choose cache-first, network-first, or stale-while-revalidate separately for versioned assets, HTML navigation, articles, fonts, and dynamic APIs with bounds.

A sound implementation does not ask users to refresh until it works. Each phase has an input, an output, a timeout, and a terminal state. Hashed immutable assets fit cache-first, HTML needs freshness plus offline fallback, and user APIs or credentials generally stay out of Cache Storage.

Offline UX distinguishes locally available, pending sync, and server-confirmed states. Cache versions, command queues, and conflict resolution belong together or reconnecting amplifies collisions between old actions and new facts.

Define the system contract first

Start from facts the data and protocol can guarantee, then decide what the interface may promise. Each rule below needs an owner, a bound, and a compatibility policy rather than an oral convention from one review.

  • Route by destination and URL, verify status, type, and size before caching, use SWR for articles, network-first with a short timeout for navigation, and bypass APIs.
  • Define success, degraded, cancelled, and failed terminal states before UI, storage, and metrics consume the same state.
  • Ship conservative defaults, server-side ceilings, and a rollout switch instead of trusting browser-provided numbers as resource budgets.

The delivery standard for Service Worker Cache Strategies by Shell, Articles, and APIs is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.

What can break that contract

Failure and success must share one state model. An error toast that neither releases resources nor propagates a terminal state leaves dirty work for the next recovery attempt.

  • Cache-first for every GET preserves stale HTML and sensitive APIs, while caching 404 or 521 keeps an outage alive after recovery.
  • Refresh and network change start two recovery paths, and duplicate side effects look like two genuine user actions.
  • An untested fallback receives all traffic during a primary failure and becomes the slower, more expensive bottleneck.

How to test the contract line by line

A release gate combines deterministic regression, randomized timing, and real browser pairs. Preserve the seed and state trace from every failure as a permanent replay case.

  1. For each resource class test online, slow, offline, 521, updates, and full cache; verify hits, expiry, fallback, sensitive exclusions, and bytes.
  2. Disconnect, change networks, and recover mid-operation; reconcile endpoint state, persistence, and resource counts.
  3. Use fault injection to prove alerts precede user reports and operators can locate the failing phase from bounded evidence.

The result must be correct, recoverable, and explainable. If any part depends on refreshing the page or an engineer guessing, the protocol loop remains incomplete.

Put the guide to work

Open uCopy and connect two devices securely from the browser.

Start for free