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.
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
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...
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.
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.
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.
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.
- 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
- reduce tracking/analytics/advertising scripts - do you really need 583 trackers?
- use Progressive Web App techniques to cache data on the users device.
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.