COP27 Egypt: A webpage sustainability review - Part 2

Taipei's finally emerging from a month of almost constant rain. It's nice to finally have a few days of sun.

As I write this, COP27 is starting in Egypt. I've still got some hope in the process, but we are quickly running out of time to limit temperature rise to under 1.5 degrees celcius. In this issue we'll continue auditing the COP27 homepage, looking at the network layer & energy use on a real world device.

Let's quickly recap where we got to in the last issue.

  • We reviewed the website's performance profile on Treo, and found a significant design change in July/August corresponding with a degradation in website paint metrics.
  • We used WebPageTest to uncover that the website is primarily hosted in Egypt.
  • We then used The Green Web Foundation's IP to CO2 Intensity API to profile Egypt's energy grid.

Sustainability profile cont

Networks - Page weight & data transfer

Even though network energy use is pretty much a constant (I go into that here), it’s still important to be looking for ways reduce the amount of data we send to those visiting our sites.

When a page loads it can help with performance (as we’ve seen above). When a page is loading, it might help to reduce energy consumption on the user’s device. And, if anything, it can help ensure that the people consuming our sites who may have data caps, or pay-as-you-go plans, don’t chew through their budgets faster than they expect.

Page weight is a problem

The homepage initially loads over 19 MB of data. That’s over 9x the size of the median desktop page as of September 2022. As I was checking in DevTools, though, I noticed the data being transferred kept ticking up. It eventually stopped at 31.9 MB.

That’s probably another reason why the performance paint metrics are as poor as they are. There’s a heap of data contending for bandwidth as the page loads. Where’s all this data coming from, and what can we do to reduce it?


There are 155 images requests when the page first loads. They account for 16.8 MB of data transfer. Of these, only one was a modern image format - a WebP image served by a YouTube video embed near the bottom of the page. Most are PNG or JPEG format, including two images for the event’s mobile app that are 4.5 MB and 2.0 MB.

Reducing the impact of images would be a sensible first step. Applying the loading="lazy" attribute to off-screen images should help both sustainability and performance. Using modern formats (with PNG/JPEG fallbacks) would help take things that extra mile, and really get the overall transfer size down.

A lot of the image bloat seems to have come about since the website redesign that we saw earlier. The previous iteration of the site had a clean design that was light on images and fluff. It also demonstrated some features of Sustainable Web Design. I’m not sure what was behind the redesign, but my personal opinion is that it was done to the detriment of the website.

A self-hosted video file

The homepage also features a self-hosted video file near the bottom of the page. Of the final 31.9 MB downloaded, this one video accounts for 12.9 MB. I’ve included a simplified snippet of the video tag from the site below:

<video preload="auto" controls poster="path/to/post/image.jpg">

The video tag has a poster attribute, so there’s going to be something nice shown in place until the user starts watching it. For that reason, the preload attribute could be set to "none" which would instruct the browser not to download any video content until the user requests it (by playing the video).

A questionable Twitter feed

Just above the video, there’s a section promoting the event’s app alongside a Twitter feed. On my screen, it looks like this:

Screenshot from a section of the COP27 homepage.,q_auto/

Firstly, remember I mentioned a 2.0 MB image promoting the event’s app? This (the phone) is that image. A file which is 1443 × 2802 pixels, rendered at 227 x 440. We’ve talked about images already though. Let’s talk about Twitter.

Files served from Twitter (and related domains) account for 3.4 MB of the total page weight. That’s a fair bit of data to download, only to then display it in a section like the one in the picture above. I’m not a designer, but I’m sure there are better ways this part of the homepage could be presented. Michelle Barker’s covered some ways to reduce the impact of social embeds in this post for Smashing Magazine.

Let’s guesstimate the impact

If we could edit the website today to address the three areas highlighted above, what kind of impact might we have on overall page weight? Note that the figures below are guesses made off some knowledge, and assumptions.

  • We could probably reduce image size by at least 75% (saving 12.6 MB)
  • We’d remove the 12 MB downloaded for the video
  • We could defer the loading of all Twitter stuff until the user actually requests it (saving 3.4 MB)

So, we could potentially get the page down to a somewhat reasonable 3.9 MB without really having to dive deep into the weeds of website optimisation.

Devices - Testing energy usage

Still here? Thanks!

We’re now going to do something that I’ve never done before when reviewing a website. We’re going to see how much power it consumes on the client (the browser in this case).

We’ll be using the Firefox DevTools Profiler on a Windows 11 Surface Pro 6 device to record a capture of the site as it loads. We’ll then use a ⚠️ currently very much work in progress ⚠️ fork of the Profiler to look at the power usage. We’ll see data presented in both units of watts, and in units of CO2e (carbon dioxide equivalent).

The CO2e estimates we'll see should be considered experimental at this stage. I’ve been helping to build out this feature as part of my work with The Green Web Foundation. That said, I’ve never used it to review a website, so it’ll be my first time trying to analyse these figures too. Let’s learn together, friends.

Recording the capture

Rather than diving straight into the profile, let’s race through recording the capture first. I believe that the ability to record a power profile from devices was introduced in Firefox 104, so you’ll need to be on that version of the browser or newer. The option will show up on all platforms, but actually only works on Windows 11 & Mac OS at the time of writing.

In the browser, open up DevTools and navigate to the Performance tab. There, you’ll see a dropdown with different presets which you can use. There’ll be a Power option in that list. With that selected, you can start recording!

Screenshot from Firefox 106 DevTools, showing the Power preset selected in the Performance tab.,q_auto/

A wild profile appeared!

Once you’re done recording, the Profiler will automatically load your recording in a new tab. It’ll probably be overwhelming, just like the screenshot below. What we’re going to do in this post mostly focuses on the four Power rows (which you might be able to see highlighted in the screenshot below).

Screenshot of a Firefox Profiler results tab. If you look carefully, you can see the four Power rows highlighted in green.,q_auto/

Before continuing, I’d like to again reiterate that I’m using a local, forked version of the Profiler to uncover carbon emission data. While energy consumption data is currently available in the live version of the tool, the carbon emissions data you’ll see shortly is from a branch that is still being actively worked on.

Device level energy and carbon estimates

Let’s zoom in on the four Power rows. Here’s what they show us.

Screenshot showing Power tracks (rows) in the Firefox Profiler.,q_auto/

In the screenshot above, I’ve hovered over a point in time on the Power: CPU package row. This brings up a tooltip showing:

  • Power (in watts) - The power consumption by the CPU package at that point in time on the timeline.
  • Energy used in the visible range (in milliwatt-hour) - the energy used by the CPU package over the entire profile.
    • Next to the milliwatt-hour figure there’s also a carbon estimate shown in milligrams of CO2e. This is the bit that I’ve been working on with The Green Web Foundation.

Okay, so there’s a likelihood that you’re like me and don’t know your milliwatts from your milligrams. All we really need to know is that we’re dealing with some pretty small figures here.

What does this mean?

Here’s how I’m reading it:

For each time someone on a Surface Pro 6 loads the COP27 homepage, 45 milliwatts of energy are used by the device, equating to an estimated 20 milligrams of CO2e.

It might help to work with larger numbers here. If 100,000 people visited the homepage on a Surface Pro 6, then a collective 2000 grams (2 kilograms) of CO2e will be generated by the devices.

A few things to note

While this is super handy data to have, there are a few things to keep in mind - especially with the experimental CO2e figures I’ve shown.

  • The profile I’m reviewing is loading the page with an empty cache. Would caching change power consumption? That’s something to look into in another post.
  • The CO2e figures are generated using global average grid intensity figures for 2021, which are imported into the project from CO2.js. Ideally, we’d like to use more region-specific figures for even greater detail. There’s been some conversation around this as part of the PR for this feature.
  • I honestly have no idea whether looking at CPU package, CPU cores, iGPU, or DRAM would be the right approach here. There are some details documented in the Firefox Source Docs, but I’ve yet to go into detail on that.
  • This just captures the page load. The only interactions I had with the page were to close the cookie banner & app promotion overlay.

I’d love to explore these further when I’ve got a bit more time. Especially measuring interactions.

Overall sustainability profile

We’ve unpacked a lot in this post, so thank you for making it this far.

To finish, let’s get back to answering the question we began with - how does the COP27 homepage stack up from a website sustainability perspective?

On the whole, there’s a lot that could be done better. Let’s break it down by looping back on the server, network, and device information we’ve found.


Summary: Based off what we can uncover, not great.

  • It looks like all content for the domain is served from Egypt, without the use of a CDN.
  • Egypt’s energy intensity is a bit above the global average, with most of that generation coming from fossil fuels.
  • We can only hope that the site has been hosted on servers that get all/most of their power directly from clean energy sources.


Summary: Poor, but can be easily improved with a few quick fixes.

  • The page loads almost 32 MB of data when first visited.
  • Most comes from images. Using lazy loading & modern formats could reduce their size significantly.
  • Next culprit is a video near the bottom of the page. Changing to preload="none" here would save 12 MB of data download.
  • Finally, a design rethink of the Twitter feed on the site could help shave off more bytes.


Summary: “Yeah nah”. Or maybe “nah yeah”.

I’m not really sure to be honest. Since we’ve used some experimental tooling to surface device level CO2e estimates, I don’t really have a reliable baseline to go off.

Let’s end on a positive, and give them a passing grade here 🙂.

I hope you enjoyed reading the last two weeks as much as I enjoyed auditing the COP27 website. I definitely learnt a lot in the process, and developed a few more techniques that I'll explore further for future audits.

The next issue of Optimised will be in your inbox on November 25th. The website has an archive of all previous emails. It's a good place to recap on anything we've covered, and also handy to share with friends or colleagues. As always if you've got any feedback or specific topics you want to be covered then just reply to this email.

Keep safe, stay well.