Lesson 0004 · ~12 minutes

Deal-breakers & integration risks

One skill: run a 60-second design-review scan — when Cache Storage is the wrong tool, and which production edges kill “just cache everything.”

Win for this lesson

You can reject a bad caching proposal quickly (wrong store, no versioning, opaque landmine, dual-cache blindness, “durable forever”) and green-light a good one with eyes open on quota and cleanup.

External sources still optional

You’ve been lesson-first — fine. This page is self-contained for the quiz. Highest-value later skim: Storage for the web (quota / eviction) and SW caching and HTTP caching (two layers).

1. Wrong tool (reject before API details)

Requirement Usually not Cache Storage Prefer
Drafts, entities, offline queues Request/Response “rows” IndexedDB
Tiny theme / flag strings Named cache ceremony Memory / careful Web Storage
File editor buffers HTTP-shaped warehouse OPFS (or Blob-in-IDB)
Checkout / live balances Stale success from cache Network only + honest offline UX

Lesson 1 still holds: Cache Storage wins for HTTP resources that load or speed the app — not as a general kitchen sink (web.dev).

2. Versioning & “nothing expires”

MDN is blunt: items do not update or expire unless you replace or delete them ((Cache). Teams that open one eternal cache name ship stale shells forever.

3. Opaque / CORS landmines

From the Cache API quick guide:

4. Two layers can fight

Request order when a SW handles fetch (SW caching and HTTP caching):

  1. Your service worker strategy (Cache Storage)
  2. Browser HTTP cache
  3. Network

A “revalidate” fetch can still be satisfied by a long Cache-Control: max-age in the HTTP cache — so the SW never sees the origin. Design headers and strategies together; they do not have to share one TTL, but they must not silently cancel each other.

5. Quota, eviction, Safari

Cache Storage shares origin quota with IndexedDB and friends. Writes can reject with QuotaExceededError — always catch and have a plan (storage-for-the-web). Under disk pressure, best-effort site data may be evicted (often least-recently-used origins first on Chromium/Firefox).

Clone or lose

Response bodies are streams. If you both put and respondWith the same body, use response.clone() (Offline Cookbook / Fetch). Silent “body already used” bugs look like flaky offline.

6. Practice — reject or green-light

Equal-length options. Immediate feedback.

Scenario A

Proposal: store offline multi-paragraph drafts as Response bodies in Cache Storage keyed by fake URLs.

Scenario B

Team opens static-v1, v2, v3 over deploys but never deletes old names on activate.

Scenario C

Third-party font via no-CORS fetch (opaque, status often 0). They insist on cache.add during install.

Scenario D

SWR “always refreshes in background,” but origin never sees hits: assets ship with year-long max-age and no busting.

Scenario E

Product wants a legal claim: offline shell “will never be deleted on any browser for 90 days without user action.”

7. What to remember

Ask your teacher Team-specific: Workbox generateSW, opaque CDN fonts, or Safari PWA install paths — ask in chat.

Primary source (read next)

web.dev — Storage for the web for quota, eviction, and the spectrum defaults. Pair with SW caching and HTTP caching for dual-layer fights.