Ten steps to greening your website

As we re-evaluate our lifestyles in the face of global climate change, it’s not just how we heat our homes, how we travel, work, rest, play and consume that needs a major re-think. Our websites also consume carbon, and we need to deal with this. As Tom Greenwood (see below) says, “If the internet were a country, it would be the sixth most polluting country in the world, with annual emissions similar to those of Germany”.

Fortunately, doing something about this is relatively easy, but only if we all play our part. Just as charity begins at home, so does the walk that we can talk about. This post therefore aims to step through the issues that matter and show you what you can do with your website. It uses this Backdrop CMS website as the example, but much of these details will be transferable to your website’s platform, be it WordPress, Drupal or whatever.

A website’s carbon consumption has a surprisingly long life-span. Our computers are busy as we push pixels at the design stage and wrangle code at the development stage. As the process moves from development to staging to launch, the hosting company itself becomes part of the audit. Then there is the longer-term energy use involved in serving page after page to the site’s visitors. At each of these steps there are decisions we can take that can reduce the energy consumed. The good news about this is that by auditing these issues, you will be able to adopt leaner habits with longer-term energy savings. These will then be repeatable for each project, and you’ll want to refine the details as you go.

Measuring your progress: the tools to use

As you work through some of these steps, objective measurement will be your guide so that you can judge progress. I suggest that you use Web Page Test, which has been around for years (and has recently undergone a makeover), and Website Carbon Calculator, which is a newcomer that will forever change the way you think about web design. Before going any further, test your own website using these online tools, note the results, saving screenshots of the details where appropriate. These will be your benchmarks as you iteratively work through each of the ten steps that follow. You will need to look for specific details, as follows:

A. Web Page Test details to note

You will be interested in many of the results spat out by WPT but for the purposes of carbon consumption you should note the “Fully Loaded / Bytes in” measure. This is the weight of the page being tested as measured in kilobytes. It is what the server’s processing spits out. It is what your website’s visitors’ machines and browsers need to process. The smaller, the better.

To put this kilobytes number in perspective, HTTP Archive attests to the fact that median desktop page weights in November 2010 were 473 kilobytes, and that this increased to 2,000 kilobytes in January 2021. A breakdown of these numbers is revealing:

Carbon guzzling culprits are clearly images and JavaScript, with fonts coming a close third. Also note that the quantity of HTML - predominantly the text that visitors read - has barely changed over time. Our websites are clearly doing more now than simply serving up information. You can get a breakdown of numbers like these for your own website by clicking the Content tab:

One of the excellent features of the free Web Page Test service is that it keeps your test results for up to a year. Once you are viewing test results, just access them using the Test History tab on their main menu:

B. Website Carbon Calculator details to note

Over on the Website Carbon Calculator website, the percentage measure is what you should note. It will be either “cleaner than x% of web pages tested” or “dirtier than x% of web pages tested”. (The cleaner measure will display if the percentage score is 50% or above; the dirtier measure will display if the percentage score is below 49%.) The cleaner, the better. Just note that each page result is cached on their website for that day. If you’ve made a change to a page (making it ‘cleaner’, presumably), then don’t re-test by hitting F5. Just be patient and wait until the next day.

Using these two metrics of a page’s weight and the energy consumption required to display it results in a convergence that won’t be lost on you. Greener pages - if we can call them that - will mean faster pages, although the reverse is not automatically true. (You may, for example, have a super-fast page served by a hosting company that doesn’t use sustainable energy.) Faster pages will also result in a more satisfying experience for your users. The takeaway is that by aiming to make your website more sustainable, all other things being equal, you will also be providing a better user experience.

Let’s get started …

Step 1.Renewable energy for hosting - and for development

The Website Carbon Calculator makes a fairly good stab at assessing whether your website hosting is run on sustainable energy. If in doubt, you can check with your hosting company. These days, hosting companies that use ‘sustainable energy’ will usually proclaim it proudly. If they say that it’s run on 100% renewable electricity from sources like sun, wind and sea, then that’s better than vague carbon offsets or tree planting on its own. If the electricity running your computer under your desk is supplied the same way, then you will be doing something right. You might also question where your hosting company’s servers are geolocated. The closer they are to your intended audience, the better.

This might raise the issue of whether you have opted for a content-delivery network (CDN), which might generally be a good thing in terms of sustainability as it will reduce the megabyte miles that your larger files have to travel. But the energy saving in using a CDN may be offset if the CDN provider doesn’t use sustainable energy. Check first.

Step 2.Image compression

We can see from the above table that images are the greatest source of weight. They will make the single greatest demand on the energy resources used to build a site, to host it, and to serve it to users. As Henri Helvetica says over at the HTTP Archive’s Web Almanac, images “will also be our greatest source of savings”. There are plenty of ways of dealing with this.

I’ve written before (different post, this site) about one option for maximum compression of JPEG images using JPEGMini Pro. This is either a stand-alone app or a Photoshop/Lightroom plug-in that squeezes another 30% or so of file size out of JPEGs over and above what you can already accomplish with Photoshop, all with no discernible difference to the human eye There are alternatives.

Using WebP images instead of JPEGs could shave yet another 30% off any images you use. The best, free batch converter for Windows that I know of is XnSoft’s XnConvert. By using an 80% quality setting with compression method 4 and filter strength 60, I’ve reduced 42 extra-large JPEGs weighing a total 29Mb to a total WebP image format weight of 15Mb. Comparable savings are possible with the smaller files that your site will typically be serving.

I remain mildly nervous that WebP doesn’t enjoy total support, although CanIUse reports that only IE 11 doesn’t support the WebP image format, which wouldn’t normally bother me if it weren’t for the fact that most users of IE 11 do so because their accessibility software requires it. Whilst we can celebrate that Microsoft 365 apps dropped support for IE 11 in November 2021, it remains the case that there is a stubborn hold-out of IE 11 users worldwide, estimated at between 1.4% and 2.5% of site visits. (See an excellent article about this by Graham Armfield of Hassell Inclusion.) If I could be sure that this rump of users - often in public libraries where funds are extraordinarily tight - had largely vanished, I’d swap out all the JPEGs I use and replace them with WebP equivalents. The reduction in megabyte miles would be very substantial. Until then, maximum compression of JPEG will have to suffice.

There are three other steps that you could take to reduce the size of the images that your website serves. The first two can be used in conjunction with JPEG ‘super-compression’ or using WebP image formats:

• You could try using monochrome images instead of 24-bit colour JPEG images. In some situations, this is not just adequate but even visually desirable, creating an atmospheric image that these days can stand out from the crown of over-pumped HDR colour images.
• You could try blurring the parts of an image that aren’t key to appreciating the image’s main subject. Photoshop filters do this nicely. By reducing detail in this way you also reduce file size.
• Stop serving images altogether - or at least stop serving them gratuitously. I’m not prepared to do this just yet, but I can imagine taking such a step at some point.

Step 3.Audit your JavaScript

JavaScript is the second bulkiest resource our websites serve. On this site, of the 116kb of JavaScript being served (after compression), a whopping 90 or so kilobytes were being used by the beautiful image lightbox/gallery MagicZoom library (separate post, this site). You will use your own lightbox/gallery library to serve your larger (but well-compressed?) images - but check for code bloat.

I have been able to replace that with the ultra light-weight lightbox/gallery Featherlight.js. There’s a Featherlight module for Backdrop which provides a field formatter and the ability to load the library manually. The library consists of a mere 400 lines of JavaScript, 100 of CSS and it weighs in at a miniscule 6 kilobytes combined. What one ditches in beauty one gains in fleetness of foot. It also works on everything all the way back to IE 8, including mobiles.

Step 4.Font choice, location and weight

I have used Adobe Typekit and Google Fonts to serve fonts. The payload they add to a site is not inconsiderable. By keeping to two font files, one for display headings and one for body text, the added weight is around 57kb. Your font payload will vary. However, there are two ways of lightening this load. The first of these could be to host your own fonts which would have the benefit of not needing to ask for them to be delivered by a separate server. You would need to make use of the @font-face rule at the start of your CSS along these lines, after which you would refer to the font by the font-family alias that you have given it.

@font-face {
	font-family: 'xyz serif alias';
	font-style: normal;
	font-weight: 400;
	src: local(''),
		 url('fonts/xyz-serif.woff') format('woff'),
		 url('fonts/xyz-serif.ttf') format('truetype');
	font-display: swap;
  }

The ttf font will be served to Safari and Android browsers, while the woff font will be served to most other (‘modern’) browsers. As usual, provide a fall-back, generic font-family further down in your CSS, as this will cater for situations, such as Opera Mini, that can’t handle the @font-face rule.

h1, h2, h3 {
	font-family: 'xyz serif alias', 'Times New Roman', Times, serif;
}

The second way to slim down the weight of your site’s typographic requirements would work if you went with the self-hosting option described above, but this will depend upon your requirements in terms of languages, accented letters and glyphs (such as currency symbols and curly quotes). If you need little of these and can serve your text with a minimal set of font glyphs, then you could derive subsets of the font files you use - on the further condition that the licensing terms of the fonts in question permitted that. If you’re interested, Everything Fonts have font subsetter utility which will take your original font file and allow you to select only those glyphs you require before generating a slimmer subset font file which you can plug in instead. You may shave a further 25% - 50% off these file sizes. Work out what that means by subtracting the subset file sizes from the original file sizes and then multiplying the difference by the numbers of user’s first visits to your site. You’ll be dealing with approximations, but there will be an energy saving.

If you really wish to put a green hair shirt on your website, ditch all custom fonts and specify system fonts only. There is a roll call of venerable fonts installed on machines out there, so one could do worse by not having the likes of Arial, Verdana, Helvetica, Tahoma, Trebuchet MS, Times New Roman, Georgia and Garamond fonts. I’m not brave enough for this - yet.

Step 5.Cache, aggregate, compress and minify

Your CMS will offer you the ability to configure your website to aggregate and compress CSS files, and to aggregate JavaScript files. You may also be able to ‘minify’ your HTML, CSS and JavaScript, that’s to say to strip out the white spaces, line breaks and comments, and thus shave off a bit more size from the files that our served.

You should also ensure that you have your site configured to utilise server-side GZIP compression for CSS, JS and HTML resources. The Web Page Test resource mentioned above will guide you on accomplishing this. It’s well-worth doing and will enable you to secure its coveted A grade, as in the fourth icon from the left shown here, confirming that you will have reduced the total weight of resources that a page request serves.

Step 6.Help users avoid Yoyo navigation

One feature of good website design is to provide navigational aids on as many pages as possible. By providing users the ability to navigate horizontally as well as only vertically, you can help speed them to their destination and reduce unnecessary visits back up to a parent or home page before they nip back down again to a different page. Tom Greenwood calls this latter behaviour ‘Yoyo user journeys’, wasteful of user time, server processing and bandwidth.

One obvious way of avoiding this is to provide a menu of blog post titles alongside the blog post that the user is currently reading. They can then use these links to move horizontally. It’s surprising how many site designers even today don’t rate this simple affordance. If it’s good for users, it’s probably also good for the planet. Provide menus wherever possible.

Step 7.Generating less markup (Backdrop and Drupal examples given)

Both Drupal and Backdrop can be configured to generate less markup, particulars through the Views database reporting engine. (Your CMS is likely to have similar options.) The format settings for all views offer the ability to add views row classes and/or add striping (odd/even), first/last row classes. Not selecting these will not generate that additional markup:

A similar option exists at the row style level where you can disable the addition of default field wrappers to the markup:

Making these choices will get you from this:

<div class="views-row views-row-8 even">
	<div class="views-field views-field-title">
		<div class="field-content">
			<a href="https://www.rob-tomlinson.com/blog/bbc-sounds-app-and-ontabletfling-event">The BBC Sounds app and the onTabletFling() event</a>
		</div>  
	</div>  
	<div class="views-field views-field-created">        
		<span class="field-content">November 24, 2019</span>  
	</div>  
</div>

to this:

<div class="views-field views-field-title">
    <div class="field-content">
        <a href="https://www.rob-tomlinson.com/blog/bbc-sounds-app-and-ontabletfling-event">The BBC Sounds app and the onTabletFling() event</a>
    </div>  
</div>  
<div class="views-field views-field-created">        
    <span class="field-content">November 24, 2019</span>  
</div>

and eventually to this:

<div>
    <div class="field-content">
        <a href="https://www.rob-tomlinson.com/blog/bbc-sounds-app-and-ontabletfling-event">The BBC Sounds app and the onTabletFling() event</a>
    </div>    
    November 24, 2019
</div>

These reductions in page weight are minimal, and the whole exercise smacks of extreme nerdery, but the reduction in megabyte miles over the life of these pages will contribute to a smaller carbon footprint. Even greater savings will be made if these steps are taken with more complex menu system such as site maps. (It’s not unheard of to make 20kb of savings on some pages with these choices.) Your CMS is likely to have similar options.

Targeting markup in your CSS when these additional field wrappers aren’t there is a little more demanding, but all of that is eminently do-able, as all content has context which CSS styles can latch onto.

Step 8.Stop uploading video files

Agree never to upload video files ever again! They weigh too much and will, according to Cisco, take up 82% of all consumer traffic by 2022. (That way you’d also be better placed to join the fight against the tide of ‘deep fakes’ that is about to break upon us.) Besides, even one video file on your website will undo most of the good work you might have accomplished with any of the steps mentioned here.

Step 9.Standards compliance

As a long-time advocate of building websites with as ‘valid as possible’ code, I’m making a case that valid code uses less processor cycles and thus less carbon in a page’s lifetime.

There are times when it’s not possible to output the desired 100% valid code as judged by the World Wide Web Consortium’s Nu Html Checker. Your CMS or several of the modules or plug-ins you’ve chosen to use with it may be errant in this regard. I’m tempted to say that your choice could have been better, but I’ll cut you a little slack on the matter - if only because I too find it an uphill struggle to always output clean code. But you did try, didn’t you?

Brazen disregard for web standards has always struck me as unprofessional. It now strikes me as been unsustainable too. After all, if your users’ browsers are perpetually occupied error-handling code that you didn’t take the trouble to check out and clean up, then you’ve created something less sustainable than would otherwise be the case. (Watch this space for more detail on this shortly.)

If you object to this point of view, the chances are that you are pushing back against making your own website generate valid code - rather than pushing back against the broader argument in favour of making your website greener. Let me know if you think I’m wrong about this.

Step 10.The Website Carbon badge

Read about the Website Carbon Badge and then install it with pride on your own website. Once you have your site’s structure nicely toned, the badge will be a reminder to you that the weight of your content will vary from page to page. The presence of the badge will also attract curiosity and the word will spread!

Summary

If you’ve worked through the above steps, the chances are that the total bytes loaded by a page on your website will have been substantially reduced. As measured by Web Page Test, you will be able to compare where you are now with where you were with the page that you tested when you started this process. Is it any greener, and is the whole of your website greener as well?

Tom Greenwood’s inspiring book, Sustainable Web Design

Finally, for your step 11, read Tom Greenwood’s inspiring book Sustainable Web Design on this subject.

This small book could be the catalyst to transforming how website builders think about the work they do. But fear not: Sustainable Web Design is jam-packed with advice on how to make a website consume less energy. Hardly any aspect of the work that web designers and coders do is neglected.

What also jumps off these pages is that making a site sustainable also makes it faster; what makes a site use less energy also makes it a better experience for the user. This set of inter-connected relationships is made compellingly attractive, if not irresistible, by the author. So do the planet a favour and grab yourself a copy of this book (even in eBook format) and join the movement.