Web Carbon Metrics

The more papers I read about the energy consumption of the ICT industry, the less I trust website carbon footprint calculators. They are inaccurate at best, fraudulent at worst.

The carbon emission of a website can be estimated from the amount of data transferred to load it, but it’s only a part of the bigger picture. We identify in fact four main emission sources– infrastructure (cooling, power, etc.), storage, transport, and processing–with varying importance depending on what kind of web application we talk about. For example, the carbon emission from the transport layer is non-negligible in a real-time collaborative editor like Google Docs (each keystroke being monitored), while it’s not the case for most static websites.

An objective metric needs to take into account many parameters that aren’t forcibly easy to obtain. Fortunately, we can agree on a set of principles:

1. The app needs to perform fewer requests.
2. Requests must have smaller payloads.
3. Request endpoints need to be as close to the client application as possible.
4. Software programs must be efficient.
5. Stored data must be cleaned and compressed as frequently as possible.
6. Servers and third-party tools need to run on renewable energy.

These six principles cover most actions web developers can take to minimize their software footprint. Just like recycling at home, it’s not because we cannot quantify the result that the benefits do not exist: it’s simply common sense. We need to do our best, and it’s dangerous to follow inaccurate metrics telling us it’s ok to rest on our laurels once we reach a certain point. Total continuous improvement is the only way forward.