Understanding the link between your website and its environmental impact

The internet has a dirty secret, its carbon footprint. When you think of climate change, the internet probably doesn’t come to mind, heck you might not even know it contributes to climate change at all.

But the reality is, it does – contributing around 4% of global emissions (more than the airline industry) and its increasing daily, largely thanks to digital inefficiencies.

So today we’ll be looking at 3 homepages for websites in the climate space – ranging from ~0.16g of co2 per view up to a whopping ~6.54g of co2 per view (to capture the carbon footprint of these websites I’ll be using websitecarbon.com ).

We’ll also dive into what is contributing to these wildly different scores and what those values mean in a more understandable way.

This is not to call anybody out, but instead, in doing so, I hope it’ll help others to be more aware when it comes to design, development and content solutions.

So with that said, let’s dive in.

Novus homepage ~6.54g of co2 per view

We’re kicking things off with Novus – the UK's first B Corp certified neo bank which turns your everyday spending into a force for good.

So what does 6.54g of co2 per view equate to in a more understandable way?

The good bits

The website is built on top of the Jamstack leveraging NuxtJS and DatoCMS .

On top of this, DatoCMS serves the latest image format (AVIF – although there is some debate whether it’s better for the environment than WebP ) to browsers that support it, failing that it then falls back to WebP and finally JPG or PNG.

Most modern browsers support AVIF or WebP which generally offer smaller file sizes than JPG, PNG or GIF.

Room for improvement

Now let’s look at some of the biggest inefficiencies.

Hero image

Right off the bat, we’re hit with the largest image on the page – an animated GIF coming in at 489kb.

Generally speaking, we shouldn’t really be using animated GIFs anymore, especially on key pages of a marketing website – there are far more efficient solutions around.

Often times an auto-playing MP4 video would be of better quality and lower file size. But one drawback is that it doesn’t support transparent backgrounds (which wouldn’t be a problem here).

So let’s see what the output would be, using an online converter (GIF to MP4) and running it through a video optimiser here are the results:

But this animation isn’t overly complex, it could easily be replicated with some code;

• Background image layer
• Foreground image layer of the phone which loops between different screens

All of this could come in even lighter than the MP4 video.

Auto-playing video

As you scroll to the bottom of the page, you’ll come across the worst offender – an auto-playing video.

But Rob, didn’t you just say auto-playing videos are a good solution?

Well, they are and they aren’t.

Videos are often one of the worst offenders when it comes to a website’s carbon footprint. Especially because most CMS’ (at least ones I’ve worked with) don’t have any optimisation built in.

So when a content editor comes along and uploads a video, that’s what is going to be served on the website (which is probably what happened here).

This video comes in at an alarming 8.4mb!

So let’s see what we can do:

The simplest solution would be to drop this into an online optimiser, in doing so we go from 8.4mb to 4.8mb – a saving of 42%, better but still terrible.

Now if we look at the website, the video is a small letter box size, but the video being loaded is much taller.

This means the top and bottom of the video are being loaded but will never be seen by the user.

So what happens if we crop the video from 1920px/800px to 1920px/400px and then run it through our online optimiser:

Cropping our video takes it from 8.4mb to 5.9mb, and then putting it through our optimiser we get down to 1.8mb – a total saving of 78%!

This is far better, considering it only took a few minutes.

But 1.8mb is still pretty high, ideally, we’d like this to be lower than 1mb, so what else could we do?

Well we could try and reduce the overall size of the video, it’s currently 1920px wide, resizing it down to 1680px or 1440px wide for example would bring the size down more, the downside is this would have an effect on the video quality on larger devices.

Another thing we could do is trim down the video, as it’s just for visual effect, cutting it down from 17 seconds to say 10 seconds shouldn’t be so bad.

Let’s take a look, if we take our cropped video and trim it down to 10 seconds and optimise it we get it all the way down to 660kb – far better than what we started with! That’s a total reduction of 92%.

Oxwash homepage ~3.35g of co2 per view

Next up we have Oxwash – the on-demand laundry service made simple and sustainable.

Coming in at 3.35g of co2 per view what does that equate to in a more understandable way?

Room for improvement

The site is built on Webflow and looks like a fairly standard, dare I say old setup.

When I first loaded the website, I was hoping to find a couple of really badly executed things that were making the carbon footprint high, but that’s not the case.

Beyond the video, in the hero, everything else isn’t so bad… but there’s volume to this.

In total, this page is loading a whopping 222 requests and transfers 14mb worth of assets to the page.

Auto-playing video

Let’s start with a quick win, optimising the video in the hero. This is by far the biggest asset being loaded on the page coming in at 3.6mb.

Dropping it into our optimiser and tweaking the compressions settings slightly we go from 3.6mb to 2.1mb a reduction of 42%.

Now don’t get me wrong this isn’t just magic where metadata is being removed from the video without any drawbacks, the video does take a bit of a hit when it comes to quality, but Oxwash have a blue overlay on top of the video which should help to soften some of the quality loss.

Other than trimming this video down from 18 seconds, there isn’t a lot else we can do.

Next-generation image formats

Up next we have image formats, the Oxwash homepage is loading 75 images, totalling 1.3mb.

Whilst there aren’t really any outliers when it comes to file size, the bulk of it starts to add up.

When we take a look at the image formats being used, they’re either JPG, PNG or SVG – so they’re not making use of any next-gen image formats like AVIF or WebP.

So let’s take a look at the largest image…

As it turns out the largest image being loaded is never actually shown to the user, based on the file name it was an image meant for mobile but it’s just hidden by CSS, so users are loading a 246kb image for no reason.

Simply removing this image will shave off 246kb from the page.

Okay let’s take the next biggest image, this one comes in at 125kb – not exactly terrible, so let’s see what we can do.

Before we change the image format, let’s try and drop it into TinyPNG , this takes us from 125kb to 105kb a saving of 16%.

Whilst this isn’t massive, it can add up to make a difference when rolled out across all assets.

Now let’s take a look at a WebP image.

Taking our original JPG and converting it to WebP we go from 125kb to 77kb and then if we run it through our optimiser we get it down to 58kb a total saving of 53%.

So you can quickly see how much of a difference these next-gen image formats could make when rolled out across all images.

Javascript

There’s a lot of Javascript being loaded here – 76 files to be precise coming in at 2mb.

Now I’m not going to try and dissect what all of these Javascript files are doing and I’m not sure what capabilities Webflow has when it comes to bundling together Javascript files…

But at a high level, there’s a bunch of marketing scripts being loaded here:

• Google tag manager
• Hotjar
• Klayvio
• etc.

I’d estimate at least 0.5mb to 1mb are coming from marketing scripts – whilst the likes of Google Tag Manager are great, every marketing script you add quickly adds up and your websites performance and carbon footprint take a hit as a result – so make sure that what you’re adding is actually being used!

Etcho homepage ~0.16g of co2 per view

Finally, we have Etcho – who is empowering a world of conscious investors.

Coming in at a mere 0.16g of co2 per view what does that equate to in a more understandable way?

The good bits

Etcho is again built on top of the Jamstack leveraging NextJS and Prismic .

In total, this page is loading a total of 81 requests and transfers 752kb worth of assets to the page.

So what are they doing right?

Like Novus, they’re making use of next-gen image formats like AVIF with a fallback to WebP.

The largest image comes in at a mere 39kb.

Other than this, the page also makes sensible use of SVG images with the largest coming in at 4.8kb – a small file size but crisp image quality.

Out of the 81 requests, 31 of those are images – coming in at 130kb (17% of the total size being loaded).

So where does the majority of the size come from?

Room for improvement

At this point we’re essentially trying to squeeze every last drop of performance out of this, 0.16g of co2 is a really low score, but that doesn’t mean there isn’t room for improvement.

With that said, most of that 752kb being loaded is Javascript – coming in at 391kb (that’s 48% coming from Javascript).

So how could this Javascript be reduced?

Google tag manager script

Google Tag Manager makes up 78kb of that 391kb (19%) – not a lot we could do about this, other than not use it.

On a related note, Google Analytics – for those who don’t actually use all of the functionality it has to offer, Plausible analytics is a great alternative which is 45 times smaller than Google Analytics and is privacy focused (I’ve been using it myself for coming up to 2 years now).

Cookie popup script

Next up we have the largest individual Javascript file – the cookie popup which comes in at 94kb that’s 24% of the Javascript coming from the cookie popup and 13% of the total size being loaded.

An alternative cookie popup solution could trim this down.

NextJS scripts

Finally, we have the javascript bundles coming from NextJS – when added all together it comes in at around 200kb.

So what could be done here?

There are a couple of things we could try:

• Disable client-side Javascript – there’s meant to be an experimental config option which disables client-side Javascript on a page-by-page basis, but whether it’s supported still or not is another question
• Replace React with Preact which would reduce that bundle size a little bit

Alternatively, Astro (which is what I’m building my new website with) might be a better option than NextJS in this case, as it would bring the bundle size down to probably less than 50kb if I had to guess.

It’s probably worth mentioning, I built the Etcho website .

We made a lot of conscious decisions right from the design stage that meant we could create something that looked great but also had a low carbon footprint!

In doing so we managed to reduce the carbon footprint of their website by 88% compared to their old one !

Wrapping up

As you might’ve noticed much of what I’ve talked about in this post is performance related, and whilst digital sustainability goes further than performance, it’s often a good place to start.

Also, you might’ve noticed we didn’t go about changing any design choices on any of these websites, we purely discussed what can be done from a development or a content perspective to reduce these websites’ carbon footprint.

Choices made at the design stage of a project can ultimately decide whether your website can even have a low carbon footprint, e.g. could we come up with a different decision at the design stage which means not having to use auto-playing video?

Hopefully, this post highlights some ways you can implement more mindful solutions when it comes to your websites carbon footprint.

Until next time ✌️.