Learn the vocabulary of intercepting network requests to enable an offline-capable web experience.
0 / 5 completed
1 / 5
At standup, a dev mentions a script that runs separately from the page itself, intercepting network requests so a cached response can be served even when the device has no network connection. What is this script called?
A service worker runs separately from the page itself, intercepting a network request so a cached response can be served even when the device has no network connection at all. A regular page script only runs while the page's own tab is open and can't intercept a network request independently of that page's lifecycle. This independent interception is what lets a service worker enable a genuinely offline-capable experience, not just a page that happens to load quickly.
2 / 5
During a design review, the team wants a cached response served immediately while the service worker simultaneously fetches a fresh copy in the background to update the cache for next time. Which capability supports this?
A stale-while-revalidate caching strategy serves a cached response immediately for fast perceived performance, while the service worker simultaneously fetches a fresh copy in the background to update the cache for the next request. A cache-only strategy always serves the cached response and never fetches a fresh copy at all, which risks the cached content growing stale indefinitely. This background-revalidation approach is what balances immediate speed against eventually staying up to date.
3 / 5
In a code review, a dev notices the service worker's cache name includes a version identifier that's bumped on every deploy, with the old, differently-named cache explicitly deleted during activation. What does this represent?
Cache versioning bumps the cache name's version identifier on every deploy and explicitly deletes the old, differently-named cache during activation, ensuring an old cached asset doesn't persist indefinitely after the app has moved on. Reusing the exact same cache name across every deploy, with no versioning, risks serving an outdated asset alongside newly deployed ones. This versioning discipline is what keeps a service worker's offline cache from silently drifting out of sync with the actual deployed application.
4 / 5
An incident report shows users kept seeing a broken, outdated version of the site for days after a fix had already shipped, because the service worker's cache had no versioning and never invalidated the older cached assets. What practice would prevent this?
Bumping the cache's version identifier on every deploy and deleting the old cache during activation ensures users pick up the newly deployed assets rather than continuing to be served the stale ones from before. Reusing the same cache name with no version bump is exactly what left users stuck on the broken, outdated version in this incident. This versioning-and-cleanup step is a mandatory part of any service worker setup that caches an application's own assets.
5 / 5
During a PR review, a teammate asks why the team uses a stale-while-revalidate strategy instead of a strict cache-first strategy with no background revalidation at all. What is the reasoning?
A strict cache-first strategy with no revalidation risks serving an increasingly stale response indefinitely, since nothing ever triggers a background fetch to refresh what's cached. Stale-while-revalidate keeps the immediate speed advantage of serving from cache while still fetching a fresh copy in the background, gradually keeping the cache current. The tradeoff is that a user can still occasionally see one stale response before the background-fetched update takes effect on a subsequent request.