Website carbon emissions
We all know that the ways we travel, the food we eat, and the ways we power our lives produce different amounts of carbon dioxide. Various websites can estimate your personal CO2 emissions from these sources. In all the discussions though, we often overlook the CO2 emissions due to websites themselves.
Every website sits on a server somewhere. When you visit a webpage you contact that server and ask for the page. Some servers may use databases and code to work out what to send you but, in a basic sense, they all then send you files to display. Sometimes lots of files. And sending all this data relies on a bunch of other computers (routers, DNS servers, switches etc) to forward the files to you. All those computers require powering. That requires electricity and that means a level of carbon emissions. Surely this is quite low, isn't it?
The internet consumes a lot of electricity. 416.2 TWh per year.
Back in 2016 that was already greater than the total electricity consumption from all electricity suppliers in the UK. That isn't great. And it is a growing problem because the size (in bytes) of webpages is growing.
The average website on desktop is about 4 times as large as in 2010.
Data storage could balloon to 8% of planetary energy use by 2030.
Some examples
So far I've talked about the web as a whole. But, if you have a website, what can you do to help reduce CO2 emissions? I was recently reading a great blog post by Danny van Kooten an open source coder who makes plugins for the popular website platform Wordpress. Danny estimated that tidying up the code in his popular Mailchimp plugin (reducing it by 20kB) would reduce global emissions by around 59kg CO2 per month! That was the biggest single impact he could have as an individual and it just meant being cleaner with his code.
If you don't have the estimation powers of Danny, you could just use the Website Carbon Calculator to estimate the emissions from a webpage. It works out what resources a page pulls in and then works out an estimate of the CO2 emissions for one person to see it. It also tells you how much that is if you get 10,000 visitors a month and compares it to more human-friendly things like how many cups of tea it would boil water for. Let's try some examples:
- google.co.uk - 0.35g CO2 - cleaner than 77% of web pages tested
- bbc.co.uk - 2.11g CO2 - dirtier than 78% of web pages tested
- gov.uk - 0.20g CO2 - cleaner than 85% of web pages tested
- leeds.gov.uk - 0.94g CO2 - dirtier than 50% of web pages tested
- bradford.gov.uk - 1.24g CO2 - dirtier than 60% of web pages tested
- york.gov.uk - 1.12g CO2 - dirtier than 57% of web pages tested
- calderdale.gov.uk - 0.73g CO2 - cleaner than 59% of web pages tested
- theodi.org - 1.50g CO2 - dirtier than 64% of web pages tested
- odileeds.org - 0.06g CO2 - cleaner than 94% of web pages tested
Google does fairly well which isn't entirely surprising as they get huge numbers of visitors and want to reduce their bandwidth costs. The BBC is the worst of these examples and that is because they are heavy with images and video as you might expect of a broadcaster. Central government do very well and that is no doubt down to the GDS Style Guide and the Service Design Manual which aim to keep central government websites as clean, performant, and as easy to use as possible. Local Authorities don't do as well and may be down to use of overly large "hero" images that haven't been optimised e.g. Leeds City Council has a variety of background images used behind the header that are a few hundred kilobytes each. ODI HQ has around 2MB of images and 2MB of Javascript/CSS on their homepage including one very uncompressed image that is over 700kB for only 640x420 pixels.
What can you do?
There are a lot of things you can do to keep the size of your webpages down. Whole Grain Digital have lots of examples. They won't always be applicable/appropriate but let's go through some here...
Content
Makethe core content easier for people to find so they get to it more quickly. That means they spend less time failing to navigate to what they actually want.
Images
First ask yourself if an image is necessary. I nearly included a bunch of screenshots from the Website Carbon Calculator in this blog post but decided I could just convey everything in text. Can you use vector graphics (e.g. SVG) instead of photos? If your images are more graphic-y than photo, this could help reduce file size quite a lot. Make sure to minify your SVG if you create it in a tool such as Illustrator. If you have photos, you could try reducing the file size with tools such as TinyPNG or ShortPixel. You could also use responsiveimages - that means having a variety of versions of an image available and use CSS to pick one appropriate for the screen size of the end user. For instance, a mobile user with a narrow screen might get a 600px wide version and someone on a big desktop might get 1920 kB. That also helps reduce bandwidth and speed up page load times for people on mobile.
Video
Videos massively multiply the number of bytes transferred. Ask yourself if you really need to add a video. Does it add much? Clearly sometimes that is the best format but there will be other times where it could be replaced with a paragraph of text or a static image. Don't autoplay videos when they aren't the primary content. Autoplay means data is being transferred whether the user wanted to play the video or not. It is also less annoying for people as they try to work out where the sound is suddenly coming from half-way down a webpage.
Fonts
Web designers like to use custom fonts. Often that might be necessary to match with your brand. But a custom font can add as much as 250kB of page weight so be sparing. Use system fonts if you can; that way no bandwidth is needed. If you do use custom fonts try using fewer font variations. You could also use WOFF/WOFF2 files for fonts which are generally smaller than TTF/OTF.
Code
In general try to write cleaner, shorter HTML, CSS, and Javascript. Content Management Systems can often generate unnecessary or overly nested code.
- use static webpages where you can (a CMS needs database lookups to create the page)
- avoid unnecessary plugins on your CMS e.g. Danny van Kooten saved 59kg CO2
- avoid unnecessary code libraries and frameworks. For instance, you might not need jQuery and that Javascript framework you are using might be costing you.
- reduce Javascript use or use it efficiently (transfer & processing)
- reduce tracking/analytics/advertising scripts - do you really need 583 trackers?
- use Progressive Web App techniques to cache data on the users device.
- gzipping Javascript code can help reduce bandwidth but also needs extra processing at your user's end to unpack it all so may not reduce emissions.
Hosting
If you can use a host with a high Power Usage Efficiency rating - that means they aren't wasting much power as heat in their data centre. Usea data centre closer to your users; don't host your website in Arizona if your users are all based in Leeds. If your target users are all over the world, try using a Content Delivery Network to cache copies of files closer to them.
