The global number of internet and digital services users is growing exponentially. The demand increases faster than network (hardware, infrastructure) efficiency is improving therefore energy consumption to meet this demand is growing rapidly. This directly translates to a Carbon Dioxide (CO2) emission increase. It is estimated that about 2% of global CO2 emissions come from the internet, putting it next to the most polluting countries and industries like global aviation and shipping.
But how can we measure a website's CO2 emissions? There are many factors with different influences on the emissions but the easiest and directly measurable one (which can also be used as a representative of a website efficiency) is the actual website’s size. Taking the amount of data that is needed to fully load a website we can assess how much energy it requires and how much CO2 is being emitted to fulfil this energy demand. The bigger the files the more data is going to be transferred and stored and this means more energy consumption.
WordPress, being the most popular and widely used Content Management System (CMS) with about 40% of all websites using it, has a great impact on these numbers and therefore great potential to reduce the internet's carbon footprint.
There are several, easy to implement general solutions and approaches to use whilst building a sustainable website.
Data-rich visual assets like images and videos are responsible for the majority of total website size so making sure that we optimise these is crucial to significantly reduce its weight.
When using WordPress, it is vital that resizing and compressing files happen 'on the fly’ when someone edits/adds content to WP. The go-to tool for this is Shortpixel AI - it automatically resizes images to appropriate use cases, compresses and converts JPG to WebP if the browser supports this format.
Staying on the ground of the most requested and bandwidth-hungry assets (which images undoubtedly are) there is also widely supported by browsers loading attribute that we can use to further reduce page load size. If correctly implemented, this will allow loading images that are not in the viewport only when the user scrolls near them. Correct implementation would require including height and width attributes on the img tag so the browser knows the size of the image, therefore, can determine its distance from the viewport. It’s also a good practice to include these attributes anyway :)
<img src="image.png" loading="lazy" alt="…" width="200" height="200">
Single font file size can reach as much as hundreds of kb in weight. If we use more than one font on our website, the amount of data related to their size can grow significantly (in some cases, the size of one font file may be bigger than the whole front-end codebase of the website).
The first step to reduce the size is to convert any ttf or otf font files to modern, web-focused formats like woff2. Only this can save us up to 25%.
Going further, we can get rid of unnecessary characters. If the font file contains 2000 characters for many languages and our website needs only a fraction of this, we can strip the font file from any not-needed characters.
Both techniques could save us up to 95% of the initial font file size.
Remember: any changes to the font must comply with the font's EULA.
Using build tools to compress the code is another way to cut down file size which is being used as a production version. It strips the code from comments, unnecessary spaces and lines, therefore, reducing the size of the files. There are many tools available (like webpack or gulp.js to mention the most popular ones).
With the core idea of any CMS being the solution for easy content management (hence the name) and dynamically displaying this content, to mention ‘static’ might sound out of place. But the big issue with all dynamic CMS solutions is that the content is being generated every time the page loads. That is a lot of data to be fetched from servers and many server calls to be made. But luckily there are tools and approaches to take to limit the problem or even completely change the way the website is served.
To prevent every part of the page from being loaded from the scratch every time the user visits it, the easiest and most effective way is to set up page caching. This can be done on two layers: hosting (server) and CMS.
Server-side caching is the most beneficial as it sends the cached files directly to the user without querying the CMS. This saves energy, bandwidth and reduces page load times.
This feature is widely used by WordPress specific hosting providers like WPEngine and Kinsta.
If we implement page caching on the CMS layer, it will still have to generate all the content before serving cached files. But this solution is much easier to implement if our hosting provider doesn’t support server-side caching as we can use the WPRocket or Cloudflare Automatic Platform Optimization for WordPress plugins and also benefit from serving cached static files.
While a wide selection of plugins for WordPress is undoubtedly one of the key factors that built and maintains the platform’s popularity by extending its functionality to meet certain users’ criteria, excessive and uncontrollable use of plugins can have a negative impact on the website performance. Some might push extra scripts they need to the frontend not knowing that this script is already there and effectively doubling the scripts up and having a negative impact on efficiency and sustainability as well as slowing the site down. Even disabled plugins take extra space and might still have some impact on the website so it is strongly recommended to completely uninstall (not only deactivate) unused ones.
A similar, conscious approach applies to the use of ‘all-in-one’ WordPress themes. As much as they might be seen as the easiest solution to apply a non-standard theme to our website and give us flexibility, they are often (because of their universal nature) bloated and consist of features that we don’t need and will never use. But it’s there, in the code and the structure, making the theme and therefore the whole website big and slow.
We hope you have enjoyed this deep dive into improving the digital sustainability of your next WordPress build. If you are keen to learn more about the L+F approach to sustainability on the web, we'd love to hear from you.