Colophon

A colophon (pronounced KOL-uh-fon) is a note at the end of a book explaining how it was made — what typeface it's set in, what paper it was printed on, who bound it. It's a small act of transparency from the maker to the reader.

Websites don't have paper or typefaces in the same way, but they do have a footprint — servers, bandwidth, electricity. So this is a colophon in that same spirit: a note on how this website was made, and how we try to keep its footprint small.

The site is built with a tool called Astro. It bakes every page into static HTML ahead of time — so when you visit, there's no server building the page on the fly. The pages are just files, ready to send. That's much faster and much more efficient than the way most modern websites work.

Content — every pattern, every blog post, every event — lives as text files inside the website's own source code, next to the photos they use. There's no separate database or content-management system that has to be running somewhere, consuming power in the background even when nobody's visiting.

The site is hosted by Netlify. When you load a pattern photo, Netlify resizes it on the fly to the smallest version your screen needs. So a phone gets a phone-sized image, a laptop gets a laptop-sized one — rather than everyone being sent a single oversized file "just in case".

Every visit to a website uses a small amount of electricity — to serve the files, to move them across the network, to display them on your device. Multiplied across the world, that adds up to a meaningful amount of emissions.

Rather than accept a single number from a third-party calculator and leave it there, I wanted to calculate the carbon footprint of this website myself, using an open model, with numbers you can reproduce. Here's how, and here's where we are.

How we measure#

There are three steps:

1. Measure the bytes. I run Google Lighthouse against every major page on the site, against a simulated mid-range mobile phone on a congested 4G connection. Each page is tested three times and the median byte-weight is taken, because any single run can be noisy (one uncached image variant and your number jumps 20%).
2. Translate bytes into grams of CO₂e. I use CO2.js, an open-source library from the Green Web Foundation. It's the same library that powers tools like Website Carbon Calculator, Ecograder and Digital Beacon — so the numbers on this page line up with what you'd get if you ran the site through any of them.
3. Use the Sustainable Web Design v4 model. CO2.js supports several models; I've used Sustainable Web Design v4 (SWD4), the current version as of 2024. It accounts for energy used by data centres, the network in between, and the device you're reading on, weighted by the typical global mix of grid intensity.

The result is a number of grams of CO₂-equivalent per page view. Convention maps that number onto a letter grade — the same scale Website Carbon publishes — so you can see at a glance where a page lands.

Where we are today#

Figures below are from the last Lighthouse run. Page weight is the total bytes Lighthouse recorded for a first-visit page load; grams of CO₂e come from feeding that byte figure into CO2.js with the SWD v4 model.

Rating bands (grams CO₂e per view, Website Carbon convention): A+ <0.095 · A <0.185 · B <0.341 · C <0.493 · D <0.656 · E <0.846 · F ≥0.846.

What a returning visit actually costs#

The table above assumes a cold cache — you're arriving for the first time and your browser has to download everything. For a returning visitor, most of what we send is already in the browser's local cache. Our own static assets — images, fonts, CSS, compiled JavaScript — are served with a one-year cache header, so none of that comes over the wire a second time.

But some things do still re-download on every visit. The HTML document itself doesn't cache (it has to revalidate so you see new patterns and blog posts). And the two analytics scripts we currently load — Google Tag Manager and PostHog — both ship with short cache lives of their own (15 and 5 minutes), so they re-fetch any time your last visit was more than a few minutes ago. Added together they make up the bulk of a typical return visit.

Putting it together#

Averaged across the whole site, today:

• A first visit emits about 0.132 g CO₂e — less than one Google search (roughly 0.2 g at global-grid averages; a minute of YouTube is around 0.5 – 1 g). That puts the whole site squarely in Website Carbon's "A" band, with every page A-rated. The lightest page is /events, which would already be A+ on a green host.
• A returning visit emits about 0.047 g CO₂e — roughly a quarter of a Google search, and about 3× lighter than a first visit. The single biggest chunk of that return visit is Google Analytics, which is why retiring it matters more than it looks: GA costs us 155 KiB on every repeat reader, not just on first-time ones. Without it, a returning visit would drop to roughly a tenth of a Google search.

Honest caveats#

This is a model, not a measurement. A few things worth naming:

• SWD4 is an average-of-averages. It doesn't know which data centre served your request or what device you're reading on. It's a principled estimate using global-mix assumptions, not a reading off a physical meter.
• "Green host" is binary in the model — a host is either renewable-powered or it isn't. Reality is messier; Netlify sits on AWS and Google Cloud, so we can't tell from outside which one is serving any specific request. We report the non-green number above as the honest default.
• The returning-visit figure assumes a typical "next day" visit — long enough for the short-cache analytics scripts to have expired, but not so long that the browser's asset cache has been evicted. If you come back within five minutes, your actual emissions are near-zero (just the HTML); if it's been a month and your cache has rolled over, you're closer to a first-visit number again.

The most sustainable byte is the one you never send, so most of what's on this page is really about not sending bytes.

We test this site with Google's Lighthouse tool, and we specifically test against the mobile profile: a simulated mid-range phone on a congested 4G connection with a slow CPU. That's not the latest iPhone on fibre — that's real-world reading conditions for a lot of people, and it's the baseline we care about being fast on.

Our latest scores (median of several runs, mobile, simulated):

• Accessibility: 100 across the whole site
• SEO: 100 across the whole site
• Best practices: 96 across the whole site
• Performance: ~85 on most pages, still pushing for 90+ ("green")

On desktop, performance is comfortably in the green band on every page. On mobile we're still a few points short on some pages; see "what's next" below.

A colophon isn't a finished statement — it's a snapshot. Things I'd like to improve from here:

• Finish the migration to PostHog and retire Google Analytics. The moment that happens, every page on the site loses roughly 156 KiB of extra JavaScript per visit.
• Get every mobile page into the "green" performance band. Most are there already; a handful sit in the high 80s. The lever is a finer, page-by-page tuning of image sizes — too aggressive and we degrade quality on certain screens, too gentle and we waste bytes. It's tedious work that has to be done carefully, which is why it's on the list rather than shipped.
• Find a greener hosting setup. Netlify's footprint is reasonable, but because it sits on top of both AWS and Google Cloud we can't be confident which backend is serving any given request — and AWS's green credentials are weaker than Google's, which are in turn weaker than some specialist green hosts. Moving off Netlify means giving up a lot of convenience (deploy previews, image CDN, edge functions), so I want to do this carefully rather than hastily.
• Adopt a real carbon-per-visit measurement. While I was at the Green Software Foundation, we kicked off a project with the W3C to define a standard way of reporting a website's carbon footprint (a Carbon Specification for the Web). Once that lands I'd like to publish a properly-calculated figure for this site rather than relying on modelled estimates.

Where that gets us#

If we do those three concrete things — retire Google Analytics, trim images on the heaviest pages, and move to a verified green host — my modelling with CO2.js projects the site averages would land at:

• A first visit at around 0.086 g CO₂e — a 35% drop from today, and enough to clear Website Carbon's A+ threshold on every page.
• A returning visit at around 0.019 g CO₂e — less than a tenth of a Google search, and a ~60% drop on today's return emissions.

That's the target.