Estimating website emissions in the italian context – Sitigreen & CO2.js

In this case study, we explore how the Sitigreen website carbon calculator uses CO2.js to perform website carbon calculations that are specific to Italian users.

This case study was first presented at the 2023 Digital Ethics Forum, on November 23rd, 2023. You can find a PDF copy of the slide deck, and a transcript of the presentation below the video.

Download Slides

Download the slides for this presentation in PDF format:

Transcript

Hi there, I’m Fershad Irani from the Green Web Foundation, and today I’ll be talking about how Sitigreen uses CO2.js to present website carbon calculations in the Italian context.

Just quickly a bit about me, as I mentioned, my name’s Fershad and I work with the Green Web Foundation, where I’m a maintainer of CO2.js amongst some other libraries and other things I do for the foundation. I’m also the creator of a website checking tool myself, it’s called Are My Third Parties Green, and I’ve been known to write the odd web sustainability review of COP websites, which you can find over on my blog.

When I’m away from a laptop or a computer, you’ll normally find me playing, refereeing, coaching, or organising Touch football, which is a faster, more exciting form of rugby, and we play that here in Taiwan, and it’s something that I’m very, very passionate about.

So about this project, this project came about when Nicola contacted me to see whether we could update the Sitigreen website carbon calculator so that it could return results that were more tailored for an Italian audience. I mean, why would we do that in the first place? Sitigreen was working fine before Nicola got in touch. Well, as I mentioned, Sitigreen’s main audience is the Italian market. However, originally it had no way to be customising the results it was showing for that Italian audience.

This is because it lacked context. It didn’t know about the location of the server for the webpage that it was testing. It also didn’t know about the user’s location, and both of these things get fed into website carbon calculations. As a result, Sitigreen was relying on global averages in the calculations it was performing.

And this is important to note, because in the end, all carbon emission calculations look like a version of this. where emissions is the result of energy used multiplied by Grid Intensity. Now grid intensity is a term that’s used to talk about how clean or dirty a electricity grid is, and it’s normally represented in the form of grams of CO2e per kilowatt hour. And it’s important to keep this in mind.

Because, if we were to try to produce website carbon estimates for an Italian market, but use the world average grid intensity, we would be overestimating the CO2 in our results. However, for someone like me, in Taiwan, where our grid is much dirtier than the global average, if I was to use a global average in my carbon calculations, I’d be underestimating my emissions. So it’s really important that we have the ability to customise the grid intensities we’re using in our calculations.

This chart I’m showing here is from Ember Data. You can check out their Data Explorer. There’ll be a link to it later in this presentation. It’s a, it’s a fascinating, fascinating tool to check out.

So, about the project in more detail. What changed and what didn’t? In order to get us to a state where we could customise the grid intensity of the inputs that were going into Sitigreen’s website carbon calculations, we needed to make a combination of code changes and UI changes. To do this, we had to replace the previous API that Sitigreen was using with CO2.js. We needed to provide a way that users could tell us where they were located. We needed to also check the server location. And we did that using the IP to CO2 intensity API that the Green Web Foundation maintains. And then we also, we also decided to add some additional context to those results, just so that it could be clearer to the user what they were seeing.

Now what didn’t change? Sitigreen originally was using the sustainable web design model for its calculations and we did not change that in this update. And Sitigreen was written in PHP. We didn’t change that despite the fact that CO2.js is a JavaScript and Node library.

So, getting a bit further into the details, replacing the previous API with CO2.js. This change was required so that we could adjust the grid intensities when calculating user device emissions and also website, server or hosting emissions. So why CO2.js, besides the fact that I’m the maintainer of it, so I’m a bit biased yet. CO2.js was a drop in replacement for the previous API that Sitigreen was using. Both of those tools use the Sustainable Web Design Model by default, and that’s the model that’s used in a lot of popular website carbon calculators that you’ll find on the internet. As I just mentioned, CO2.js allows for developers to adjust server, network, and device segment grid intensity, which is what we needed to achieve the Italian specific results that Nicola was after. And CO2.js also comes with the grid intensity for 209 countries and 13 regions. These are annual average figures that are sourced from the Ember dataset that I showed previously. And this means that there’s no need for any further outbound API calls if you are wanting to change grid intensity of different segments within CO2.js.

Now, as part of swapping out the previous API, which did a lot of stuff in Sitigreen under the hood, we needed to do some more things ourselves. The first thing being that we needed to now check if a website was being hosted green. We did this… using the Green Web Foundation’s Greencheck API. And we also needed to check how much data was being downloaded when that page first loaded. To do this, we used Google’s PageSpeed Insights API. There are different, a few different ways you can do this nowadays, but Google’s PageSpeed API was the one that we picked because it was just the quickest to get started with.

So with those code changes made, we needed to now figure out how we could get the user’s location. After a bit of back and forth, we decided to go with a really simple implementation which resulted in a UI change to the website calculator form, where the user now has the option to tell us whether they are based in Italy, based in Europe, based somewhere else in the world, or whether they don’t know where they’re based. That unknown value actually just defaults to the global average anyway. This avoided a whole bunch of GDPR and user permissions complications that could have happened if we tried to do this programmatically. And I think it’s quite an elegant solution to this problem. Once the user sets a location for us in the front end and enters a website URL, that information is then passed through to CO2.js to use in the website carbon calculations that it performs.

That helped us achieve our MVP. To take it a step further, we just needed to add a few extra bits of magic on top. The first one being a check of the web server location. Now, a lot of website carbon calculators will check if a website is hosted on a green web host. But, if it’s not, not many of them actually then go and check where the website, where that website is hosted to find out what the grid intensity of that region is. We do that now in Sitigreen.

So, after we’ve checked with the Greencheck API whether a site is hosted green or not um, we see that result and if it’s, if it’s false, We then get the IP address of that website and pass it through to the IP to CO2 intensity API, which the Green Web Foundation also manages to get the location for that server. With that location in hand, we can then pass that information into CO2.js to be used in the website carbon calculations that it carries out.

And finally, we made some further UI changes to the results that Sitigreen presents to anyone who does run a test. Now, the changes we made are to provide some visibility as to the variables and constants that went into the sustainable web design model calculation that CO2.js performed. This is important because it helps to provide transparency to the user and some clarity as to why the results they’re seeing here might differ from other website carbon calculators that they try out.

So, to summarise, in this project, we successfully integrated CO2.js, a JavaScript library into Sitigreen’s WordPress PHP code base. We provided a way for users to include context about their location, uh, in carbon emission estimates. And we also included additional context programmatically about a website server’s location in carbon emission estimates.

And in the end, this helps Nicola, and the team that runs Sitigreen to help raise awareness for the Italian people about the environmental impact of the digital sector.

These slides and this presentation video will be on the Green Web Foundation blog shortly where you’ll be able to find links and resources, links to all the resources I’ve mentioned here, um, and really quickly just a short plug for the foundation. If you or your organisation would like us to do any talks, workshops, training or consulting you can engage us via the website linked on this page greenwebfoundation.org/services.

Thanks. Arrivederci.