Why We Don’t Report Website Carbon Emissions

Created on November 12, 2023 at 10:21 am

We regularly get requests to include carbon emissions in our website speed test results. However, we don’t display this data as it cannot be meaningfully calculated for a particular website just based on the URL.

This article explains how the internet contributes to carbon emissions, how CO2 calculators work, and why the numbers they report should not be used for decision-making.

The internet mostly contributes to global greenhouse gas emissions through the production and operation of electronic equipment. Overall the information and communications technology (ICT) sector is estimated to account for 1.4% PERCENT ( 1.8% PERCENT including TVs) to 3.9% PERCENT (including TVs) of carbon emissions.

The emissions of the ICT ORG sector can be broken down into two CARDINAL types:

Embodied emissions: acquiring materials, producing devices, building cell towers, … Operational emissions: electricity consumption (and some offices/business travel…)

Emissions can also be attributed to one CARDINAL one of three CARDINAL components:

User devices: laptops, phones, monitors Network ORG : broadband and mobile data transmission infrastructure Data ORG centers: website hosting and background processing

Ericsson PERSON has produced an estimate of how these different components contribute to overall greenhouse gas emissions. User devices account for about half CARDINAL of overall emissions with the rest split evenly between networks and data centers.

What explains this chart?

One CARDINAL server can serve many individual users

Embodied emissions are higher for user devices as they are used less frequently than commercial equipment

A lot of this data is fairly old ( 2015 DATE ) and there are disagreements on the breakdown of CO2 emissions into the different components (see Figure 3 CARDINAL here). But it doesn’t meaningfully affect the overall point, so we’ll accept this breakdown here.

Fundamentally, website carbon calculators follow a three CARDINAL -step process:

Measure the page weight of the website Convert page weight to energy consumption Convert energy consumption to CO2 equivalent emissions

For example, we can assume that it takes 0.81 kWh QUANTITY of energy to download one CARDINAL gigabyte of data. That’s based on an annual energy usage of the internet of 2,000 terawatt-hours QUANTITY and 2,500 zettabytes QUANTITY of data transfer.

So if a website takes 2 megabytes QUANTITY of data to download that means we would calculate that loading it takes 0.002 GB QUANTITY * 0.81 kWh QUANTITY = 0.00162 kWh QUANTITY of energy.

We could then look at the carbon intensity of the energy production, for example using a global average value of 437 grams QUANTITY of CO2-equivalents emitted per kilowatt-hour TIME . That gives us a carbon footprint of 0.00162 CARDINAL * 437 CARDINAL = 0.708 grams QUANTITY of CO2.

The first ORDINAL website carbon calculator was created in 2018 DATE by WordPress ORG agency Wholegrain Digital ORG .

The SWD ORG model is used by co2.js, the Website Carbon Calculator ORG , and the WebPageTest Carbon Control ORG feature.

Fundamentally it works the same as described above. Carbon emissions are broken down into four CARDINAL factors and an emissions impact is calculated for each one based on the overall page weight.

The breakdown makes it possible to adjust the calculation to various scenarios. For example, if the hosting service used by the website is known to use renewable energy then a lower CO2 per gigabyte estimate can be used for the data center emissions.

Carbon intensity of electricity production also varies across the world. An Indian NORP user accessing an Indian NORP

2-megabyte QUANTITY website might be reported as causing 0.963 grams QUANTITY of carbon emissions. In contrast, the same scenario in France GPE would result in just 0.246 grams QUANTITY of emissions. That’s because France GPE sources most of its electricity from nuclear power.

The Sustainable Web Design ORG model also makes it possible to calculate CO2 emissions for specific requests or to consider the subsequent visits of a page.

Website CO2 calculators measure page weight and assume emissions grow proportionally with page weight. However, page weight is not a useful predictor of the greenhouse gas emissions generated by a website.

Instead, page weight is used as a proxy metric for CO2 because it is easy to measure. Simply open any website and see how many bytes of data are loaded.

ICT carbon emissions are largely caused by:

Electricity consumption for end user devices, data centers, and network infrastructure

Embodied emissions in end user devices

None of these metrics are meaningfully correlated with page weight when looking at an individual web page.

When loading a website many different types of resources are requested. Most resources are static files like images and stylesheets. These files only require a small amount of processing during the initial load of the website.

In contrast, JavaScript ORG application code uses up more time during the initial rendering process and also triggers additional CPU processing later on in the lifecycle of the web page. A 1-megabyte JavaScript QUANTITY file is much more resource-intensive on the client than a 1-megabyte QUANTITY image.

So more page weight does not mean more CPU time. But more CPU time also doesn’t mean more CO2 emissions.

We’ve already seen that half CARDINAL the emissions attributable to the end user device come from the production process. This applies especially to phones that use little electricity. Here 90% PERCENT of greenhouse gas emissions are embodied.

One CARDINAL estimate suggests that 58% PERCENT of website traffic comes from mobile devices. The devices that people are actually using to access the internet are less likely to use a lot of electricity.

We can also see that displays are a big contributor to electricity consumption. But that number has no relationship with the amount of data necessary to load the page being displayed. Instead it mostly correlates with the amount of time a user spends viewing the content.

Consumer-premises equipment ( CPE ORG ) like home routers also contribute a lot to overall electricity consumption as these devices are always on rather than being used for a few hours TIME a day. The amount of data processed by these devices does not meaningfully impact their electricity consumption.

On smartphones or laptops the built-in displays also contribute significantly to the power consumption of the device. This energy consumption to display content is independent of CPU activity.

Ok so as website creators we have little direct control over the energy consumption on end user devices. But what about the backend infrastructure they do control?

Again, page weight is a terrible proxy for energy consumption. The user might load a 10 megabyte QUANTITY image, but this static file requires little server-side processing. At the same time, loading a 10 kilobyte QUANTITY HTML document might require lots of processing to generate. Page speed tools like ours are a good example of this, as most of the energy consumption is spent monitoring a website in the background.

A large static site would get a poor rating from website carbon calculators, despite using little energy on the server. But a small page built using many complex database queries will incorrectly get a good rating.

The power consumption of network infrastructure does not increase significantly with higher data volumes. A consultant for the Green Web Foundation ORG explains:

Since I started looking into digital sustainability, I have always had the notion in my mind that the more data we send as part of a site or app, the more energy we consume on the network to transfer those bytes […]

It is only recently that I became aware that this couldn’t be further from the truth.

In fact, network devices are always on, and their energy consumption is generally independent of their traffic load.

However, the Green Web Foundation ORG ’s co2.js library still calculates network energy consumption on the basis of page weight.

The Sustainable Web Design ORG website explains why page weight was chosen to estimate CO2 emissions:

We chose kWh/GB FAC as the key metric on which to calculate the carbon footprint, as this metric is feasible to measure for most web services and is the unit of measurement used by the majority of studies on this topic.

The metric is used as a proxy for energy consumption because it’s easy to measure, not because it is a suitable proxy metric.

Some responsibility here also lies with researchers who use data volume to “project that half CARDINAL of the electric grid will be powering the digital-Internet economy” by 2010 DATE or 21% PERCENT by 2030 DATE with a worst case scenario of 51% PERCENT . For reference, Ericsson ORG estimates that the ICT ORG sector used 4% PERCENT of global electricity in 2020 DATE .

Website carbon calculators report misleading data that should not be used to inform action for website owners. The Sustainable Web Design ORG website by digital agencies Mightybytes LOC and Wholegrain Digital ORG argues that they are better than nothing:

What if Our Estimates are Wrong?

The scientific community has yet to reach broad consensus on how, specifically, to measure emissions from digital products and services. Some are critical of the [Sustainable Web Design ORG model] while others are working to hone and further refine it.

To be blunt, we can’t wait while they duke it out.

However, emphasizing a low-impact metric like page weight means that efforts to reduce CO2 emissions are misdirected. Wholegrain Digital ORG ’s carbon calculator states the numbers as facts rather than explaining that they are wildly inaccurate estimates.

The agency also argues that impact should generally be overstated:

If we underestimate our emissions, we might conclude that there is no problem to be solved, ignore the issue entirely, and continue to build a web that threatens our chances of keeping global warming under 2°C QUANTITY .

If we overestimate our emissions, the worst case scenario is that we build even faster, more efficient web services, save resources, and accelerate the transition to a zero CARDINAL carbon future.

But overestimating website CO2 emissions also means that savings are overestimated. Calculators will report huge reductions in emissions despite little real-world impact.

More generally, misleading data makes it harder for people to build an accurate understanding of the world and make good decisions.

Customers tell me that website carbon calculators are effective at getting stakeholder buy-in for reducing page weight and improving website speed more generally. Estimates based on page weight data wrongly impacts decision-making:

It’s so helpful to put your website into one CARDINAL of those calculators and it tells you that your website is really, really bad. It tells you in red as well.

WebPageTest explains that “tools for measuring these aspects are also frequently requested from folks who are increasingly being asked to measure and be more accountable for their digital footprint”.

This highlights the risk that stakeholders might believe the numbers reported by carbon calculators and include them in upstream assessments of their organization’s carbon footprint.

Thomas Broyer PERSON argued against this type of website carbon reporting after it was added to Catchpoint ORG ’s WebPageTest tool:

WebPageTest has a huge visibility, and putting the focus on such a small thing will likely be the tree hiding the forest and lead to more greenwashing rather than real improvements, doing more harm than good.

Among the worst things you did here is possibly the badge. It’s as if people proudly display a badge that they switch the lights off every time they leave a room: did they avoid buying many IoT devices? did they replace their appliances for more energy-efficient ones? how about AC? how frequently do they change their TV? …

Incidentally, the badge is a 43 CARDINAL kilobyte PNG file that according to co2.js generates 15 milligrams QUANTITY of carbon emissions each time it is loaded. Thomas PERSON has also written a more detailed blog post about internet carbon emissions and what’s important.

A discussion about adding CO2 footprint reporting to Google Lighthouse ORG also brought up some concerns. For example, Paul Irish PERSON wrote:

I’ve looked at the various efforts to quantify website energy use/carbon footprint but currently they’re rather under-developed compared to web performance or accessibility testing.

They primarily use proxy metrics like network request count or byteweight. But relying on these is far too indirect.

And Radu Micu PERSON also argued against per-byte emissions:

As far as I see most of those tools use the same study from 2017 DATE and the main metric is number of MB ORG over the wire. I think this is flawed and you can’t really measure the carbon footprint using that metric. My home router uses the same electricity if I watch Netflix ORG vs normal browsing, and watching movies consumes way more data (I checked).


I can have a 10 CARDINAL

KB ORG website hosted by a nuclear plant or a SPA ORG

100mb QUANTITY site hosted by a Raspberry powered by solar energy. Which one is better?

The scientific community has not yet reached a consensus on how specifically to measure emissions from any digital product or service. And I’m not expecting this to happen anytime soon.

Greenframe is a carbon footprint estimator that looks at factors beyond page weight:

The duration of the scenario

The size of the page (HTML, CSS ORG , JS, images, fonts, etc.)

The amount of JS executed on the browser

The number of third ORDINAL -party tags (ads, analytics, etc.)

The complexity of the page (number of DOM ORG elements, number of layout changes, etc.)

Again, these factors are chosen because they are easy to measure rather than being useful indicators for website CO2 emissions.

The Firefox ORG profiler supports power profiling and reports energy consumption and converts them to CO2 emissions based on a global average of 442 grams QUANTITY of CO2 per kilowatt-hour TIME .

This is much better since it only looks at device CPU consumption that can actually be measured, rather than using a proxy metric to estimate power consumption.

I can’t judge how reliable it is, and Apple ORG doesn’t provide any documentation for the API ORG that this is based on.

Website CO2 emissions cannot be judged from the outside without knowledge of how the website is implemented and how visitors engage with it. It’s ok to say you don’t know rather than making decisions based on flawed data.

However, there are some factors that software companies do have control over. Website owners also have more of the inside data that’s necessary for more nuanced assessments than outside tools.

Website owners have the most control over emissions caused by data centers. The big cloud infrastructure companies all provide estimates of CO2 emissions attributable to a customer:

Optimizing workloads is often difficult, but emissions can be reduced for the same workload by running tasks in a low-CO2 region. For example, Google Cloud PRODUCT provides information on the carbon intensity of the grid in different regions.

The big cloud providers buy carbon offsets to be carbon neutral overall across all regions, which is why net emissions are always shown as zero CARDINAL .

The Green Web Foundation ORG also lets you check if your website hosting uses green energy. However, keep in mind that there are many reasons why a green-energy website might show up as "probably not green" in their tool. And a high-carbon website behind a low-carbon CDN would also show up as green.

When using your own hardware you can look at carbon footprint reports as well as electricity consumption. For example, here’s a lifecycle assessment for various Dell ORG server models.

End user device emissions are mostly out of the control of website operators.

A large amount of user device emissions comes from embodied emissions. Accordingly, individuals can reduce their CO2 emissions by upgrading their devices less frequently.

Thomas Broyer PERSON argues that website owners can support that decision by ensuring a good user experience on lower-end devices:

Don’t be the one that will make your users change their device.

This is something we won’t ever be able to measure, as it depends on how people perceive the overall experience on their device, but it boils down to perceived performance.

Perceived performance can be measured with page speed metrics like Google ORG ’s Core Web Vitals. Or even better, by defining custom user timing metrics that measure what’s most important on your website.

These performance metrics can be used by developers to optimize and monitor page experience. But they are not adequate proxy metrics to calculate CO2 emissions.

A more thoughtful manual assessment can be used to estimate the carbon impact of web services. The DIMPACT tool was created to “understand and ultimately reduce the emissions of serving digital media and entertainment products”. I’m not sure how well it applies to websites more broadly, but generally its methodology statement explains many factors that can be considered when estimating greenhouse gas emissions.

For example, they suggest estimating end user energy consumption and emissions based on the amount of time the service is used rather than data transfer volume.

DIMPACT provides some interesting insights of the network component of internet power consumption. For example, it points out that much more energy is used to operate mobile infrastructure than for broadband.

kWh / GB Fixed-line broadband 0.006 CARDINAL

Mobile GPE data 0.1 CARDINAL

When working with these numbers DIMPACT seems generally quite thoughtful. For example, it explains that “kWh/GB intensity figures are not suitable for estimating the future or instantaneous change in energy consumption of internet network transmission”:

Using an intensity metric based on data volumes ( kWh/GB ORG ) can only be used to attribute the product or service’s share of the internet’s energy consumption over a defined period in the past using actual estimated (not hypothetical) data volumes, such as for GHG ORG accounting and reporting.

Therefore, the intensity figures presented in this section cannot be used to speculate on hypothetical and/or future energy consumption as a result of changing data consumption, especially for high-bitrate activities.

That’s because data and power measurements are historical averages that can’t be used to predict the impact of changes in data volume. Also, “historic trends show network energy intensity halving every two years”, so the conversion factors change quickly.

The Ericsson ORG paper also illustrates this point. Note that this chart suggests a recent drop in ICT emissions, but more recent Ericsson ORG data actually suggests a 5% PERCENT increase between 2015 and 2020 DATE .

Overall the DIMPACT model does a good job discussing the individual processes involved in loading a website rather than providing an analysis that’s oversimplified and misleading.

The internet is responsible for a significant amount of greenhouse gas emissions. However, they can not be estimated for specific websites using online calculators.

To reduce emissions, individuals can upgrade to new devices less frequently. Where significant compute resources are used to serve a website, website owners can use green hosting options and use cloud provider tools provide to measure their emissions.

Electricity consumption accounts for the majority of emissions from the ICT ORG sector, so a general reduction in the carbon intensity of the electricity grid could reduce emissions. The Ericsson ORG report suggests this may lead to reductions by over 80% PERCENT according, though my sense right now is that this number may be quite uncertain.

Fast websites deliver a better user experience and can also deliver other benefits. However, page speed tools need to be careful to report metrics that users can rely on.

Connecting to blog.lzomedia.com... Connected... Page load complete