Caching strategies

Because ServiceWorker is just an event driven JavaScript worker, you have full control over network access. That said, there are common user cases that are found in most Progressive Web Apps.

Caching assets

Normally, you want to cache all the static assets after the application loads. This allows you to fall back on at least the Application Shell when the application is offline.

You can also decide to cache assets manually on user interaction, for instance "read later" for articles or "watch later" for videos.

Dynamic caching

Much of the data applications work with is dynamic, that is it's fetched from database through a remote API. For this type of data, there are some different common approaches:

A stale-while-revalidate strategy will quickly return a cached version of a resource while it goes to the network to fetch an updated version if there is one. This is a good strategy for content that rarely changes.

A cache only strategy is more straightforward: it only returns the cached resource without even trying to go to the network. This is suited for serving the resources for your App Shell and other static content that is only updated when the application version is updated.

In many cases, a network first, but fallback on cache strategy is best suited for dynamic content. With this strategy, you try to fetch the latest content from the server but fall back on a cached version if that fails.

For content that is static but rarely used, a cache first, but fallback on network strategy works well. In this case you try to get things from the cache. If it's not found, you go to the network and add it to the cache for later.

Jake Archibald from the Google team has written a comprehensive guide to working offline with a ServiceWorker. These common strategies are also built into ServiceWorker libraries like Workbox.