On calculating carbon

Reading Time: 2 minutes

I had an interesting conversation today with a couple of colleagues from VisitScotland. They had come across our web estate carbon calculator, and were interested in replicating our approach.

Screenshot of a dashboard showing estimated carbon emissions for 3 websites run by Scottish Enterprise.

I had already indicated in the response to the invitation that I had reservations about how useful this approach is. So it was an interesting chat.

I’ve read quite a few ariticles since creating that data studio dashboard that have made me doubt the wisdom of using pageweight alone as an indicator of carbon intensity.

This is a good explainer on how and why it’s difficult, or impossible, to arrive at an end-to-end figure for the amount of CO2 your website might be responsible for.

The web, and the layer below that – the internet – is a vast machine, and it’s just incredibly hard to estimate the environmental cost of a switch or a router in Delaware that, somehow, gets involved in routing data packets from your server to a client somewhere in South America.

Related links

The answer, I think, is something like this

Acknowledge that, yes, it’s impossible to reliably measure the climate impact of a website when you consider all factors such as:

  • The embodied carbon in client devices, especially phones
  • The embodied carbon in data centre infrastructure
  • Varying carbon intensity of the grid over time
  • The complex infrastructure of the internet

But, as developers and designers, we have control over one thing

And that is the code we deploy to clients.

Yes, page weight alone is not the only factor we need to consider. A 1MB web page composed of HTML, CSS, a few images and a sprinkling of javascript will likely be much less resource-intensive than a 1MB SPA requiring 2 or 3 API calls and some complex javascript on the client to unravel it all.

And we need to understand all of that a lot better.

But, I have concluded that:

  • Focusing on page weight, especially javascript, is unlikely to be bad
  • There will be other benefits from sending less data over the wire: performance and UX improvements
  • It’s imperfect; but it’s something, and it’s something we can do
  • Consider the data like web analytics; look at the trends, not the numbers
Website | + posts

I'm a service designer in Scottish Enterprise's unsurprisingly-named service design team. I've been a content designer, editor, UX designer and giant haystacks developer on the web for (gulp) over 25 years.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.