Stale‑while‑revalidate versus Network‑first for Zero‑Downtime PWA Updates in Opera on Unreliable Networks

Direct answer

For a PWA that must stay usable while the device flips between online/offline or suffers low bandwidth, stale‑while‑revalidate gives lower perceived latency during an update because it serves the cached copy instantly and fetches the new version in the background. Network‑first can block the UI while waiting for a network response, leading to blank screens or noticeable delays.

How freshness is affected

• Stale‑while‑revalidate: The user sees the previously cached version immediately. After the background fetch finishes, the cache is updated and the next navigation shows the fresh content. If the device goes offline before the background fetch completes, the user may continue to see slightly stale data until connectivity returns and the fetch succeeds.
• Network‑first: When online, the request goes to the network first, so the displayed content is as fresh as the network allows. If the request fails or is slow due to poor connectivity, the service worker falls back to the cache (if a fallback is defined) or shows an empty UI, which can make the app appear outdated or unresponsive until the network recovers.

Cache‑versioning practices to avoid permanently stale assets

1. Include a version string (e.g., v2026-10-11) in the service‑worker script name or as a constant (const CACHE_VERSION = 'v2026-10-11';).
2. Prefix all cached asset URLs with that version or add a cache‑busting query parameter (/app.js?v=2026-10-11). When the version changes, the URLs are new, forcing fresh caches.
3. In the install event, pre‑cache the new assets using the versioned URLs.
4. In the activate event, loop through caches.keys() and delete any cache whose name does not match the current CACHE_VERSION.
5. Optionally set a max‑stale header or use Cache-Control: max-age=0, stale‑while‑revalidate=86400 to bound how long a stale response may be served.

Practical steps for this case

// sw.js
const CACHE_VERSION = 'v2026-10-11';
const STATIC_CACHE = `static-${CACHE_VERSION}`;
const API_CACHE = 'api-data';

self.addEventListener('install', e => {
  e.waitUntil(
    caches.open(STATIC_CACHE).then(cache => cache.addAll([
      '/',
      '/index.html',
      '/styles.css?v=' + CACHE_VERSION,
      '/app.js?v=' + CACHE_VERSION,
      '/icon-192.png'
    ]))
  );
});

self.addEventListener('activate', e => {
  e.waitUntil(
    caches.keys().then(keys => Promise.all(
      keys.filter(key => !key.startsWith('static-') && key !== API_CACHE)
        .map(key => caches.delete(key))
    ))
  );
});

self.addEventListener('fetch', e => {
  const url = new URL(e.request.url);
  // Static assets: stale‑while‑revalidate
  if (url.origin === location.origin && url.pathname.startsWith('/')) {
    e.respondWith(
      caches.match(e.request).then(cachedResp => {
        const fetchPromise = fetch(e.request).then(networkResp => {
          caches.open(STATIC_CACHE).then(cache => cache.put(e.request, networkResp.clone()));
          return networkResp;
        });
        return cachedResp || fetchPromise;
      })
    );
    return;
  }
  // API calls: network‑first with cache fallback
  if (url.pathname.startsWith('/api/')) {
    e.respondWith(
      fetch(e.request).then(networkResp => {
        caches.open(API_CACHE).then(cache => cache.put(e.request, networkResp.clone()));
        return networkResp;
      }).catch(() => caches.match(e.request))
    );
    return;
  }
});

Missing diagnostic detail

The recommendation above assumes that a short period of stale API data is acceptable. If your application requires near‑real‑time data (e.g., live chat or stock quotes), please confirm the maximum tolerable staleness for API responses; if it is effectively zero, a pure network‑first approach (with appropriate offline fallback) would be required instead of the hybrid strategy.