SWDM v4 worked examples

How I calculate a website's carbon footprint

Maciej Zmitrukiewicz · Material for the article Website carbon footprint: estimate, reduce and report it

This is the material behind the article. It shows the SWDM v4 formula the article uses and the examples I check it against. Every input here is made up for illustration, so the results show what the model assigns to a page, while the page's real energy use would need its own measurement.

What I looked at

I took the SWDM v4 coefficients from the Sustainable Web Design methodology and from the constants in CO2.js. The operational coefficients are 0.055, 0.059 and 0.080 kWh/decimal GB for data centres, networks and user devices. Embodied emissions, meaning the making of the hardware, are expressed as energy equivalents of 0.012, 0.013 and 0.081, converted at 494 gCO₂e/kWh. The hosting and reload rules follow the SWDM v4 implementation in CO2.js.

I wrote the arithmetic myself in a short script and didn't run the CO2.js package, so the article has an independent reference point.

D = first-view bytes / 1,000,000,000
F = first-view share + return-view share × reload share

C = F × D × [0.055 × I_dc × (1 - hosting factor)
             + 0.059 × I_network + 0.080 × I_device
             + (0.012 + 0.013 + 0.081) × 494]

The first-view and return shares add up to one. The reload share is the part of the page fetched again on a return visit, the opposite of the cached part. The hosting factor reduces only the operational data-centre emissions. The script applies both adjustments to each component as well, so the components always add up to the total.

Start from cold first-view bytes. If you feed in bytes that already reflect warm caches or weighted visits and then apply the reload share, you count the cache saving twice.

The eight calculation checks

Scenario	gCO₂e / modelled view	JSON identifier
1 MB, first view	0.148200	`one_mb_cold`
1 MB, hosting factor 1	0.121030	`one_mb_hosting_adjustment`
1 MB, 50% first / 50% return, 20% reload	0.088920	`one_mb_mixed_visits`
Same mixed visits, hosting factor 1	0.072618	`one_mb_hosting_and_mixed_visits`
2 MB, first view	0.296400	`two_mb_cold`
1 MiB (1,048,576 bytes), first view	0.155399	`one_mib_cold`
1 MB, data-centre factor 100; other factors 494	0.126530	`one_mb_lower_dc_grid_scenario`
Zero input bytes (arithmetic check only)	0.000000	`zero_bytes_model_only`

I keep six decimals so the tests catch any change in the arithmetic. In a headline, write about 0.15 gCO₂e.

Where the 0.148200 comes from

For 1 MB, a first-view share of 1, no hosting adjustment and operational factors of 494, the six parts are:

Component	gCO₂e
data centre operational	0.027170
data centre embodied	0.005928
network operational	0.029146
network embodied	0.006422
device operational	0.039520
device embodied	0.040014
Total	0.148200

Intensity and volume

The article compares two made-up periods. 2 MB × 100,000 views gives 29.640 kgCO₂e under this model, and 1 MB × 250,000 views gives 37.050 kgCO₂e. The page got 50% lighter while the total went up by 25%. The example shows how the two numbers relate, and it says nothing about why traffic changed.

Checking it against a second calculator

I also entered the four combinations of first view, cache and hosting into the calculator from CometWeb's own Web Sustainability report and ran it in Chromium. All four gave the same result as the script. Both calculators rest on the same assumptions, so this confirms the arithmetic, while the assumptions themselves stay untested.

What this data can't tell you

These are model calculations on made-up inputs. They measure no real website and come with no confidence interval.
A zero result for zero bytes checks the arithmetic. A real service with zero bytes still uses some energy.
Device-specific power, backend and AI energy, real traffic weighted by activity and a full lifecycle inventory are all outside these examples.
When a change in hosting or caching lowers the result, the model assigns less to the page. That is a modelled difference, and the physical saving can be different.

Files

scenarios.json: inputs and results for all eight scenarios, plus the traffic and hosting examples, each with a fingerprint so you can tell if anything changed
reproduce.py: the script that recalculates every scenario and rejects twelve kinds of invalid input

To run it again, use Python 3.10 or later with no extra packages and run python3 reproduce.py --output scenarios-reproduced.json --tests-output calculation-tests.json. The script and the JSON record the exact CO2.js file versions I checked the formula against.

Back to the article