Lesson 24 of 30

Service Worker Caching Strategies for Performance

Q: You're adding Service Worker caching to an app with three kinds of requests: content-hashed static assets, an auth-sensitive account balance endpoint, and a user's feed of recent activity. What strategy would you pick for each, and why?

A strong answer covers: Cache First for the content-hashed static assets, reasoning that immutable, versioned URLs make staleness a non-issue; Network First (or no caching at all) for the auth-sensitive balance endpoint, reasoning that freshness/correctness matters more than raw speed for sensitive data; Stale-While-Revalidate for the activity feed, reasoning that instant perceived speed matters and one-generation-stale content is an acceptable tradeoff; Explicitly frames this as a per-route decision, not a single blanket strategy for the whole Service Worker.

A Service Worker sitting in front of your network requests is only as good as the caching strategy behind it — and the right strategy depends entirely on how much staleness a given request can tolerate.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A Service Worker uses Cache First for a content-hashed, versioned JS bundle. Why is this a safe choice for that specific asset?

A content-hashed filename never changes its content, so there's nothing for the cached copy to go stale relative toJS bundles are always small enough that staleness doesn't meaningfully affect performanceCache First automatically checks the network in the background to keep the bundle up to date

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Service Worker Caching Strategies for Performance

What interviewers actually ask about this, and what a strong answer has to cover.

You're adding Service Worker caching to an app with three kinds of requests: content-hashed static assets, an auth-sensitive account balance endpoint, and a user's feed of recent activity. What strategy would you pick for each, and why?

A strong answer covers

Cache First for the content-hashed static assets, reasoning that immutable, versioned URLs make staleness a non-issue
Network First (or no caching at all) for the auth-sensitive balance endpoint, reasoning that freshness/correctness matters more than raw speed for sensitive data
Stale-While-Revalidate for the activity feed, reasoning that instant perceived speed matters and one-generation-stale content is an acceptable tradeoff
Explicitly frames this as a per-route decision, not a single blanket strategy for the whole Service Worker

Likely follow-ups

What's the actual failure mode if you accidentally applied Cache First to the account balance endpoint instead of Network First?
How would you reason about a request that's a mix — content that changes occasionally but where a few seconds of staleness genuinely doesn't matter?

Practice these with the AI interviewer →

The plain-language idea

You already know what a Service Worker is and how it intercepts requests from the PWA lesson. This lesson is about the decision that actually determines whether that interception helps or hurts performance: which caching strategy a given request should use. The same intercepted request can be handled three genuinely different ways, each trading speed against freshness differently.

Cache First — check the cache; only go to the network if there's a cache miss. As fast as a request can possibly be when it hits, because it never touches the network at all. Right for versioned, rarely-changing static assets (a content-hashed JS bundle, an icon set) where staleness isn't a real risk — the content simply doesn't change under a given URL.
Network First — try the network first; fall back to the cache only if the network fails. Prioritizes freshness — you always get the latest version when you're online — while still working offline or on a flaky connection by degrading to whatever was last cached. Right for content that should be as current as possible but shouldn't hard-fail without a connection.
Stale-While-Revalidate — serve the cached response immediately (fast), then, in the background, fetch a fresh copy from the network and store it in the cache for next time. A genuinely clever middle ground: the user gets a fast response now, and the cache quietly catches up, at the cost of occasionally seeing one-generation-stale content on any given request.

See it in a real thing: the same request, three strategies

Cache First vs. Network First vs. Stale-While-RevalidateStep 1 of 4

The same request can be routed through a Service Worker three different ways.

Picture a request for /api/user-preferences handled three different ways. Under Cache First, if it's ever been cached, the network is never even contacted — fastest possible response, but a preference changed on another device would never show up. Under Network First, the request always tries the network, so it reflects the latest state whenever the network is reachable, and only falls back to a (possibly outdated) cached copy if the request fails entirely. Under Stale-While-Revalidate, the cached preferences appear instantly, then a background fetch quietly updates the cache with whatever's actually current — so this response might be a version behind, but the next one won't be, without ever making the user wait for the network.

What people usually miss

Watch out

Cache First is only safe for content that's genuinely versioned or immutable. Applying it to something that can change server-side (without the URL changing) means the Service Worker can serve stale content indefinitely — this is the classic Service Worker performance bug, not a caching-strategy edge case.
Network First isn't "no caching" — it still writes to the cache on every successful network response, so the fallback path has something recent to serve, not whatever happened to be cached whenever the Service Worker was first installed.
Stale-While-Revalidate's "staleness" is bounded, not unbounded — every request triggers a background refresh, so the cache is at most one request-cycle behind current, which is a very different (and usually acceptable) guarantee from Cache First's "could be arbitrarily stale until something explicitly invalidates it."
Picking a strategy per-route, not per-Service-Worker, is what makes this actually work in practice — a single blanket strategy for every request a Service Worker intercepts is almost always wrong for at least some of those requests.

Why this matters in interviews

"How would you cache API responses in a Service Worker without serving stale data forever?" is a real, practical question, and naming the three strategies by what each actually optimizes for — instead of a vague "cache it, but also check for updates" — is the difference between an answer that sounds right and one that demonstrates you understand the speed/freshness tradeoff underneath all three.