Design a Service Worker caching strategy for a news app

What's really being asked

This question evaluates whether you understand that Service Worker caching is not one-size-fits-all. Interviewers want to see if you can categorize resources by their update frequency and criticality, select patterns that balance performance against freshness, and discuss practical constraints like storage quotas, cache expiration, and how the Service Worker layer interacts with the underlying HTTP cache. They also care whether you can justify trade-offs in user experience rather than simply naming patterns.

The full answer

Four decisions in order. First, the application shell should use Cache First because it is versioned, critical for render, and must load instantly even offline. Second, static assets like CSS and JS bundles should use Stale-While-Revalidate so returning visitors get sub-second loads while the browser fetches an updated version in the background for the next visit. Third, dynamic article API data should use Network First with a short TTL fallback cache so online users always see the latest headlines, but offline users still have something readable rather than a blank screen. Fourth, you must mention cache cleanup strategies such as limiting the number of entries or using a max-age, because mobile devices enforce storage quotas and uncapped growth will evict your origin.

The mistakes people make

Treating every resource with the same pattern, such as Cache First for APIs, which would serve days-old news as current. Another red flag is ignoring the HTTP cache entirely; a senior candidate should note that the Service Worker sits in front of the browser cache and can either bypass it with fetch options or let it absorb redundant requests. Proposing infinite cache growth without eviction logic is also a junior-level mistake. Finally, suggesting Network First for the app shell misses the point of instant offline rendering.

What usually comes next

How would you invalidate the app shell after a deployment? How do you handle opaque responses from third-party CDNs? What happens when the user exceeds the browser storage quota? How would you sync read markers or user preferences when connectivity returns?

A concrete example

In a news PWA, the Service Worker precaches the shell HTML and main bundle at the install event. On a page load, the shell is served from Cache First. A request for article.json is handled with Network First; if the network is down, the last successful response is returned from a cache named content-v1 that stores only the twenty most recent articles. CSS files use Stale-While-Revalidate with a one-day max-age in the Service Worker, while the HTTP cache layer is configured with immutable headers for hashed filenames to prevent revalidation round trips.