Digital sustainability: how can technical choices improve the sustainability of websites?

And one other thing, rather than create prescriptive step-by-step instructions, we wanted to discuss best practices based on tried and tested methods. Because we’re all still learning. In making this series, we hope to spur a continuum of content from across the sector on this topic.

Strip themes back

For the Climate Group’s needs, Drupal won out as the best-suited content management system (CMS). With Version 9 having recently landed, Drupal is also one of the most up-to-date CMS choices on the list.

To build sustainable foundations for the charity’s web estate, Manifesto sought out the most stripped back theme, which was ‘stable9’. This theme contains minimal markup – that is, the software instructions which say how a page should look and work. As well as very few Cascading Style Sheet (CSS) classes, which means the website won’t house any code which doesn’t directly aid its core functionality.

We also created a custom theme which could override certain stable9 functionality where necessary. Some of these overrides were general. For example, stable9’s template ‘page.html.twig’ is called on every public page, but our self-built theme adds a custom header and footer to it.

Overrides can be adding a class to an element for theming, or adding a whole new section to a page which isn't part of the default theme you’re using. Having our own theme gave us more control over the final version of the code base. Less inherited code from a pre-built theme means your frontend developer can have complete ownership of the frontend code.

We also removed any dummy and unused code. We even got rid of an updated admin skin. While we didn’t think this skin made a material difference for the Climate Group’s editors, it did add unnecessary weight to the website – every byte counts!

We kept a close eye on what reducing emissions meant for development time. It quickly became clear that it didn’t mean anything! That’s because the time it took to unpick and refashion otherwise familiar steps of a build was more than made up for by the efficiencies a build such as this dictates. Be that working in less fonts, images, or heavily customised and complicated code.

Pattern lab approach

We used a very strict pattern lab approach. This is a strategy that separates websites into five components: atoms, molecules, organisms, templates and pages. There were two reasons for this.

One was that a key contributor to unnecessary emissions is a bloated code base. This can be caused by poorly implemented updates made over time. Be that a new font size, a new background colour or a slightly different module. By adhering to a pattern lab approach, our team’s build pipeline becomes subject to an extra layer of governance. This means the code base – and the user’s experience – still stays true to the original, well-considered design we unpacked in the last post.

Secondly, a pattern lab approach gave our backend and frontend developers the ability to concentrate on their respective specialisms. Rather than requiring an experienced frontend Drupal developer, we needed a frontend developer who could write good quality, lightweight code. And that’s exactly what we had!

There are, of course, other knock-on benefits to the pattern lab approach. When new editors, designers or developers join the team, they’ll know exactly what is available to them and why. This is important because it means as the website ages, any small tweaks which are required over time can happen in line with the original sustainable design methodology.

We’re not advocating that sites stay exactly as they were the day they were launched. But small tweaks can have a huge impact on emissions if they aren’t considered in the same line of thinking as the initial build.

Consider every call

Third-party plugins aren’t within our control once they’re added to the site, so we've tried to remove as many of them as possible. One of the most obvious types on the ‘chop’ list was ‘follow and share’ social media plugins. They trigger excessive calls which convert into unnecessary emissions. Instead, we just used simple ‘html‘ links which linked directly to the Climate Group’s social network pages.

A slightly trickier third party integration we came up against was YouTube embeds. Having one on a page automatically triggers roughly 15-20 calls. If the person visiting the page doesn’t watch the video, all of those emissions are essentially a waste.

Video is a very powerful medium. It explains things in seconds that text or static pictures simply can’t. But to build a sustainable website, you have to weigh up this value against the emissions they produce. We replaced YouTube embed with a static picture and a play button. This follows a virtually identical user experience (UX) but saves on the number of calls the website makes.

Optimise images

Before you start optimising your images, you need to decide on which tool you want to use. We decided on Imagemagick, largely because of its marginally better image quality. It also has impressive file type coverage, as well as a number of extra features. But we kept the analysis simple, sticking to file size and image quality.

Once your images are optimised, you can start thinking about how to actually render the images to the user. We plan to implement lazy loading for future builds, but it didn’t make the prioritised list for the Climate Group’s go live. We were already minimising the number of images, so lazy loading wasn’t an absolute must-have. But to compensate, we used ‘srcset’ to pass the work to the browser. The tool tells the browser about the images we have available, and what size they are, hence the browser does all the work.

Use SVGs

The site had to be visually appealing, in spite of a severe cut back in imagery. This led to the use of background shapes or icons.

To minimise the file size, we used Scalable Vector Graphics (SVGs), which automatically scaled to fit the user’s device and used CSS to determine colour. If we had separated out each size and colour in different files, it would have cost us about 255 megabytes. That’s 693 kilobytes, times by three sizes, times by eight colours, times by 50 different images – ouch!

The SVG and CSS route cost Manifesto just five kilobytes. That’s 0.002% of the size it could have been without these modifications. Smaller, optimised images like these also mean faster site load times, storage space can be reduced and future development time is kept to a minimum. For example, in six months time when a new brand colour is added, you know which route will facilitate the easiest implementation.

Keep your fonts close

The Climate Group uses custom Adobe fonts, and they are a clear part of the charity’s brand. So, we needed to make sure the site could serve them in the most efficient way possible.

We decided to put them within the Drupal theme, so they could be served directly from the servers, where the rest of the site is stored. This avoids serving them from a font repository, which would require third party help. And it speaks to our overall aim – to maintain as much control as we can over the entire site. If we rely on external services we can’t control, then we’re not taking enough responsibility for minimising the site’s emissions.

In total, we used just three different weights of one font, and converted the files to WOFF2 to make them even smaller.

Conclusion

Throughout the technical steps in this project, Manifesto’s design and development teams maintained the following mindset – that reducing emissions was a positive challenge and not a negative constraint. By sticking to this attitude throughout the build, team members could reach their truest creative potential, questioning every norm – be that deadlines that could lead to quick but not environment-friendly solutions, or unnecessarily complex designs which use more energy.

While this is the first fully end-to-end digitally sustainable web build Manifesto has embarked on, it won’t be the last. We have processes in place to make this an important part of all of our projects; helping us to make this our default approach. The more experience our team gains on these sorts of projects, the greater efficiency we can implement into future builds.

Next up in our short series is Digital Sustainability: continuous improvements.

Neil Clark, environmental lead at Manifesto.