How to measure and reduce the carbon footprint of your application

I’m a green software engineer, and the first principle of green software engineering is to build applications that are carbon efficient. That means for each gram of carbon our application is responsible for emitting into the environment, we try to extract the most value from that gram as possible.

So, in this context, the first metric you might think of is carbon. And although we do need to calculate the carbon emissions of our application at some level, it’s particularly hard to measure. There’s no HTTP response header that returns the carbon cost of the request (maybe there should be?), so most of what we do is try to model. When we model, we make assumptions, and those assumptions might impact where we put efforts to optimise.

For example, a common challenge is the carbon intensity of electricity. Electricity is dirty and it emits carbon in its creation – how much carbon it emits is known as carbon intensity. The global average for carbon intensity produced in 2020 was 519g/kWh, but each electricity grid in the world has a different number because each grid has a different mix of clean and dirty electricity sources. It also changes over time, so each minute in each region has a different carbon intensity. Which of these numbers is the right one to use when calculating your carbon metric?

If you choose a global yearly average and try to save carbon by running your application in a region with cleaner electricity, that change won’t be reflected in your carbon metric.

If you decide to include real-time regional carbon intensity numbers in your calculation, then imagine this scenario; You release a code change and your carbon metric goes up. Did your code change make the application worse or has the electricity become dirtier? In this scenario, the real-time carbon metric is a problem as it’s causing false positives.

At the same time, perhaps you released a code change that shifted workloads to times and regions when the electricity was cleaner. If this was the case, then you’d want your carbon metric to use real-time regional carbon intensity numbers to tell you your code change had a positive impact.

It’s good to attempt to model and think of the overall carbon number of your application, but be aware of how that number is being calculated and what assumptions are being made.

Look for carbon proxies

An easier solution is to look for carbon proxies. If you can somehow connect what you are measuring to carbon, then it’s a proxy. And optimising for that metric is optimising for carbon.

For example, let’s take a look at electricity. We burn fossil fuels to make electricity, meaning there is a connection between electricity and carbon. This makes electricity a carbon proxy. Therefore, reducing the energy consumed by your application reduces the amount of carbon it’s responsible for emitting.

How to choose carbon proxy metrics

The metrics you choose will open the doors to optimisations as if you measure something, you will usually aim to optimise it, so picking the right measurement criteria is key.

Our goal as green software engineers is not to write reports, it’s to implement change. We need information to know what these changes should be. When picking a carbon proxy, be less concerned about how accurately you can measure it, and more concerned about the directional information the proxy gives you. It’s OK if your units are off, and it’s OK if it’s not accurate. As long as the metric behaves in a way that gives us the right information to make the right choices, it’s good enough.

What you choose to measure will impact what you will optimise, and because of the assumptions that need to be made when summarising, multiple metrics are better than one.

Some metrics are easier to measure than others: pick what’s manageable at the start, add others as you refine your green software engineering methodology.

What carbon proxy metrics should you choose for a website?

Let’s take a look at what metrics a website might need. We’ll pick a reference architecture of a basic multi-page application (i.e. most websites). Every time a user clicks a link, the browser makes a request to the server, the server generates some HTML and returns it in the response which the browser then renders on the client machine.

We have a frontend running on a client machine, some networking, and a backend running on some servers. We assume the application is not a bitcoin miner or a game – essentially once parsed and loaded in the browser, the application is not running constantly and taking up CPU.

So, what are some good carbon proxy metrics we might choose to measure for this application?

Frontend

For the frontend, the ideal carbon proxy would be the total energy used to render the webpage. There are tools to measure this, however, pulling that all together into an automated measurement system is not easy. Another carbon proxy we can then use is time-to-interactive. This is the time it takes from the response being made to the page being rendered and usable on the client device. We’ll make the assumption here that the energy used is proportional to the time, though this might not always be the case.

A lower time-to-interactive implies an application that:

• Consumes less electricity – and electricity is a carbon proxy (see the second principle of green software engineering).
• Has more efficient code. The more efficient the code, the better the application will perform on older hardware. The more we can make our applications work well on older hardware, the less pressure we put on society to throw away perfectly good devices just to buy newer, faster machines to meet the demands of the latest software. Hardware releases carbon in its creation so hardware is a carbon proxy. This speaks to the fourth principle of green sustainable software engineering: embodied carbon.

We can connect time-to-interactive to carbon through two other carbon proxies (electricity and hardware), so time-to-interactive is also a carbon proxy.

Networking

What is the carbon cost of networking? It’s difficult to measure and there are competing models, but suffice it to say, two things are true.

1. The larger the size of data you are transmitting, the more energy and compute it requires to transmit. Therefore, data size is a carbon proxy.

A good metric to choose here for websites is page weight – the overall size of all the assets in your website. Page weight is a carbon proxy.

2. The more distance the data has to travel, the more compute and energy is needed. Therefore, the distance that data has to travel is also a carbon proxy.

The distance is a difficult one to factor in since it depends on where your users are located and the location(s) your requests are being served from. Are your users globally distributed? Are they mostly in the UK? It’s possible to measure, but as you can imagine, measuring accurately is not going to be simple. You really want the average distance that each MB of your data had to travel across the network to reach its end customer.

This is one of the cases where we can spend a lot of time figuring out the most accurate value when what we need might just be directional information. Average Server Response Time is something that analytics tools can measure; they define it as ‘the time for your server to respond to a user request, including the network time from the user’s location to your server’. It’s fair to assume that the less distance the data has to travel to the user, the faster the server might respond with the data. Average Server Response Time can therefore be a carbon proxy and something we can measure in our application.