Does your website have a carbon footprint? Yes — and the fix is the same as the speed fix

The internet has a carbon problem, and your page is part of it

The scale surprises people because the emissions are invisible. Taken together, the digital sector is responsible for roughly 4% of global carbon emissions, which means the internet now generates more than the entire aviation industry, and data centres alone consume somewhere around 1 to 1.5% of the world’s electricity — a share rising quickly as AI workloads grow (The Sustainable Agency, 2026). Every page view triggers work at each link in the chain: a server processes the request, networks transmit the data, and the visitor’s device renders it, and each step draws electricity (Decoding Biosphere, 2026).

At the level of a single page, the current industry benchmark is about 0.36 grams of CO2 per view, which totals roughly 43 kilograms a year for a site with 10,000 monthly views and climbs into tonnes for high-traffic sites (Website Carbon, 2026). Those numbers deserve a caveat that runs through this whole guide: the estimates are models, different methodologies produce different figures, and you should treat any single number as directional rather than precise (Decoding Biosphere, 2026). What’s not in doubt is the direction — websites have a measurable footprint, and most of it is avoidable.

Where a page’s emissions actually come from

The footprint breaks down across four layers: the data centres that host the site, the networks that carry it, the devices that display it, and the embodied emissions of manufacturing all that hardware (1ClickImpact, 2026). But within the part you control — the page itself — the distribution is lopsided in a useful way. On a typical site, media is the dominant contributor, JavaScript accounts for much of the remainder, and the backend for very little; one common breakdown puts it at roughly 80% media, 15% JavaScript and 5% server-side code (CloudPressHub, 2026).

That lopsidedness is good news, because it tells you exactly where to look. Large unoptimised images and video, heavy JavaScript, and third-party scripts that pull code from other servers are the avoidable overhead, and a page loaded with them can emit three to five times what a lean equivalent does (SEO Juice, 2026). Bot traffic and unnecessary third-party tags pile on more (Decoding Biosphere, 2026). The same bloat that this cluster’s guide on site speed identifies as the enemy of performance turns out to be the enemy of the climate too — which is the whole point.

The fix is the performance fix

Here’s the insight that makes sustainable web design practical rather than a separate chore: the optimisation is the same. Lighter pages produce a lower Largest Contentful Paint and therefore better rankings, and lighter pages also emit less carbon, so a single set of changes serves both goals at once (CloudPressHub, 2026). If you’re already optimising for Core Web Vitals — which you should be — you’re most of the way to a low-carbon site by definition, because page weight is an input to both (CloudPressHub, 2026).

The industry is starting to measure this explicitly. Google’s Web Almanac added a sustainability chapter that tracks per-page CO2 using the Website Carbon methodology, a sign that the topic is being watched even if it isn’t yet a formal signal (CloudPressHub, 2026). The honest framing is that you shouldn’t optimise carbon for SEO — Google hasn’t made it a ranking factor and probably won’t — but because cutting emissions is the same work as improving speed and user experience, the ranking benefit arrives anyway, as a by-product of building a lighter site. Speed, sustainability and a good visitor experience are three readings of one decision.

The levers, in order of impact

Because media dominates the footprint, image optimisation is the highest-value move: compressing images and adopting modern formats like WebP or AVIF can cut page weight dramatically, on the order of 70% in many cases (Digidop, 2026). After that comes removing unnecessary scripts and third-party tags, and self-hosting lightweight, subset fonts instead of pulling bloated files from external servers, followed by caching and a CDN to avoid retransmitting the same bytes. Leaner content helps too — every feature and asset you don’t ship is energy you don’t spend.

Then there’s hosting. Running on servers powered by renewable energy reduces the data-centre share of your footprint, by somewhere between roughly 30% and 90% depending on how genuinely green the provider’s supply is, and the Green Web Foundation maintains a directory you can check a host against (SEO Juice, 2026). The order matters, though: most sites cut emissions by 60 to 80% through the design and code work alone, with green hosting closing the remaining stretch rather than substituting for a lean page (CloudPressHub, 2026). Weight first, hosting second.

Measuring it honestly

If you want to act on this, measure before and after rather than trusting intuition. The current standard is the Sustainable Web Design Model v4, an open methodology that estimates energy across data centres, networks, devices and manufacturing — using figures like roughly 0.30 kilowatt-hours per gigabyte transferred and a global average grid intensity near 494 grams of CO2 per kilowatt-hour — to produce a per-view number (1ClickImpact, 2026). Free tools apply it: the Website Carbon Calculator gives a quick per-page estimate and checks whether your host runs on renewables, while Digital Beacon breaks a page down by images, scripts and fonts so you can prioritise (Decoding Biosphere, 2026).

The honest way to use these is to run more than one, expect the numbers to disagree slightly, and treat the results as directional (CloudPressHub, 2026). Record your baseline and page weight by asset type, make a change, and re-run to confirm the delta (Decoding Biosphere, 2026). The value isn’t in the absolute figure, which no model can pin down exactly; it’s in the comparison — your page against a benchmark, and your page against its former self after each optimisation.

The emerging standards: WSG and carbon.txt

Measurement is starting to get shared standards, which is worth knowing even though they’re early. The W3C’s Web Sustainability Guidelines reached finalised draft status in December 2025 and are on track to become a formal W3C specification around Earth Day 2026, structured much like the accessibility guidelines (WCAG) that came before them (W3C, 2026; University of Edinburgh, 2025). They’re advisory today, assessed by self-review rather than a formal test, but widely expected to become the shared benchmark for responsible web work — and possibly a legal one, if they follow WCAG’s path from guidance to requirement.

Alongside them sits carbon.txt, a plain-text file in the family of robots.txt and humans.txt that makes a site’s sustainability data discoverable, maintained by the Green Web Foundation. Its quiet power is procurement: when a contract requires a carbon.txt link before it pays out, transparency stops being optional (Green Web Foundation, 2026). Neither standard changes the underlying work, and we mention them without overstating how settled they are. But they’re worth noting for one reason: a lean, static site already meets most of what they ask for by construction, and can publish a carbon.txt for almost nothing. The standards are catching up to what building light already achieves.

Why our sites are low-carbon by construction — and the honest caveats

Stated plainly as our position: the sites we build are low-carbon by construction, because the architecture that makes them fast is the same one that makes them green. A static site with self-hosted, subset fonts, no third-party requests, almost no JavaScript and a top performance score has already stripped out the media bloat, script overhead and external calls that make up the bulk of most sites’ emissions — so it lands near the low end of the carbon range without any separate “sustainability” work. Pairing it with a renewable-powered host closes the remaining gap. It’s the same “does less” architecture that keeps a site fast and keeps its visitors’ data private, viewed through one more lens.

The honest gate here is important, because sustainability attracts more marketing than most topics. Carbon calculators are directional models that disagree, so we treat their numbers as comparisons rather than precise claims. “Green” hosting badges and tree-planting widgets can be substance or can be decoration, and we won’t hang an environmental claim on a badge we can’t stand behind. And Google has not made carbon a ranking factor, so we won’t pretend a low-carbon site ranks better for being low-carbon — it ranks better for being fast, which is the same thing by a different name. What we’ll do instead is build the lean site, put it on a host we can verify, and measure the result with you using the tools above, so any claim you make about it is one you can prove.

Sustainability is a property of doing less

Step back and website carbon turns out to be the same story as speed and privacy told a third way: the problem is excess, and the fix is restraint. A page is high-carbon for the same reason it’s slow and the same reason it leaks data — because it does more than it needs to, loading heavy media, running scripts, and calling out to third parties. Strip those away and all three problems shrink together, which is why you never really have to choose between a fast site, a private site and a green one. They’re the same site.

So the useful way to approach your website’s footprint is not to bolt on a sustainability programme but to build, or rebuild, for leanness: optimise the images, cut the scripts, self-host what you can, choose a renewable host, and measure honestly before and after. Do that and sustainability stops being a separate obligation or a marketing badge and becomes what it should be — a quiet consequence of a site built to do less, which is the same “do it right once” logic that runs through our guide on site speed and everything else we make.