Don’t go back and forth: using service workers to reduce your website’s footprint

When you visit a web page, your browser will ask the server to send the data it needs to build that page. The browser will then build the page with the received data, but maybe not completely from scratch. If you have visited that page before, the browser might have some parts of the page saved (or cached) on your computer. It will, however, always ask the server for some of the data.

What if we could tell the browser not to contact the server if the content has not changed? Well, we can: enter service workers. And they can even do much more than that.

What are service workers?

Server to computer and vica versa

Service workers are small pieces of JavaScript that run on your visitor’s device. They run separately from the clients – all instances of your web page either as tabs inside your browser or a PWA.

They act like a sort of proxy (or intermediate) between the internet and the web pages they serve. They allow for a fine-grained control of the exchanged data.

What can service workers do?

Service workers can have a wide variety of applications. They can be used to better control the way both internal and external requests are cached, but they allow to make an entire website available offline.

More advanced usages of service workers include:

  • Queuing requests while offline: remembering what you asked the browser to do and executing it when you are back online
  • Synchronising data in the background: for example, update your web page with new data available on the server
  • Receiving and displaying push notifications

And of course, they can help you reduce your site’s footprint.

How can I use them to reduce my footprint?

The general idea of service workers is to

  1. consume as little data as possible
  2. use as little power as possible while displaying your web page.

1. Less is more

It’s always important to keep the amount of ‘useless’ data that goes over the wire at the minimum. Combined with proper use of HTTP Caching, service workers can leverage all sorts of caching strategies to make sure requests are only made when they are strictly necessary.

Service workers are assigned some caching space (or memory) on the visitor’s device where they can store data. Mostly, it comes down to caching.

Some requests (like static assets) are never supposed to change, so they can be stored indefinitely. They don’t need to be downloaded from the server each time. Other data, like continuously changing stock prices, has to be updated often. Some requests could also fall back to a cached version when the initial request either fails or times out.

A nice strategy I like to use for non-critical data, is called stale-while-revalidate. This is perfect for data that has to be served swiftly, but needs to update in the end. With this strategy, a cached version of the response is sent to the client, while the service worker fetches the updated version in the background.

Want to learn more about caching? In The Offline Cookbook, Jake Archibald beautifully explains the different kinds of caching strategies and when to use them.

2. Decrease power consumption

There are two main ways to reduce the amount of power your website consumes on your visitor’s device using service workers.

Less network traffic

Like I said before, the best data is the data you don’t have to send over the network. You could, for instance, reduce the quality of images being loaded on the page, if you detect the user is having a slow internet connection. This can be checked for on the fly, based on the Network Information API.

Chrome and Opera also support a data-saving mode. This can be checked for inside of a header, as well as using the Network Information API.

Optimising content and the way it’s delivered is a topic on its own, be sure to read up on that as well.

Decrease resource usage

Do you really need that JavaScript library to animate every bit of content as soon as it scrolls into your viewport? Every line of JavaScript code has to be parsed, then evaluated by the browser. Depending on how hard this relies on changes to the DOM, this might get ugly pretty fast.

With the Battery API, you could even check for low battery levels and chose not to include some non-critical scripts or stylesheets. Always aim for progressive enhancement and graceful degradation.

So that’s about it as an introduction. If you haven’t heard about service workers, now is a good time to read up on them. Google Developers has a great introduction on the topic.

This page is loaded in about 30 kb.