A site already sets Cache-Control headers on every asset. What can a service-worker cache do that HTTP caching alone cannot, and what does that actually buy the user?
answer
- two caches, two different owners
- headers describe, worker code decides
- network unreachable is not a headers problem
- substitute a response, not just store one
- entries live until your code deletes them
basics
~20 sA service worker runs your own code in front of the network, so it can answer a request while the device is offline, substitute a different response for a failed one, and keep stored entries until your code deletes them. HTTP caching only stores responses and follows freshness rules.
solid answer
~50 sThe HTTP cache belongs to the browser: you describe a policy once, in response headers, and the browser decides whether to store, reuse, revalidate or evict. A service worker is your code running between the page and the network, so the decision happens per request, at request time, on the device. That gives you three things headers cannot: an answer when the network is unreachable — including a real offline page instead of the browser's error — the ability to serve response B for request A, and entries that live until your code removes them rather than until a `max-age` lapses. What it does not give you is speed on a first visit, or anything for a user whose JavaScript never runs. So the honest pitch is resilience and control, not "a bigger, faster cache" — a hashed asset already sitting in the HTTP cache is not served meaningfully faster because a service worker fetched it.
go deeper
Be able to say plainly that headers let the browser decide while a service worker is your own code deciding per request, and that offline behaviour and custom fallbacks are the things headers cannot do.
Explain the mechanics of the split: policy fixed at response time versus a program run at request time, why the first visit is unaffected, and why a hashed asset already in the HTTP cache gains nothing.
Show you would only take on a client-side cache when offline or unreliable-network behaviour is a real requirement, and that you price the storage, support and deploy-risk cost before shipping it.
Own the framing that this moves a piece of delivery policy off your servers and onto users' devices, and be ready to say who maintains it, what it is allowed to store, and how you would remove it.
## Two caches, two owners A browser page can be served from more than one cache, and they are not the same kind of thing. The **HTTP cache** is the browser's own store of responses. You influence it declaratively: you attach headers to a response (a lifetime, a validator) and the browser applies its rules — store it or not, treat it as fresh or stale, revalidate it, evict it under pressure. The policy is fixed at the moment the response is created, and after that you are a spectator. Shared caches such as a CDN work the same way one hop earlier. A **service worker** is a script of yours that the browser runs in the background, separate from any page, and that requests from pages in its scope pass through. For each request it can hand back something it has stored, go to the network, or construct a response itself. The store it reads from is a cache your code fills and empties. Nothing about it is declarative: it is a program that runs at request time on the user's device. That difference — a policy the browser interprets versus a program you wrote — is the whole answer. ## What only the service worker can do **Answer when there is no network.** The HTTP cache can reuse a stored response, but the moment something has to reach the network — a navigation to a document that has gone stale, a request that was never stored — it simply fails, and the user sees the browser's connection-error page. A service worker is still running, so it can serve a stored copy of the page shell, or a page you wrote for exactly this case, and the site stays usable on a train or in a lift. **Substitute one response for another.** Headers can only say things about *this* URL. Your code can answer a request for `/reports/2026` with a cached shell, return a placeholder image for a photo that failed, or map a whole family of URLs onto one stored response. **Decide at request time, not at response time.** Whether to prefer the stored copy or the network can depend on what the request is for, on how the last few requests went, or on a flag you flipped in a later deploy. With headers, the policy travelled with the response; changing your mind means new responses reaching the client first. **Own the lifetime.** Entries stay until your code deletes them; nothing expires them behind your back because a lifetime elapsed. (The browser can still evict the whole origin's storage under pressure, so this is a fast path, never durable storage.) ## What HTTP caching still does better - It works on the **first visit**, and for any visitor whose JavaScript never runs. A service worker cannot help the load that first delivers it. - It is **shared**. One copy in a CDN serves millions of users; a service-worker cache is one device, filled by that device's own downloads. - Conditional revalidation is **built in** — the server can confirm a stored copy is still good without resending the bytes. - It costs no code, no storage you have to reason about, and it cannot break your site. ## What this means in practice Add a service-worker cache when *offline or flaky-network behaviour is a product requirement*, or when instant repeat navigation for an app-like site is worth real engineering. Do not add one because "caching makes things faster" — for content-hashed static assets your headers already deliver a local read on repeat visits, and reading the same bytes through a service worker instead is not faster. Also price the bill honestly. You are storing a second copy of bytes the browser may already have, against a storage quota that can be evicted. You are shipping code onto the request path of every page in scope, so a bug there is a site outage rather than a slow page. And you have created a cache that lives on your users' devices, which — unlike your CDN — you cannot purge from the server. That last point is why a service worker is a delivery *decision* long before it is an API you call.
- If the network is up and the file is already stored, is a service-worker cache hit faster than an HTTP cache hit?Not meaningfully. Both are local reads on the same device, and the service-worker path adds a little work to start the worker and run your handler. The win is not per-asset microseconds; it is being able to answer a navigation instantly, answer at all when offline, and choose what to serve.
- Once you have a service worker, do you still need Cache-Control headers?Yes. The first visit is served entirely by HTTP caching, shared caches and CDNs only understand headers, users without a controlling worker exist at all times, and the worker script itself is delivered over HTTP. Treat the service worker as an additional layer on a correct header policy, never as a replacement for one.
- How durable is the data a service worker stores?Not durable. It lives in the origin's storage quota and the browser may evict it under storage pressure, when the user clears site data, or in some browsers after a long period without visits. Design so that an empty cache is merely slower, never broken — the worker must always be able to fall back to the network.
saying these in an interview costs you the question
- Describes it as just a bigger HTTP cache
- Thinks Cache-Control alone can serve a custom offline page
- Claims it speeds up first-time visitors
- Assumes cached entries expire on their own like max-age
- Treats offline support as free once a worker exists