Reducing the carbon footprint of your website from a FEDs perspective

“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.‍

Assets

‍According to MDN 51% of a webpage’s bandwidth comes from images. Optimisations here can have a great impact on power usage.

Sizes

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

‍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

‍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

‍Setting meaningful cache headers will avoid re downloading from the server. Static files such as images, CSS files, and JavaScript files can have a more aggressive caching setting. 

Code splitting - JavaScript

Certain websites rely on JavaScript for enhancements. Code splitting is a technique to ensure the user only downloads the JavaScript that is required to run that specific page/route. There are several options available, some require bundle processes such as Webpack but using the promise that the import statement returns can be a great first step.

Code splitting - CSS

‍Splitting the CSS files into bundles that only contain the currently needed styles will also contribute to smaller file sizes that are required per page. A popular approach that will make it easier to split is the use of the BEM naming convention. Creating CSS files per page/route is still a manual process and requires the developer to check whether or not specific components are being used or not on that page/route as there is no native concept of treeshaking for CSS. With JavaScript frameworks like React it becomes possible to easily include specific CSS inside the components code CSS in JS. Because bundlers do have the ability to treeshake JavaScript components, so this automatically means it’s not including unused JS and CSS.

Compression

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.

Image sprites

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.

Default typeface

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.‍

Static websites

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!

Conclusion

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.