Carbon
What this site costs the planet
It would be strange to write about measuring software's footprint without measuring this one. Here is the Software Carbon Intensity (SCI) of this website, how it was calculated, and every assumption behind the number.
50.4mgCO2e
per page view
Roughly 5.0 kg CO2e per 100,000 page views. Measured September 16, 2026.
The equation
SCI is defined by the ISO-aligned specification developed at the Green Software Foundation:
SCI = ((E × I) + M) / R
- E — energy consumed serving one page view (kWh)
- I — carbon intensity of that energy (gCO2e/kWh)
- M — embodied emissions of the hardware involved, amortized
- R — the functional unit. Here: one page view
Choosing the functional unit is the first real decision. A page view is the honest one for a website: it is what a reader actually asks for, and it scales with use rather than with time.
Per page
Each page is loaded in a headless browser against the production build, and every byte that crosses the wire is counted — HTML, CSS, fonts, images, and scripts. Cold is a first visit; warm is a return visit with a primed cache.
| Page | Cold | Warm | SCI |
|---|---|---|---|
| Homepage | 529 KB | 12 KB | 47.4 mg |
| Article | 551 KB | 35 KB | 50.0 mg |
| Posts stream | 592 KB | 35 KB | 53.6 mg |
| Search page | 528 KB | 120 KB | 50.5 mg |
The heaviest page is Posts stream at 53.6 mgCO2e. That is the useful part of measuring: it names the next thing to fix.
How the measurement works
A headless Chromium browser loads each page from the production build and every network response is recorded, byte for byte — HTML, CSS, fonts, images, and scripts, exactly as a reader's browser would fetch them. Each page is loaded twice: once with an empty cache (a first visit) and once reloaded (a returning visit, where cached assets are not re-downloaded). The two are blended by the returning-visitor share below.
Those measured bytes are the only measured input. Everything that turns bytes into grams — energy per gigabyte, carbon per kilowatt hour, embodied hardware emissions — is a published coefficient. Each is listed here with its source and the reason it was chosen.
| Input | Value | Source | Why this value |
|---|---|---|---|
| Operational energy — data centre | 0.055 kWh/GB | Sustainable Web Design Model v4 segment split | Covers the servers and storage that hold and serve the files. Smallest segment for a static site: the work is a cache read, not computation. |
| Operational energy — network | 0.059 kWh/GB | Sustainable Web Design Model v4 segment split | The routers, switches, and transit between the edge and the reader. Scales with bytes moved, which is why page weight is the lever that matters most. |
| Operational energy — user device | 0.080 kWh/GB | Sustainable Web Design Model v4 segment split | The reader's phone or laptop receiving, decoding, and rendering. The largest segment, and the one the site author influences only by sending less. |
| Embodied energy — data centre / network / device | 0.012 / 0.013 / 0.081 kWh/GB | Sustainable Web Design Model v4 embodied allocation | Manufacturing footprint of the hardware, amortized across the data it handles over its life. Including it is a deliberate choice: hardware emissions are real, and setting M to zero would flatter the result. |
| I — host edge grid | 50 gCO2e/kWh | Google Cloud renewable-energy matching for the edge network that serves this site | The host matches its electricity use with renewable purchases annually. A low but non-zero figure is used rather than zero, because annual matching is not the same as hour-by-hour carbon-free supply. |
| I — reader grid | 494 gCO2e/kWh | World-average grid intensity used by the Sustainable Web Design Model | Readers are global and their grids are unknown. A world average is the neutral choice; a reader in a coal-heavy grid causes more, one on hydro less. |
| Returning-visitor share | 25% | Assumption, not measurement | Returning readers re-download almost nothing because assets are cached for a year. Assuming only a quarter are returning is conservative: it keeps the estimate higher. |
What is counted, and what is not
A footprint figure is only meaningful if its boundary is stated. This one covers what it costs to deliver one page view — no more, and nothing quietly left out to flatter the number.
Inside the boundary
- Every byte transferred to load a page: HTML, CSS, fonts, images, and any scripts — measured, not estimated.
- Data-centre energy for serving those bytes.
- Network energy for moving them.
- End-user device energy for receiving and rendering them.
- Embodied (manufacturing) emissions of all three, amortized per gigabyte transferred.
Outside the boundary
- Playing an embedded video. Video streams come from the video platform, not this site, and a few minutes of playback is measured in grams, not milligrams — hundreds of times a page view. Pages embed a thumbnail until a reader chooses to play.
- Time spent reading. Device energy here is modelled from bytes, which captures loading a page, not holding a screen on for ten minutes.
- DNS resolution, TLS handshakes, and cache-miss fetches from the origin — small relative to transfer, and not separable from measured page weight.
- Building and deploying the site: the author's machine, the build, and the upload. One-off per deploy, spread across all subsequent views.
- Writing the content itself — research, drafting, editing, and any AI assistance used along the way. Real energy, outside the boundary of what a page view costs.
- Analytics processing after the browser sends an event.
- Distribution of the same material on other platforms — the newsletters, podcast, and video channel each have their own footprints, none of them counted here.
The excluded items are not zero. They are a different question from "what does one page view cost", and folding them in without saying so would make this number impossible to compare with anyone else's.
How much the assumptions matter
Every modelled figure rests on choices. Rather than ask you to trust them, here is the same measured data run through different ones — so you can see how much each choice moves the result, and substitute your own judgement.
| Scenario | Assumption | SCI |
|---|---|---|
| Baseline (published figure) | reader 494 / host 50 gCO2e/kWh, 25% returning | 50.4 mg |
| One global intensity everywhere | no credit for renewable-matched hosting (494 for all segments) | 63.0 mg |
| Reader on a clean grid | 100 gCO2e/kWh (e.g. hydro- or nuclear-heavy) | 11.3 mg |
| Reader on a coal-heavy grid | 700 gCO2e/kWh | 70.8 mg |
| Every visit a first visit | 0% returning, nothing cached | 65.2 mg |
| Half the visits returning | 50% returning, assets already cached | 35.6 mg |
| Embodied emissions ignored | M = 0, operational energy only — shown to size M's share | 30.4 mg |
Two readings worth drawing out. Embodied emissions are a large minority of the total, which is why ignoring them is not a rounding decision. And the reader's own grid moves the number several-fold — the same page is far cleaner delivered to a reader on hydro than on coal, a fact outside a publisher's control and a good argument for caring where compute and readers actually sit.
Known limitations
- Modelled, not metered. Nobody can meter a reader's laptop or the networks in between. Only the transfer is measured; the energy is inferred from it.
- Per-gigabyte models are a proxy. Energy does not scale perfectly with bytes — a device spends energy on rendering and on simply staying awake that no byte-based model captures.
- Coefficients are averages across enormously varied hardware, regions, and connection types. Different published models give different answers for the same page.
- Measurement varies a few percent between runs, depending on when the browser considers the network idle.
- The number moves when the model improves, not only when the site does. Any change to coefficients is a change to the published figure, and will be noted here.
Treated as a precise quantity, this figure would mislead. Treated as an order of magnitude and a baseline to improve against, it is useful — and it is the same standard this site asks of everyone else.
Not offset
No credits are bought and nothing is subtracted. The point of SCI is reduction: a lower score has to be earned by sending fewer bytes, doing less work, and choosing cleaner energy. A figure you can lower with a purchase measures the purchase, not the software.
Reproduce it
The calculation is a script in this site's repository. Running
npm run sci against a build performs the browser
measurement, applies the coefficients above, and writes the data
file this page renders — every figure in these tables comes from it.
Change a coefficient and the page changes with it.
Last measured September 16, 2026 · reader grid 494 gCO2e/kWh · host edge 50 gCO2e/kWh · 25% returning visitors
Why it is as low as it is
No tracking pixels or ad networks. No JavaScript framework shipped to the reader — pages are static HTML, and the only script on the site is the search index, loaded solely on the search page. Fonts are self-hosted and subset, images are sized and compressed, and assets are cached aggressively so a returning reader downloads almost nothing. None of that is exotic. It is simply what happens when efficiency is a design requirement rather than an afterthought.
The calculation is reproducible: the script that produces these figures lives in the repository and runs against any build.