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

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.

  • 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

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:

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:

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:

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:

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!

Engineering Your Breakthrough

Engineering Your Breakthrough