The sense of Cache Strategies

Hey, you’ve probably already heard about Service Workers. Sure thing — you’ve heard. That is such a useful proxy between your web app and the network that has access to the cache storage, and not only.
I think every site should have a Service Worker and in this article, I’ll explain the main benefits of using it together with Cache API.

This article is written by Vitalii Manchenko

Why should I read further?

Do you know that without much work you can speed up your website a few times?
The understanding of how to combine cache and network requests will make the native-like experience for the end-user.

Before We start

• The code below will be used from Workbox to avoid boilerplate, which is common for Service Workers when you write it natively.
• Workbox is a collection of JavaScript libraries for Progressive Web Apps. This is a great tool created by Google developers and other contributors, that helps to build a production-ready Service Worker for you.
• I’ll also represent these strategies as recipes to make the explanation simpler.

What is Service Worker?

I know, there are tons of information about it. I won’t go into details, it’s boring. Instead, I’ll show you a picture that allowed me to realize the main sense of Service Workers:

If you know what is Proxy, then you know, what Service Worker is. Service Worker is a middle layer between your app (even in multiple tabs) and the Network, that has access to the Cache.

5 Main Cache Strategies

1.Stale-While-Revalidate

Perhaps, this is the most popular and rough way to have a quick response to UI and make a parallel request to the server for updating the cache.

This pattern allows you to respond to the request as quickly as possible, with a cached response if available, falling back to the network request, if it’s not cached. The network request is then used to update the cache.

Useful cases:

• Styles
• Scripts
• Workers

This helps developers balance between immediacy — loading cached content right away — and freshness — ensuring updates to the cached content are used in the future.

The code might look next way:

2. Network First

For frequently updated resources.
It’s preferable to serve the fresh content. However, if the network is unstable or fails, it’s acceptable to serve slightly old content.

Useful cases:

• News feed timeline
• Order statuses
• API GET requests

Code example:

3. Network Only

For important resources, such as admin pages.
This one is best suited for logs or anything we don’t have to make available offline.

Useful cases:

• Admin pages
• Payments and checkouts
• Balance statements

In this case, the code will be the following:

4. Cache First

For less active assets, such as fonts and static images.
The content is non-critical and can be served from the cache for performance gains, but the Service Worker should occasionally check for updates.

Useful cases:

• Fonts
• App shells
• Common resources

With this approach, the code looks like this:

5. Cache Only

This is a very uncommon strategy. Can be more helpful for building your own cache strategy or for static landings, which will be re-registered in 24h automatically, anyway.

Useful cases:

• Landing pages
• Visit cards
• App shell

This one will work with the next code:

Summary

Those are only basic cases, but they are enough to make your app native-like.
Just combining these strategies based on your app’s aims, you’ll get a production-ready Service Worker.

Good luck and make your users happy! :)

Thanks for reading. Stay tuned for what’s new!