Observability turned on its own publication. This page is the honest accounting: how the site is built, what it loads, and how the footprint badge in the footer arrives at its numbers. Awareness, not absolution.

Annual footprint

The loop opened when we first instrumented the publication closes here: the site measuring itself, published openly. 2026 is the baseline year — each future year lands beside it so the trend is visible, not just asserted.

Measured from the built site (public/), gzipped, by scripts/footprint-report.py — inspectable and reproducible: run it after a build and you get these numbers. No third-party calls. Every page sits well within its per-template budget (article 100 KB, guide 200 KB, front page 120 KB), and the whole site is small enough to cache offline in full.

Method

The footprint badge in the footer measures this page’s real network transfer using the browser’s Performance API — the same resource and navigation timing entries you’d read off any instrumented service. It sums transferSize across every resource the page actually pulled, then converts bytes to an estimated carbon figure:

gCO₂e = transferred_GB × Σ(segment energy, kWh/GB) × 494 gCO₂e/kWh

  data centre   0.055 operational + 0.012 embodied
  network       0.059 operational + 0.013 embodied
  user device   0.080 operational + 0.081 embodied
                                    ────────────────
                             Σ =    0.300 kWh/GB
  (a green-hosting factor would offset the data-centre operational
   share; we keep it 0 — github.io isn't a verified green host)

This is the Sustainable Web Design v4 model — the same one the CO2.js library implements — inlined into the footprint script so the badge adds no runtime dependency (keeping the 0 runtime deps budget above honest). Energy is summed across three system segments — data centre, network, and user device — each with an operational and an embodied share, then multiplied by the global grid intensity, 494 gCO₂e/kWh (Ember). It’s an approximation, not a meter — treat it as an order-of-magnitude signal, the way you’d treat a sampled trace rather than a billing record.

What the number honestly leaves out

• Repeat visits read lighter. transferSize reflects the network, so cached assets count as ~0 on a return visit. That’s correct — a returning reader really does pull fewer bytes — but it means the badge shows less than a cold first load.
• Cross-origin assets report zero. Resources served without a Timing-Allow-Origin header return transferSize: 0. Fonts are now all self-hosted and counted; what’s still hidden is the CDN-loaded Mermaid library (diagram pages only) and the Umami analytics script. We treat that as a to-do, not a loophole: self-hosting them makes them both lighter and visible to the meter.
• It’s modelled averages, not your request. The SWD model uses global-average energy intensities and grid carbon — not your actual device, network, or the grid where the page was served. It’s a rigorous industry estimate, not a per-request measurement.

The point isn’t a precise gram count. It’s the habit: a publication about seeing your systems clearly should be able to see itself.