Cache API

In this chapter

We'll meet the Cache API — a real, programmable store for whole Request/Response pairs, genuinely different from the browser's own automatic HTTP cache, and the storage foundation offline-first web apps are built on.

8–10 min

The Problem in Real Life

"IndexedDB can hold the catalog's data," Sarah says, "but offline browsing needs more than data — it needs the actual images, the actual page files, everything a browser normally has to fetch fresh over the network."

Mike looks confused. "Doesn't the browser already cache that stuff automatically?" "It does," Sarah says, "but that automatic cache isn't something we control. This one is."

Isn't there already a cache for that? Why do we need another one?

Mike

A Cache the Browser Controls vs. One GreenMart Controls

Full, explicit control — not the browser's automatic cache

The Cache API is fully programmable: your own code decides exactly what gets cached and for how long, unlike the browser's header-driven automatic HTTP cache.

Stores whole Request/Response pairs, not application data

A real URL mapped to a real network response — genuinely different from IndexedDB's structured application data.

The Cache API is a real, programmable storage mechanism for exactly one kind of thing: whole HTTP Request/Response pairs — not application data like a cart or a catalog record, but the literal network responses a browser would otherwise have to fetch fresh, every time.

What it actually stores. A Cache API entry is a real Request object (a URL, effectively) mapped to a real Response object (the actual body, headers, and status the server returned). Storing GET /product-image-402.jpg once means every later request for that exact URL can be answered instantly from the cache, without ever touching the network — a real image file, a real API response, a real HTML page, all storable this way.
How it's genuinely different from the browser's own built-in HTTP cache. Every browser already has an automatic cache, governed by HTTP headers like Cache-Control — that cache is real, but it's not something GreenMart's own code controls directly; the browser decides what to keep and for how long, based on server-sent rules. The Cache API is the opposite: fully programmable, fully explicit — GreenMart's own code decides exactly what gets cached, when, and for how long, using real method calls like cache.put(), cache.match(), and cache.delete().
Why it exists specifically for offline-first apps. A page can't rely on the browser's own automatic HTTP cache to guarantee something will still be available with no network connection at all — that cache is a performance optimization, not a durability guarantee. The Cache API, paired with a Service Worker (the very next chapter) intercepting real network requests, is what makes a genuine promise possible: "this specific set of files will be available, on purpose, even with zero connectivity."
Multiple named caches, real version control. A page can open several separate caches by name — caches.open('catalog-v1'), caches.open('images-v1') — which makes it possible to update one category of cached content without touching another, and to cleanly delete an old version once a new one is ready, a real pattern for keeping cached content from silently going stale forever.

The Cache API alone doesn't make anything work offline — it's a real, precise storage mechanism, but something still has to decide when to serve a cached response instead of hitting the network. That decision-making layer is exactly what the next chapter's own mechanism, the Service Worker, is built to provide.

Key Takeaway

The Cache API is real, explicit control over exactly what network responses get kept and reused — genuinely different from the browser's own automatic HTTP cache, and the real foundation offline-first apps are built on, one real cached response at a time.

Why This Matters

Mike's idea of a genuinely offline-browsable catalog needs more than stored data — it needs the actual product images and page assets to be reliably available with zero network connection. The Cache API is the real, specific mechanism that makes that promise possible, rather than left to the browser's own best-effort automatic caching.

GreenMart now has a real way to store whole network responses on purpose, under GreenMart's own explicit control. The next chapter meets the piece that actually decides when to use them: the Service Worker, a background script that can intercept every request a page makes.