A slow website is not slow because it is dirty. It is slow and carbon-heavy for the same underlying reason, which is that it sends and processes more than it needs to.
That distinction sounds pedantic, and it changes what you do about it. If you believe slowness causes emissions, you optimise for speed scores. If you understand that weight causes both, you go after the weight, and the speed follows along with the estimate.
The carbon cost of slow websites is really the carbon cost of unnecessary bytes and unnecessary processing, measured at every visit.
Carbon Cost of Slow Websites: What to Measure First
1. Where the energy is actually drawn
Three places, and they respond to different decisions.
- The visitor’s device parses, renders and executes what you send. Heavy JavaScript is expensive here, and on an older phone the cost is felt as heat and battery drain before it registers as delay.
- The network carries every byte. This scales directly with page weight, which makes it the portion most within a designer’s control.
- Your hosting draws power continuously. Estimates commonly attribute a minority share of a website’s total footprint to hosting, though the figure varies by methodology and provider, so treat any specific percentage as indicative rather than settled.
Multiply all three by your monthly traffic and the arithmetic becomes clearer: a site with modest traffic and a heavy homepage may be worse than a busy site built lean.
2. What “measurable carbon cost” honestly means
Carbon estimation tools calculate from page weight and assumptions about energy intensity, network transfer and hosting. They are models, not meters.
Two tools will disagree about the same page, sometimes considerably, because their assumptions differ. That is not a flaw to be embarrassed about, it is what modelling is.
So use one consistently, state which, record the test conditions, and treat the trend as more meaningful than the absolute figure. Reducing unnecessary data transfer and processing supports a faster experience while lowering estimated digital carbon, though those environmental figures remain modelled rather than directly measured.
3. Measure before you change anything
Record page weight, request count and Core Web Vitals for your most-visited pages, noting the device, the connection and whether it is a first or repeat visit.
Without that baseline you can assert an improvement but not demonstrate one, and demonstrating one is the entire point if anybody is going to ask.
Then take a carbon estimate from the same pages under the same conditions, so the two datasets describe the same thing.
4. What to fix, in order
- Images. Almost always the largest share. Wrong dimensions, dated formats, eager loading of things nobody scrolls to. No design compromise required.
- Third-party scripts. Usually second. Most sites carry tags for tools abandoned a year ago, each opening connections and executing code on every visit.
- Fonts. Two families at most, subset to the characters used.
- JavaScript. The most expensive payload byte for byte, since it must be parsed, compiled and executed rather than simply rendered. Also the most effort, which is why it comes last.
Re-measure after each change so you know what earned the improvement rather than guessing.
5. Accessibility reduces waste too
The overlap is genuine rather than convenient.
Clear navigation reduces how many pages somebody loads to find what they need, and every avoided page load is transfer and processing that never happened. Semantic HTML reduces script dependence. Text alternatives mean content is usable when media fails.
Work towards WCAG 2.1 Level AA. Accessibility does not automatically reduce carbon, and claiming it does overstates the case, but the practices substantially overlap and both are served by the same work.
Before you publish any of this
Environmental claims must be accurate and substantiated. Describe what you measured, with which tool, under what conditions, and what changed.
“We reduced our homepage from 3.6MB to 820KB, measured with a named tool on a stated connection” is defensible and more persuasive than a percentage nobody can check.
Our website sustainability audits produce exactly that baseline, which is what makes later claims safe to make.