Network-First Strategy

A network-first strategy tries to obtain a fresh response from the network before falling back to a cached response. In a service worker, this is useful when freshness matters but an offline experience is still desirable.

A network-first strategy is a service-worker caching pattern for resources where current data is preferred. When a request arrives, the service worker first attempts the network request and returns that response when it succeeds.

If the network request fails, the service worker checks its cache for a previously stored response. This fallback allows the application to continue working when the user is offline or the network is temporarily unavailable.

A successful network response can also be placed into the cache so that a newer response is available for a later offline request. The exact caching behavior depends on how the service worker is implemented.

This strategy is particularly appropriate for content that changes relatively often, such as API data or frequently updated pages. It is less attractive when network latency is undesirable and cached content is sufficiently fresh for the use case.

Key points

• Try the network first to prefer fresh content.
• Use the cache when the network request fails.
• A service worker can implement this pattern with the Cache API.
• A successful network response may update the cached copy.
• The pattern trades offline resilience for potentially higher network latency.

Interview questions

What is a network-first caching strategy?

It is a service-worker strategy where the network is attempted before the cache. If the network succeeds, its response is returned, giving the user fresh data. If the network fails, the service worker tries to return a cached response instead. This provides a balance between freshness and offline resilience.

How would you implement network-first in a service worker?

The service worker intercepts matching requests in a `fetch` event. It calls `fetch()` first and returns the network response if successful. The response can be cloned and stored in the Cache API for future fallback use. If the request rejects, the handler calls `caches.match()` to find a cached response.

Why might network-first be slower than cache-first?

With network-first, the browser normally waits for the network attempt before returning a successful response. Network latency therefore affects the response time even when a cached copy is available. Cache-first can return the cached response without waiting for the network. The trade-off is that cache-first can serve older data.

What should happen if both the network and cache fail?

The service worker has no response to return, so the request should ultimately fail. For navigation requests, an application may provide a cached offline page as a separate fallback. For other resources, the appropriate behavior depends on whether the resource is optional or required. A robust implementation should deliberately define this final failure path rather than assuming the cache always contains the request.

What types of resources are good candidates for network-first?

Network-first is useful when users generally need current data but should still get something useful during connectivity problems. Examples can include frequently updated application data or pages whose freshness matters. It is usually less compelling for static assets that change rarely, where cache-first can avoid unnecessary network latency. The right choice depends on the freshness, latency, and offline requirements of the resource.