Skip to content

SYSTEM Cited by 1 source

Service Worker

A service worker is a W3C-standardised, browser-managed script that runs in a worker thread outside the page and can intercept the page's outgoing network requests before they reach the origin. "Conceptually, it sits between the browser and the origin as a programmable middleman." (Source: sources/2026-05-14-github-from-latency-to-instant-modernizing-github-issues-navigation-performance)

This shape — a programmable proxy embedded in the browser — gives service workers two architectural superpowers no in-page JavaScript runtime has:

  1. Influence over hard navigations. A regular React / in-page runtime is dead the moment the browser starts a hard navigation; a service worker is alive across hard navigations because the browser owns its lifecycle, not the page. "That makes it one of the few web platform primitives that can influence hard navigations without requiring the page's JavaScript runtime to already be active."
  2. Programmable response generation. A service worker can intercept a network request and synthesise a response from any source — the network, an in-process cache, IndexedDB, or its own logic — without the page having to know.

Common use cases

  • Offline-first applications. Cache shell + critical assets at install time; serve from cache when offline; replay writes when connectivity resumes.
  • Background sync. Queue mutations and fire them when the device is online.
  • Push notifications. Wake on push events and surface notifications without an open tab.
  • Cache-hint signalling for SSR substrates. The pattern GitHub introduced for issues#show — the worker checks local cache state and annotates outgoing requests with a custom header so the server can short-circuit expensive server-rendering work and return a thin HTML shell when the client already has the data. See patterns/service-worker-cache-hint-header.

GitHub Issues issues#show cache-hint flow

The structural innovation in the GitHub case is that the service worker's role is not to serve responses from cache on the user's behalf — that's the classic offline-first shape — but instead to inform the server that cache exists on the client, so the server can return a thin HTML shell and let in-page JavaScript hydrate from the local cache:

  1. Browser starts a hard navigation request for an issue page.
  2. Service worker intercepts the outgoing request.
  3. Service worker checks the local cache (often IndexedDB) for the issue payload.
  4. If present, the worker adds a custom request header indicating cache-hit.
  5. Server, on seeing the header, returns a thin HTML shell (layout + minimal markup + JS); React renders from local cache.
  6. If absent / stale / no service worker, the request falls through to the standard SSR path.

This is a strict optimisation: failure modes (no SW, cold cache, stale cache) all degrade gracefully back to the SSR path. (Source: sources/2026-05-14-github-from-latency-to-instant-modernizing-github-issues-navigation-performance)

Why this shape matters architecturally

The conventional service-worker frame is "cache responses, serve them when offline." GitHub's frame inverts the client-server contract: instead of the client substituting for the server (which constrains rendering to whatever the cached HTML shape was at cache-write time), the server cooperates with the client by returning a thin shell when cache is available, leaving rendering responsibility to the in-page runtime where the cache already lives. This decouples the SSR rendering shape from the cache rendering shape — a change that would require evicting all stale cached HTML in the offline-first model can be deployed by changing only the in-page React code, because the cached payload is data not HTML.

Tradeoffs

  • SW lifecycle complexity. Service workers have install / activate / fetch / waiting states with intricate version- rollover semantics. A botched SW deploy can serve stale responses indefinitely.
  • Debug-ability. Network requests routed through a service worker are harder to debug than direct fetch calls; browser devtools have improved here but it remains an extra mental layer.
  • Failure-modes-as-features only when explicit. GitHub's "this is a strict optimization: if the cache is cold, stale, or the service worker isn't available, behavior falls back to the standard server-rendered path" discipline is load-bearing. Designs that depend on the SW being available will break unpredictably for users in incognito mode, on Safari-old, etc.

In the wiki

Seen in

Last updated · 542 distilled / 1,571 read