You can’t always trust results from website carbon calculators

You can’t always trust results from website carbon calculators. As it turns out, you can’t always trust other tools either, such as Google Lighthouse or browser inspect, when it comes to total Network transfer.

For example, I tested the website of a B Corp recently. I wanted to check how it measured up to see if it could be added to the lowwwcarbon showcase. I ran a few tests across different carbon calculators, all of them suggested the homepage’s initial page weight was around 1.2MB. Not too bad, I thought.

I was skeptical though. The reason I didn’t believe these results? The full screen autoplaying background video. I knew there was no way this 40 second long media asset was loading in well under 1MB (alongside everything else).

Deciding to delve further, the next test was to look at the Network transfer via browser inspect tools. This too suggested that the total network transfer was around 1.2MB, just like the carbon calculators displayed.

This can’t be right, I thought. I decided to inspect the page further. Downloading the video asset – a single mp4 file – I found it to be 22MB. So how can this be autoplaying and appear to only weigh a few bytes?

206 partial content status

Instead of the expected 200 status result, I noticed there were multiple (sometimes two, sometimes three) 206 partial content status codes for media – the same video file.

What does this mean?

This indicates that the video is only being loaded in small chunks, rather than the entire file in one go. There are a few different methods for this, such as:

Progressive Loading: Some media formats, like videos, support progressive loading, where the initial request fetches only a small part of the file, and additional portions are requested as needed. This can be used for smoother streaming. The initial request may indeed show as only a few bytes, while more data is loaded in subsequent requests.

Streaming: The video might be streaming in small chunks. In such cases, the browser requests each chunk separately, and the network transfer tool may display the size of each individual chunk, which could be small.

Range Requests: The server or the browser may be using HTTP Range Requests. These requests allow you to fetch specific byte ranges of a file. For example, when you initially load a video, the browser might request only the first few bytes. As you play the video, it fetches subsequent chunks.

To be honest, I don’t think I’ve come across this before on a ‘standard’ website. Definitely not one put together with a very common page builder plugin for WordPress. I would expect this from a streaming platform or YouTube/Vimeo, but not a fairly straight forward website.

A deceiving result

The result of this is that the site can be quite deceiving. If I hadn’t of delved further and only gone on the initial results, I could have been sharing a website with a 22MB autoplaying video as an example of best practice of low-carbon web development. Not something I want to do.

My conclusion to this? Be inquisitive. Ask questions. Delve deeper. The truth may be different to those initial results.

What to read next

More from our resources, blogs and case studies

Find this resource useful?

I hope so. I want everyone to be able to benefit from articles like this one. That is why I'm kindly asking for your support.

These resources take time to research and write. The site is run by one person, with occasional volunteer contributors in spare time. Please consider supporting the project if you can.

Plant a tree with Ecologi or Donate £3