Have you ever thought about the resource cost of running your website? How each and every request made on the site is received, processed, and stored somewhere.
As part of our mission to make the digital cleaner and more resource-conscious, we’ve written this series of posts to act as a guide for designers, developers, and creators, and help them to reduce the carbon footprint of their work. The guide includes minor changes such as resizing images, to full workflow reworks for static site generation.
An obvious (and often correct) assumption is that a smaller website will use less energy, and thus produce less waste. This is because there are fewer assets that need to be distributed across the web. In our first blog post: Calculating A Website's Energy Consumption, we discussed the impact of data transfers on energy consumption. In this post, we will take a closer look at the role size plays, why it matters, and how you can handle and improve it with specific action points.
As mentioned, limiting the number of files and their size can have a beneficial impact on the energy efficiency of your website. However, that being said, not all assets are created equal, and more often than not they will have different characteristics when it comes to being transferred and placed on your site. For instance, in comparison to a 1MB image, 1MB of code is actually sent faster, but the image is parsed1 more quickly than the code. This is because code needs to be processed, parsed, and executed.
To improve on this, other than being mindful of the code you write and the files/ images you include, is to look at minifying1 the code itself. This is a process of compressing code from the original size to the smallest size possible without affecting its operation functionality. This can be done via different open-source/online tools. Code minification isn’t only good from a sustainable standpoint, but also reduces the load time and bandwidth usage of websites.
Image and video processing.
Typically, a website would load an image at the highest resolution to ensure the best quality for the end-user. However, with exact loading, a website will instead first check how big the user’s viewport is (i.e. their screen), before loading the image to almost the exact size of the space. This loading technique won’t have an impact on the perceived image quality, as what is displayed is just perfect, but it will result in a smaller footprint as the ultimate file size is smaller. The same can also apply to videos.
If you’re unsure where to start with exact sizing, you can begin by checking if your CMS allows for responsive asset queries to help you select the right image size for different dimensions. At Wonderland we use the responsive asset query enabled by DatoCMS and Imgix.
Our machines have a wide variety of fonts installed, such as Arial and Comic Sans. These are the system fonts. For aesthetic reasons, we don’t always use the system fonts that we know everyone has on their devices when designing a website. However, by using external fonts we are also adding additional requests to the servers running a website, requiring further storage space and energy expenditure.
Where possible, try to work with system fonts, and if you need a custom font for certain design elements (e.g. your logo), consider only doing this with the required letters instead, rather than the entire font.
Load only what’s needed, when it’s necessary
Most websites will pre-load images, code, and other assets before users reach them; this is unnecessary. Instead, we work with Lazy Loading. In doing this, a website - or more accurately, the code - is able to check what's visible on the screen and load only the elements required, as a user reaches them. This reduces bandwidth usage and results in both faster initial page speed, and reduced environmental costs.
The same goes for videos, this is a very beneficial approach when a user just wants to scroll to a website and scan the content, instead of viewing each and every section in detail. On the Wonderland website, we integrated lazy loading for videos, meaning that instead of loading a full video, we have a function that checks if the video is in view for more than 3 seconds. After those three seconds have elapsed, the video will fully load and play. Just by implementing this one feature, we have been able to decrease bytes transferred by our site by more than 50%! Granted, we’ve also had to compromise on the visual aesthetic of our videos on first load, but that small price makes a big difference towards our sites energy consumption.
Aside from visual assets, code can also be loaded when it’s needed. When using Nuxtjs, a static site generator, you can split the code for different pages so that the scripts belonging to a specific page will only be loaded when visited. You can read more about this here.
We hope that you find this article has been useful and thought-provoking when it comes to reducing the carbon footprint of your website. If you’d like more tips, have a look at our two other posts in this series, exploring Tracking Tech and Managing and Monitoring Power Consumption.
If you’ve been following our journey, you’ll know by now that we’re just at the beginning of our Sustainable Digital Design journey. Keep checking back regularly as we share more of our discoveries and creative solutions for sustainable digital design and development techniques.