When a GreenTracer report says a page view is associated with, say, 0.2 g of CO₂e, it's fair to ask how anyone could know that. The honest answer is that nobody can measure it directly. A single visit touches your host's servers, several networks and the visitor's own device, each shared with countless other tasks, and none of them reports the energy used for your page. So the figure is an estimate. This article explains what goes into it, what it can't know, and why it is still a useful number to work with.
What the model actually does
GreenTracer uses the Sustainable Web Design Model, version 4 (SWDM v4), the default model in the Green Web Foundation's CO2.js library. It works from the top down. Its authors take published estimates of the total energy used each year by data centres, networks and user devices, and divide each by the total data transferred across the internet (5.29 zettabytes, a figure they take from the ITU). That gives an energy cost per gigabyte for each part of the system.
The model counts two kinds of energy for each part: operational, the electricity used to run the equipment, and embodied, the energy that went into making it. Added together they come to 0.300 kWh per gigabyte. Multiply by the data a page transfers and by a grid carbon intensity, and you have grams of CO₂e. Our guide to reading a carbon report walks through the arithmetic.
The authors are open about the limits. Their page states that models and estimates are imprecise by nature, and that because the model draws its boundaries broadly, its totals are likely to overestimate actual emissions, which they consider better than underestimating. They also say the model is less suitable for working out which specific part of a system to optimise, because it shares out the energy of the whole system by data transferred.
The assumptions GreenTracer adds
On top of the model, a GreenTracer check makes some choices of its own. We set them out so you can judge them:
- One first, uncached visit. We measure one initial load of the page with nothing cached, using Google PageSpeed Insights on mobile and desktop, and use the heavier of the two. The SWDM can account for returning visitors whose browsers have cached files, and CO2.js offers a per-visit calculation that includes the model authors' assumptions about visitors and caching. We don't apply that discount, so our figure describes a first visit.
- A global average grid. We use the SWDM default of 494 g CO₂e per kWh, the global average from Ember's data. The model allows regional or local values where they are known, but we don't know where your visitors are.
- A green hosting adjustment only for listed hosts. If the Green Web Foundation lists your host as green, the data centres' operational energy is removed from the estimate, as the SWDM describes for a green hosting factor of 1. Otherwise no adjustment is made. Our article on what green hosting changes covers this.
- Only what loads without interaction. The test doesn't scroll, click or accept cookie banners, so content that loads later isn't counted. See cookie banners, tags and your carbon test.
What a page test can't know
Some things that affect the real footprint of your page are simply outside what a single test can see:
- Where your visitors are. The carbon intensity of electricity varies from place to place, which is why the SWDM lets you use regional values when you know them. A global average can't reflect your visitors' local grid.
- What device they use. The model uses one average energy figure per gigabyte for all user devices, worked out from global totals. It can't tell which phone or computer your visitors have.
- How many visits there are. The estimate is per page view. Total impact depends on traffic, which a page test doesn't see.
- How visitors behave. Scrolling, clicking, returning with a full cache or leaving after a second all change how much data actually moves.
Why an estimate is still worth having
None of that makes the number meaningless. It makes it a particular kind of number: a consistent estimate based on one thing you can measure and control, which is how much data your page sends.
- It is consistent. The same method, the same constants and the same kind of visit are used every time, so two checks of your page, or checks of two pages, are comparable.
- It is proportional to something real. Under the SWDM, the estimate rises and falls with data transferred. The model's authors describe data transfer as “a proxy metric to account for the bloatware issue”. Halve the data and you halve the estimate.
- It points at what you can change. You can't pick your visitors' devices or their electricity, but you can choose lighter images, fewer scripts and leaner fonts.
- It is open. The model and its figures are published, so anyone can check the working.
Using the figure well
- Treat it as a guide for comparison and progress, not a precise measurement or a figure for a formal carbon report.
- Compare like with like: the same page, the same tool, before and after a change. Different tools may use different models: the CO2.js documentation notes, for example, that SWDM results differ from its other model, OneByte, because the two draw their boundaries differently.
- Look at the bytes measured as well as the grams. The bytes are the measured part; the grams follow from them.
- Read a grade as a band. Our grades page shows where the boundaries sit.
If that sounds modest, it is meant to. A careful estimate, honestly labelled, is more useful than a precise-looking number nobody can check. Check a page, then open “How we estimated this” to see every step.
