Service Worker Caching Strategies
Tags: webdev, beginners, tutorial, javascript
Published: 2022-01-26 05:47:49

Service workers are an essential part of developing rich and powerful web applications. It provides the technical foundation to features like offline support, periodic background syncs and push notifications and eventually supports Progressive Web Apps (PWA).

In order to provide great offline support, necessary resources and (sometimes) data  need to be cached within the web browser. 

At a high-level, a web application can have multiple levels of caching.

1. **Service Worker Cache** - This is only enabled programmatically by installing a service worker into the web application. Once enabled, resources are cached using Cache Storage or IndexedDB. There are different caching strategies in this level, and we will talk more about it later in this post. 

2. **HTTP Cache / Browser Cache** - Browsers tend to cache resources in the browser. If the cache has not yet expired, the browser automatically uses the cached response avoiding an external network request. However this behavior can be changed using certain response headers. 
https://web.dev/http-cache/

3. **Server-Side Cache** - Network components like CDN are used to achieve this level of caching. However this does not help the offline support of your web application, but it drastically reduces content loading time over the network. 
https://vercel.com/docs/concepts/edge-network/overview  

If the content is not found in any of these levels, request will reach the origin server. 

![Cache Level in a Web Application](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cenc2jj8ms7h4evtgab9.png)

https://web.dev/service-worker-caching-and-http-caching/

In this post, we will focus on different Service worker caching strategies. Each strategy will have its pros and cons and you can implement one or more strategies depending on your application characteristics. 

Also I have created a playground that demonstrate how each caching strategy works.

Please note, that this application does not have any actual service worker implementation, and intention was to create a visualization that mimics the actual behavior. 

![Cache Visualizer Application Demo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vk5qa5lui1avablpxdna.gif)

I recommend to continue reading this post in a desktop (wide) browser, since you might not be able to properly interact with the `codesandbox` app that is embedded in this post. 

Let's get started...! 

## Stale While Revalidate

The stale-while-revalidate strategy checks the cache first and respond immediately if there is a cached response. Meanwhile a revalidation request will be initiated to the server and that new response will be cached for the future use.  

This is a fairly common strategy where having the most up-to-date resource is not vital to the application.

![Stale while Revalidate](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1r6nm7mzrh5jfih84s6c.png)

{% codesandbox sw-cache-visualizer-vw649 initialpath=/stale-while-revalidate %}

https://developers.google.com/web/tools/workbox/modules/workbox-strategies#stale-while-revalidate

## Cache First (Cache Falling Back to Network)

If there is a cached response, that will be served immediately and network will not be used at all. But if there is no cached response, it will fall back to network to get the latest response. 

For assets that are non-critical, Cache First is the best option. Also this will gradually cache the responses as you use the app.

![Cache First (Cache Falling Back to Network)](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s2ydn1dcsczz47zcgfgl.png)

{% codesandbox sw-cache-visualizer-vw649 initialpath=/cache-first %}

https://developers.google.com/web/tools/workbox/modules/workbox-strategies#cache_first_cache_falling_back_to_network

## Network First (Network Falling Back to Cache)

As the first attempt, it will try to get the response from network. If it is successful, that response will be served while stored in the cache as well. If the network is not accessible, cached response is used. 

For requests that are updating frequently, the network first strategy is the ideal solution.

![Network First (Network Falling Back to Cache)](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f9avlgqry6ulxbi3411z.png)

{% codesandbox sw-cache-visualizer-vw649 initialpath=/network-first %}

https://developers.google.com/web/tools/workbox/modules/workbox-strategies#network_first_network_falling_back_to_cache

## Network Only

This does not involve any cache. Always relies on the network to get the response. 

![Network Only](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vcfpbtxuwjh33efkutcf.png)

{% codesandbox sw-cache-visualizer-vw649 initialpath=/network-only %}

https://developers.google.com/web/tools/workbox/modules/workbox-strategies#network_only

## Cache Only

Network will not be used at all. This is a less commonly used since, you have do a pre-caching step before this strategy to work.

![Cache Only](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qoydchrzw59uf0qib970.png)

{% codesandbox sw-cache-visualizer-vw649 initialpath=/cache-only %}

https://developers.google.com/web/tools/workbox/modules/workbox-strategies#cache_only

# Conclusion

Today we learnt about different caching levels of a web application and different caching strategies that can be used in Server Worker based caching implementation. 

Hope you enjoyed playing with the demo application. you can find the full app here. 

https://codesandbox.io/s/sw-cache-visualizer-vw649

If you want to try some of these patterns, you can use the https://developers.google.com/web/tools/workbox library that provides all the features out-of-the-box. 

As an example 

```js
import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';

registerRoute(
  ({url}) => url.pathname.startsWith('/images/avatars/'),
  new StaleWhileRevalidate()
);
```

❤️ Appreciate your feedback and thank you very much for reading.