Service Worker Caching

A service worker is a JavaScript file that runs in a separate background thread from the main page. It acts as a network proxy — intercepting fetch requests and responding from a cache. This enables offline support, push notifications, and background sync. Service workers must be served over HTTPS (or localhost). In discussions: 'add a service worker' means implement offline or advanced caching strategies.

Cache-First is a service worker caching strategy: check the cache first, return the cached response if found, only hit the network as a fallback. Ideal for static assets (fonts, images, JS bundles) that rarely change. Other strategies: Network-First (try network, fall back to cache) for dynamic content, StaleWhileRevalidate (serve cache immediately, update in background) for content that can be slightly stale.

Precaching means caching a set of resources when the service worker installs, before the user requests them. This typically includes the 'app shell' — the minimal HTML, CSS, and JS needed to render the UI skeleton. Tools like Workbox manage precaching with a manifest. In discussions: 'precache the app shell' means ensure the basic UI loads from cache on repeat visits, even offline.

When a new service worker is deployed, it enters a 'waiting' state — the old one continues controlling pages. skipWaiting() forces the new worker to activate immediately, and clients.claim() makes it take control of open pages without requiring a reload. In update strategy discussions: 'activate and claim' means the new version takes effect immediately rather than waiting for the user to close all tabs.

A cache hit occurs when a requested resource is found in the cache; a miss means the network was needed. The hit rate (hits / total requests) indicates how effective the caching strategy is. A high hit rate means fewer network requests, faster responses, and better offline support. In performance reviews: 'improve the hit rate' means tune caching strategies to serve more requests from cache.