Useful PWA Cache-Control Examples

What are Cache-Control headers exactly?

While PWAs are known for their Service Workers, the humble Cache-Control HTTP header remains the backbone of web performance. It is a string of directives sent by the server that tells the browser (and intermediate CDNs) how to store, update, and expire content. Here are some common recipes:

Recipe 1: The "Fingerprinted" Assets (JS, CSS, Images)

Use this for: Files that have a hash in their filename (e.g., main.a2b3c.js, logo.f8d9s.png).

Cache-Control: public, max-age=31536000, immutable

Why: Since the filename changes whenever the content changes, we can safely tell the browser to cache this "forever" (1 year). The immutable keyword saves the browser from even asking "is this still valid?" saving you a network request.

Recipe 2: The Entry Point (index.html)

Use this for: Files that rarely change filenames but control the version of your app.

Cache-Control: no-cache

Why: This is the most critical header in a PWA. If you cache index.html for even 10 minutes, you cannot deploy a hotfix immediately. no-cache forces the browser to check the server's ETag every time. If the file hasn't changed, it downloads nothing (304 Not Modified). If it has, the user gets the new version instantly.

Recipe 3: Public Content Feeds

Use this for: Blog lists, news feeds, or catalog data where speed matters more than absolute real-time accuracy.

Cache-Control: public, max-age=0, stale-while-revalidate=60

Why: This offers the best user experience. The user sees the cached content instantly (even if it's "stale"), while the browser updates the cache in the background for the next view. It feels like a native app speed.

Recipe 4: The Sensitive Data

Use this for: Banking info, highly sensitive PII, or security tokens that must never touch the disk.

Cache-Control: no-store

Why: This is the nuclear option for security. It instructs the browser, the OS, and any CDN not to write this data to the hard drive or memory cache. Every single request triggers a full network download to ensure the data is never left behind on a shared device.

Why HTTP Caching is the Primary Mechanism

There is a common misconception that a Service Worker replaces the need for server-side cache headers. This is incorrect. The HTTP Cache is the first layer of defense. You should optimize your Cache-Control headers first, and then use the Service Worker to handle offline capabilities and granular caching strategies.

Links & Documentation

• Cache-Control on MDN