Service Workers can save the environment!

Service workers allow you to cache resources on the user's device when they visit your site for the first time. Fewer HTTP requests mean less CPU usage and less energy consumed.

Service Workers can save the environment!

Woah! The title of this article might seem like clickbait - but bear with me. Using service workers can actually reduce the amount of energy that users that visit your website consume. I may have lured you in with the false pretence of saving the environment….but now that you are here, read on and hopefully I can at least convince you that service workers can make a (little bit) difference to energy consumption!

As data centers and volumes of servers have grown, so has the overall amount of electricity consumed around the world. Electricity used by servers doubled between 2000 and 2005 (and has continued growing ever since) from 12 billion to 23 billion kilowatt hours. It’s crazy to believe it, but analysts have forecasted that if the current trend is not abated, then the power required to run servers will be equal to or greater than the server cost.

So where do service workers fit in?

Let’s take a step back and start with the basics. When a user navigates to a URL using their browser, they make a number of HTTP requests in order to retrieve the resources necessary to display the web page. The diagram below gives you an idea of this in action.

HTTP Caching - Service Workers energy consumption

Once the initial request for the HTML page is made, the browser scans through the HTML and finds any resources that it needs to render the page. Each HTTP request that is required for the page needs to travel over the network and in turn this consumes energy on both the server and client. While this may not seem significant for websites with low traffic, as traffic to the site begins to increase, so does the amount of energy consumed.

Without effective caching on the client, the server will see an increase in workload, more CPU usage and ultimately increased latency for the end user. Unfortunately, this also means that the more the CPU usage correlates to power consumption.

CPU Utilization and power consumption - service workers
CPU Utilization and Power Consumption (Source: Blackburn 2008)

As you can see from the graph above, the harder a server needs to work, the more energy it needs to consume, which is why it makes sense to reduce the CPU usage on the server. As you can imagine, increased workload on the server also has other side effects such as increased heat generation. Unfortunately, that’s not where it ends. Server power consumption extends to the power supplies, memory, disk, fan and even motherboard.

Server power consumption - service workers
Server Power Consumption (Source: Intel Labs 2008)

Processors and memory consume the most power on the server, followed by the power supply efficiency loss.

This is where service workers can make a difference. They allow you to cache resources on the user's device when they visit your site for the first time. This means that the next time that they return to your site, they already have resources that they need cached locally on their device and they don’t need to make the current HTTP request. Fewer HTTP requests mean less CPU usage and less energy consumed. Let’s refer to the diagram that we looked at previously, but this time with service worker caching in place.

Caching with service workers

With service worker caching in place, the resources that we need to load the page are cached on the device, which means that we don’t need to go over the network to retrieve it. This is a much better result and saves load on the server, reduces bandwidth and ultimately makes your web page load even faster. It’s a win-win all round!

You might be wondering about traditional HTTP caching and how service worker cache differs from this. HTTP caching stills plays an important role in reducing the bandwidth consumed by your users, but it isn’t without its limitations. Jake Archibald has written a great article on this. Traditional HTTP caching can be tricky and you aren’t always guaranteed that you will receive a cache hit. This is where service worker caching differs; the HTTP request is intercepted by the service worker and if the resource exists in cache the HTTP request is never made. In this article, I’ve focussed on service worker caching, but other forms of caching can help performance and CPU usage too!

Show me the money!

Okay, so this all sounds like a wonderful theory, but I want to see some real data. To start with, I wanted to determine how many users that visited my website actually had service workers installed that were actively controlling the page. In order to track this information, I used Google Analytics and pushed this data through as an event. I already had Google Analytics installed, so I added the following code to each page.

function getServiceWorkerStatus() {
  if ('serviceWorker' in navigator) {
    return navigator.serviceWorker.controller ? 'controlled' : 'supported';
  } else {
    return 'unsupported';
gtag('event', 'service-worker-support', {
      'event_category' : 'service-worker-support',
      'event_label' : getServiceWorkerStatus()

Using Google Analytics, I was able to determine the support for service workers across my site. In the image below, the blue (68.8%) represents all visits to the site that support service workers. The green (23.3%) represents of all visits to my site were controlled by a service worker and served cached data. Finally, the orange shows that around 8% of all visits to my site were from browsers that don’t support service workers.

Service worker support for this blog

With this in mind, here are some stats for my site for the month of March 2018:

  • 30,000 users visited this site
  • 93% of all visits supported service workers
  • 24% of those were controlled by a service worker
  • The average web page on my site makes about 13 HTTP requests

With service workers in place, any subsequent visits save a minimum of 7 HTTP requests per page. With some very rough calculations of my monthly traffic:

  • Without service worker caching, I should expect about 400,000 HTTP requests to my server
  • With service worker caching in place, and taking into account service worker support, I saved around 90,000 HTTP requests to my site. That’s around 23% of all requests!

This doesn’t even take into account the amount of bandwidth saved for my users. These stats are for a little blog site with a small amount of traffic - imagine if every website with high traffic was able to do this, it would make a significant difference in CPU usage and energy consumption around the world! As browser support for service workers continues to grow - so should these savings.


When we build websites, a lot of focus is placed on web performance (and rightly so!), but it’s great to know that these performance improvements actually bring beneficial side effects with them too. While a lot of my calculations in this article have been pretty rough, hopefully I’ve managed to convince you that service worker caching can really make a difference to the load on the server and in turn reduce the amount of energy consumed. While this isn’t an exact science, using caching correctly can make a tiny difference that can in turn make a big difference to energy consumption. Service workers really could be good for the environment!

Whilst researching for this article, I came across some useful papers that are worth sharing.