The device in your pocket is doing more work than you think, and most of it is unnecessary.
Not because anybody designed it that way. Because the pages it loads carry things nobody asked for: images four times larger than the space they fill, scripts for tools that stopped being used, video playing behind a headline that could have been a photograph.
The website speed carbon footprint connection is simply that all of that unnecessary work has two costs. The visitor experiences one as slowness. The other is modelled as emissions: same cause, two symptoms.
Website speed and carbon: The Surprising Link
Why the website speed and carbon link holds
Speed isn’t a measure of environmental impact, and treating it as one is misleading. But the correlation is strong enough to be practically useful, because both follow from the same input.
A page that takes eight seconds on a mid-range phone is almost always sending too much or asking the device to do too much. Fix the underlying cause, and both figures move.
The exception worth knowing: website speed improvements achieved purely through caching or faster servers improve the experience without reducing transferred bytes on a first visit. So measure both rather than assuming one implies the other.
Three changes worth making first
- Serve images properly. Display dimensions, modern formats, lazy loading below the fold. On a site never reviewed, this alone frequently halves page weight and costs nothing visually.
- Delete third-party scripts nobody owns. List every external domain your page connects to and find someone accountable for each. The unclaimed ones are free to remove and there are usually several.
- Remove autoplay video. The heaviest common default on the web, and on a weak connection it is the difference between a page that arrives and one that does not.
Measure before and after under recorded conditions so you can attribute the improvement rather than guessing.
Inclusive design is the same work from another direction
This is the part most speed writing misses, and it is why this matters beyond a score.
The people most affected by heavy pages are the people already least well served: someone on a pay-as-you-go data plan, someone on a four-year-old handset, someone in a part of the county where coverage drops between villages.
A lighter page weight is not automatically an accessible one, and it is worth being precise about that. But the overlap is real. Semantic HTML reduces script dependence and gives assistive technology what it needs. Clear navigation reduces how many pages somebody has to load. Reduced motion lowers processing and helps people with vestibular conditions.
Work towards WCAG 2.1 Level AA on its own merits, and note that most of what it asks for also reduces what you send.
What to measure
Page weight, request count and Core Web Vitals on your most-visited pages, under stated conditions: which device, which connection, first or repeat visit.
Then a carbon estimate from the same pages with a named tool, understanding that these produce modelled figures rather than measurements and that different tools disagree.
Where performance and environmental impact both apply, treat them as the same lever: reducing unnecessary data transfer and processing supports a faster experience while lowering estimated digital carbon, though environmental figures remain modelled rather than directly measured.
Before you publish anything about it
Environmental claims must be accurate and substantiated. The Competition and Markets Authority’s Green Claims Code sets out what that requires.
Report what you measured, with which tool, under what conditions. Resist the temptation to reach for sector-wide comparisons, which are contested and rarely survive scrutiny from anyone who knows the literature.
Our website sustainability audits record speed and estimated carbon together, with the method documented.