Reducing the carbon footprint of your website from a FEDs perspective
Websites are becoming more sophisticated. Bigger infrastructures, more storage ability, and faster delivery methods often equal more electricity consumption, and a bigger carbon footprint. We’ve been researching ways to cut down a website’s carbon emissions.
“Between 2011 and 2019, the median resource weight increased from ~100KB to ~400KB for desktop and ~50KB to ~350KB for mobile. While image size has increased from ~250KB to ~900KB on desktop and ~100KB to ~850KB on mobile.” [source MDN]
As front-end developers, we can address a website’s carbon footprint and also follow best practises for building fast and responsive websites. For example, to create an efficient website we look to load the bare minimum and use techniques to enhance the content based on user interaction. These practises result in less data being sent, which will also have a positive impact on a website’s carbon footprint.
Below we’ve highlighted a few approaches to reducing a website’s carbon footprint. There’s no ‘one size fits all’ solution, and it’s important to note that each approach has pros and cons in certain situations.
According to MDN 51% of a webpage’s bandwidth comes from images. Optimisations here can have a great impact on power usage.
Serving the correct image sizes based on screen size is a great optimisation. Not only will it positively impact the energy consumption level, it will also increase the user experience as they experience faster loading times. HTML offers great native solutions to load the correct image per screen size. The combination of the srcset and sizes attribute on the <img> tag ensures the correct image file is loaded for the correct screen size. This approach will ensure that we load tailored fit data to the client, saving unnecessary file requests. MDN has written a great article on how to execute such an approach.
Lazy loading helps to shorten the Critical Rendering Path length. Only data that is critical for the initial render will be loaded, saving bandwidth until a user requests these resources, via scrolling or other ways of navigating on the page. The overall loading energy footprint is now customised to the user’s needs! Many modern browsers now natively support the loading=lazy attribute.
Service workers in combination with CacheStorage let you control whether to fetch assets from the server or from the browser cache. This technique can be used to make certain websites available offline.
HTTP cache headers
Code splitting - CSS
Less compression equals larger file sizes. Some file types like PNG offer very high image quality, but with the downside of larger file sizes. Picking the right compression for your images, which could be a case by case decision, will result in faster page loads and less power consumption. There are also new formats to familiarise yourself with, e.g. Google Chrome recently announced that it will support AVIF.
A lot of games use the concept of sprite sheets. This is a collection of different images, all saved as one big image. This way a user only needs to download the spritesheet, which is made out of all the different images a game might need. The use of image sprites is therefore a great way to minimize HTTP requests. As with all solutions, correct usage is key. When creating image sprites, ensure that the images included are actually used. Otherwise the user will load data it will never see.
The website does not need to declare a custom font-family at all. This not only avoids having to load the font assets. Only one weight (regular) of a font needs to be used, demonstrating that typographic hierarchy that can be established without loading multiple typefaces and weights. By not declaring a font-family the user’s font settings or user’s system fonts will be used.
Most of today’s websites use server side programming languages that generate the website on the fly by querying a database. On the other hand, a static website is generated once and exists as a simple set of documents on the server’s hard disc. Static websites typically require less processing power and thus less energy.
No third-party tracking
This article won’t go into detail about privacy concerns when tracking, but we did want to briefly mention it. Besides this concern, client-side tracking generates extra requests that don’t benefit the current user experience. Depending on the requirements of the analytics, it is possible to achieve similar outcomes with server side tracking. This user will benefit from the fact it needs to do extra server requests because this data is already created on the server!
In the use-case where client tracking is required, consider researching whether the tracking service claims to be carbon neutral, and ask for greater transparency about the carbon footprint of their service.
No advertising services
Advertising is a surplus of unrequested data, the user landed on the webpage because of its content, not its external links. Not only does it require extra HTTP requests, it’s also highly likely that the ad contains images. Which we now know, are responsible for more than 50% of page traffic!
The great thing about the process that we’ve outlined above is that it doesn't only benefit the carbon footprint of your application. All these steps are also part of best practises in order to create performant websites. It will result in a better user experience as users don’t have to load unnecessary data.