Caching with a service worker: what to cache and what to skip

A service worker caches assets that never change and leaves the HTML to the network, so a second visit does not download 65 files again. This site has none today: /sw.js answers 404 and caching lives only in the HTTP headers.

Four resources, four strategies

The minimal worker

self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open("static-v1").then((cache) =>
      cache.addAll(["/", "/manifest.webmanifest"]),
    ),
  );
});

self.addEventListener("fetch", (event) => {
  const url = new URL(event.request.url);
  if (url.pathname.startsWith("/api/")) return;
  event.respondWith(
    caches.match(event.request).then((hit) => hit || fetch(event.request)),
  );
});

Install opens a cache with a versioned name and puts the stable files in it; fetch answers from the cache and falls back to the network only when nothing matches. Requests to /api/ return early, so the data never turns stale.

The command

curl -sS -o /dev/null -w "%{http_code}\n" https://ui.eneawork.it/sw.js

The command prints 404 until the file exists: run it after a deploy, because a worker registered once stays active even when the file disappears from the server.

The limitation

Today all caching lives in the HTTP headers, and the measurement describes the ceiling of a precache, not a saving achieved. A badly configured worker serves stale HTML, and to switch it off you must publish a file that unregisters itself: deleting it from the server is not enough.

Where to continue

In the EneUI catalogue: 111,985 components, 1,556 blocks and the record sidebar, a component that does not change between visits. The guides: Cache-Control and immutable and route-level code splitting; the comparison Brotli versus gzip shows how much what you cache actually weighs.