In this chapter
We'll turn every mechanism from this Act into a real, working offline-first strategy — cache-first, network-first, and stale-while-revalidate for different kinds of data, plus Background Sync for queuing an action (like adding to cart) taken while genuinely offline.
The Problem in Real Life
Every real piece is finally on the table: the Cache API to store responses, a Service Worker to intercept requests, IndexedDB for structured data. "Now the actual question," Sarah says. "Not just can we go offline — but exactly when do we serve cache instead of network, and what happens if someone tries to add to their cart with zero signal?"
Mike leans in. This is the actual idea he had, finally becoming real.
So — could someone genuinely keep shopping, offline, and have it actually work when they're back online?
Mike
Having the Pieces vs. Having a Real Strategy
Three real caching strategies, three real trade-offs
Cache-first, network-first, and stale-while-revalidate each trade freshness against speed differently — the right choice depends on the specific data.
Background Sync queues what can't complete right now
An action taken offline (like adding to cart) gets queued, not failed — completed automatically the moment real connectivity returns.
Offline Storage & Offline-First Patterns
Every mechanism in this Act so far is a real tool. Offline-first design is the actual discipline of deciding, deliberately, how those tools work together — which requests serve from cache, which always need the real network, and what happens to an action a customer takes while genuinely offline.
- Cache-first — serve instantly, update quietly. For content that rarely changes — GreenMart's own product images, the app's own JavaScript/CSS files — a Service Worker's fetch handler checks the Cache API first and returns it immediately if found, only reaching the real network on a genuine cache miss. This is what makes the catalog Mike imagined genuinely available offline: the images were already there, on the device, before the connection ever dropped.
- Network-first — always try live, fall back to cache. For content that changes often and matters when it's wrong — GreenMart's own real-time stock counts, current prices — the opposite strategy applies: always attempt the real network first, and only fall back to a cached copy if the network genuinely fails. This accepts a small real speed cost in exchange for freshness, exactly the trade-off worth making for data where "stale" is a real, meaningful risk.
- Stale-while-revalidate — the honest middle ground. Serve the cached copy immediately for real speed, then quietly fetch a fresh copy in the background and update the cache for next time — the customer never waits, but the cache doesn't stay stale forever either. A real, genuinely useful strategy for content that changes sometimes but where showing last week's version for a few extra seconds isn't a real problem.
- Background Sync — the real answer to "what if they add to cart while offline." A Service Worker can register a sync event, deferred until the browser detects a real connection again. The real pattern: when offline, an "add to cart" action gets written to IndexedDB as a pending action, instead of failing outright; a registered background sync event later reads that pending queue and actually sends it to the server, the moment connectivity genuinely returns — turning a would-be failed action into a deliberately queued one.
| Data Type | Right Strategy | Why |
|---|---|---|
| Product images, app assets | Cache-first | Rarely changes — instant load matters more than freshness |
| Live stock count, current price | Network-first | Wrong data here is a real, meaningful risk — freshness matters more than a small speed cost |
| Product descriptions, category listings | Stale-while-revalidate | Changes occasionally — a few stale seconds is a real, acceptable trade for instant load |
| "Add to cart" while offline | Background Sync | Can't complete immediately with no connection — queue it, complete it the moment connectivity returns |
None of these choices is universal — the right strategy depends entirely on how often the real data changes and how costly a stale answer actually is.
This is Mike's original idea, genuinely real now: a customer loses signal mid-aisle, keeps browsing the catalog (served instantly from cache), adds an item to their cart (queued via background sync), and the moment their phone finds signal again, that action actually completes — with the customer never even needing to know any of this happened underneath.
Key Takeaway
Offline-first isn't one setting to turn on — it's a real, deliberate choice, made per kind of data, about how stale an answer is allowed to be and what should happen to an action that can't complete right now. Every real offline experience is built from exactly these small, specific decisions.
Why This Matters
A genuinely offline-capable storefront is a real competitive difference for GreenMart — a customer who keeps browsing through a dead zone, instead of hitting a blank error page, is a customer who's still there when signal returns. This is the actual payoff of every mechanism this Act has built toward.
GreenMart now has a real, working offline-first strategy — cache-first for stable content, network-first for anything where stale is risky, stale-while-revalidate for the honest middle ground, and background sync for actions that can't complete right now. The Act's final chapter turns all six real mechanisms covered so far into one decision framework.