Improving the homepage environmental footprint
Contextπ
I've talked about the environmental impact of digital in previous blog posts. When the issue is intertwined and complex, there are some actions that will significantly reduce the impact, such as reducing manufacturing, especially of the terminals. When developing software, you can contribute to this reduction by avoiding technical obsolescence. This also applies to simple websites. So let's work on the current website.
When I redesigned it at the beginning of the year, I tried to keep it as light as possible by using a minimal CSS framework (awsm.css) and as little javascript as possible1. I also decided to use a static generated website (Zola), so that the end result, i.e. all pages, are only calculated once. However, I can't say how good it is in terms of footprint. If I want to improve it, I need to be able to measure that footprint and evaluate whether it is worth the effort. It may already be good enough.
The toolsπ
To measure, we'll use existing tools. Their purpose is to estimate the footprint of a given web page. We'll use 3: EcoIndex, WebsiteCarbon, and EcoGrader.
EcoIndex scores your website using a model2 that estimates the energy used by the server, network, and client to serve your website. The model consists of a weighted sum of each. It uses a proxy to estimate the energy consumed for each: the HTTP requests for the server, the bandwidth used for the network, and the resulting DOM for the client. The score is then converted into greenhouse gas and blue water equivalents. It is developed by the French collective "Conception numΓ©rique responsable".
WebsiteCarbon scores your website by estimating the energy consumed from the bandwidth used to transmit the website. The model takes into account the energy intensity of the web data, the energy source used by the data server serving the data, the resulting carbon intensity, the annual Internet end-user traffic, and the annual Internet energy. The result is then expressed in terms of greenhouse gases. The model3 was developed by Chris Adams (The Green Web Foundation), Rym Baouendi(Medina Works), Tim Frick (Mightybytes), Dryden Williams (EcoPing), and Tom Greenwood (Wholegrain Digital). The calculator was developed by Wholegrain Digital.
Ecograder uses the same methodology3 as WebsiteCarbon to estimate greenhouse gas impact. It breaks down the size of a web page into images, scripts, HTML/CSS, and others. By using some tools such Google Lighthouse, it then recommends actions to improve the website. It also rates the UX design including accessibility. It is developed by Mightybytes.
The starting pointπ
The first time I use the 3 tools on the homepage, I got the following results
- EcoIndex: B grade4 (too heavy 2.796MB, simple 91 DOM elements, few requests 13)
- WebsiteCarbon: dirtier than 55%
- Ecograder: 79%5 (page weight 90%, UX design 73%, GreenHosting 100%, carbon score 60%)
The budgetπ
Is it worth the effort? Looking at the stats, I can count about 500 visits to the landing page since the beginning of the year. According to EcoIndex, this results in ~700gCO2e and ~10.5l (blue water). For EcoGrader and WebsiteCarbon it is about 425gCO2e.
Considering the maximum consumption of my laptop (90W) and the average annual carbon intensity of the Belgian grid (~150gCO2e/kWh6), this corresponds to about 31 hours of work (=425/150\*1000/90
). Depending on the improvement made and the traffic, it might be worth it. Another way to look at it is that each hour of work equals 13.5gCO2e, i.e. the cost of 10 to 16 visits. This seems to be worth the effort.
The changesπ
Most of the size of the site comes from 3 assets:
- the 2 images, and
- the script that contains the index of all blog posts, which is used to search the site.
Let's start with the image. In total they weigh about 1MB. By checking their respective sizes, it seems that they're too big (200x200 is enough), also they're not well compressed. So I do the following:
- reduce their size with ImageMagick7:
convert <picture> -resize 200x200 <picture>
, - optimize them with OptiPNG8:
optipng <picture>
, - compress it with pngquant9:
pngquant -- <picture>
.
This results in a total size of 50kB, not bad.
For the search index, it is only worth loading when you do a search. My idea is to load it only when we need it, i.e. when we type in the search text field. That way it's a little less than 2MB that I can avoid.
//Credit to https://zola.discourse.group/t/search-improvement/344/20
function delayedInitSearch() {
function loadScript(url, callback) {
var body = document.body
var script = document.createElement('script')
script.type = 'text/javascript'
script.src = url
script.onreadystatechange = callback
script.onload = callback
body.appendChild(script)
}
document.getElementById("search").addEventListener("input", function() {
loadScript("/search_index.en.js", initSearch)
}, {once: true})
}
The final resultπ
Let's go through the tools again:
- EcoIndex: Grade A10, i.e. 600gCO2e for 500 visits
- WebsiteCarbon: cleaner than 98%
- Ecograder: 98%11, 15gCO2e for 500 visits
It took me 2 hours of work, including research, so 27gCO2. Hopefully I'll have another 500 visits π. According to the tools, I'll save between 100gCO2e and 400gCO2e. It seems to be worth the effort.
The modelsπ
As we can see, WebsiteCarbon and EcoGrader give us similar footprints because they use the same model. The EcoGrader includes further measurements and analysis to refine the report and provide recommendations. The scores obtained by both are much lower than those obtained by EcoIndex. This is due to the approach. WebsiteCarbon and EcoGrader assume that data transfer alone is a good proxy for estimating energy consumption. The EcoIndex also takes into account the complexity of the page and the number of requests. For the EcoIndex, the size of the home page has the greatest impact on the energy consumption of the network. This energy consumption is three times less important than that caused by the DOM on the client terminal.
There are models that do not measure exactly, but give a good estimate. However, it is important to understand the underlying assumptions in order to interpret the results. I also think it's good to use different models to avoid having only one perspective.
I also find it interesting that the EcoIndex estimates a different footprint than green house gas. I wish we could have others because it is not the only environmental concern.
Conclusion.π
These tools (and the models behind them) allow us to estimate the footprint caused by visiting the home page. It does not directly cover the manufacturing footprint, but it could help to keep some terminal models relevant for longer.
It is also a simple web page. For a web or mobile application, or any other kind of software, the question will be more complex, even if the considerations remain the same.
I'll probably try the same exercise for such a case. Let me know if you have one in mind that you'd like me to study.
Footnotes:
Beyond the privacy concerns, I also picked GoatCounter for its relatively small javascript size (10kB against 100kB for gtag.js).
More details can be found in French on the EcoIndex website, this article developing more the asumptions behind the model, or its implementation.
The last version 3 has been published on April 2022 on the website Sustainable Web Design.
The corresponding EcoIndex report. This report might be removed by EcoIndex.
The corresponding EcoGrader report This might be removed by EcoGrader.
This can be found thanks to Electricity Maps.
The doc of the resize
command.
OptiPNG recompresses image files to a smaller size without losing any information.
pngquant is a lossy compression tool of PNG images.
The corresponding EcoIndex report. This report might be removed by EcoIndex.
The corresponding EcoGrader report This might be removed by EcoGrader. Note that I have also improved the accessibility a bit by adding proper alternative text to the image and adding an accessibility label to the search text field (spotted thanks to the toole WAVE).
If you have any comment, question, or feedback, please share them with me.