In this case study we will look at image compression. Typically when trying to optimize a website for network resource consumption and thus CO2 emission images are the lowest hanging fruit.
Modern image formats like AVIF typically achieve +50% compression ratio when compared to PNG in a similar perceived quality.
Try out on Squoosh.app for yourself to see the potential!
AVIF received many positive blogposts. However modern image formats like AVIF have a downside: They are not supported in older browsers like IE, Safari or old Chrome devices. Check support on CanIUse.com.
If you still want to support these old browsers, so that they do not see a blank image you typically would use a polyfill.
In this detailed article we will look at the potential backlash when using polyfills and how to watch out for the tipping points when a move to AVIF might actually get worse in terms of carbon emissions, although it might make no difference in performance for the users.
First we need to calcuate some statistical data from Google Analytics or whatever product you are using.
The following list outlines the questions and also the answers for the sample site that we are looking at:
Our sample site has 1.000 Users per day.
This is a representative distribution for Germany from one of our clients for a non-ecommerce site in 2022.
2 images per site on average
Our images are on average 50kB
Users visit for 2.7 pages / visit
First we calculate the savings in form of kB / MB we get when using the AVIF format:
Since every network transmission has an energy and CO2 budget attached to it we no use our formulas from TODO:_ CO2 formulas for software engineering and then we plug in to calculate the savings per day. We also use the avg. grid intensity in Germany for today (280g / kWh).
We now know, that we could save a potential 2.268 gCO2e per day for our 1.000 users if we were to move to AVIF. However what we have not considered yet is the users of the IE 6-11,Safari, Edge and Chrome < 85 browsers which do not support AVIF format out of the box.
The typical fix for this is to include a polyfill. A choice we have personally used in the past is this library: Kagami avif.js, which itself relies on an npm package: dav1d.js
The total size of this polyfill is ~300 kB
In some cases it can be tricky to detect the correct browser and delivering the polyfill only to exactly them. Therefore for reduced complexity the polyfills are always delivered no matter if needed or not.
However in this case we believe separating the browsers out through some capability check or the user agent header should work just fine.
So we assume that the polyfill is only delivered for our 30% non-supporting Browsers
We get the total number by just subtracting the 135 MB with the 90 MB to a total of 45 MB.
In this example moving to AVIF even with the needed polyfill is still worth regarding the carbon emissions. However the margin got quite diminished and if the users are visiting less pages or the browser ratio is different this might also easily reverse and become a rebound effect.
If you look at this example I hope we could convey that if you optimize for lesser CO2 emissions the backlash to consider are often different when optimizing just for performance, where a mere 300 kB polyfill will most likely go unnoticed.
When looking at our example one might also argue, that instead of including the polyfill we could also use a switch that would redirect to a different HTML page which includes only PNG images, or to use an image service, that only delivers the correct image based on detected browser capabilities.
All of these approaches have different problems and backlashes though, since they typically mean that you save on network bandwith, but therefore have to increase the storage, which is also powered by energy and thus emits CO2.
In a follow-up article we will further drill-down into the cost of storage in particular and how replicating your data manyfold to different CDNs also has a CO2 cost that has to be factored in.