Service Workers Part 2 {What caching algorithm is fast, when and why?}

This is connected to my previous article about Service Workers.

In the previous article, I shared the basics of SWs and caching mechanisms. In this article, I thought to dig into the caching techniques and their performances. Also, I thought to share some strategies that I applied to make a good cache. This information is shared based on the experience I gained at my workplace.

Yes, you do have many caching options available but I would say caching with SWs is super flexible. But you have to be careful about expiring the cache and cache lookup process.

First of all, let me share "why" and "where" you should apply the Service Worker cache.

• If you want to enable an offline experience for your web application (SW as a proxy).
• If your application has not been properly configured with a packaging tool (Parcel or Webpack || does not assemble all modules into a single file) and the browser needs to download a lot of files while the application is loading.

As you already know (read my previous article), SW uses the browser's cache storage to save files. There you have two options available. They are,

• You can directly save your files in the cache.
• You can categorize the cache storage based on your application file types.

Why and when you should categorize the cache storage?

Let's assume your application has thousands of files to cache. But you haven't split the cache based on the file types. Now, when the application reads a file from the cache storage, it needs to look up all the files up to the relevant file in the cache storage. So, saving all the files in the cache storage directly is not a good idea if you have thousands of files. But if you have a limited number of files to cache, you would directly save them into the cache. At the end of this article, I have put the link to a sample service worker cache program.

How can you clear the service worker cache?

The browser cache storage has been designed in such a way that it is accessible only to Service Workers. Also, the cache doesn't have a TTL value. So, if you want to delete the cache, you have to program it with the serviceworker.js file. You have to have a good understanding of your application files and their usage to derive your own cache deletion scenarios.

For example, in my case, I had to delete the cache for HTML and JSON files in a short time period because there was a possibility to update those files' content without a major application release.

Likewise, you have to come up with scenarios that match your application.

Anyway, you have to delete all the cached files with a major release. To do that you can have a small change to your service worker file. Once you did a change to your service worker file, it recognizes it as a new version and it will be reinstalled automatically. So you can add an event listener to track the "activate" event. Then with that event listener, you can delete the relevant cache collections. It is better to have a separate script file to keep the version number and import that script inside the service worker file using the "importScripts". You can increment the version number before the release using a gulp task or follow a similar approach. At the end of this article, I have put the link to a sample service worker cache program.

Even though you have to program the cache deletion mechanisms, you are allowed to delete the cache manually by right click on the cache.

Besides that, I want to mention the following points about the service worker cache.

• There is a cache memory limit per origin (domain) and you have to consider the memory limits (refer to my previous article for more details).
• I have compared the retrieval speed of the disk cache and the service worker cache. What I have noticed is when network speed is slowing down, the disk cache retrieval speed is also decreasing. But service worker cache does not depend on the network speed because it acts as a proxy between the app and the network.  
• It is possible to cache API GET calls with service workers. But you have to maintain the integrity of the cached API data.
• When you think about the caching algorithms, you have to determine whether the "Cache First" or the "Stale While Revalidate" is the best suit for your application cache. As per my investigations, "Cache First" is faster than "Stale While Revalidate" if you have more files to cache. But if your project is well bundled and you have a single JS file to cache, you better go with the "Stale While Revalidate" algorithm. For more information about cache algorithms, please read my previous post.

Click here to access the sample application source code.