Yes. Every page view moves data through data centers, networks, and the visitor's own device, and all three consume electricity. The heavier the page, the more energy it takes to deliver. A lighter site uses less power for exactly the same reason it loads faster.
This is the part that surprises people. Reducing a site's carbon footprint is not a separate project bolted onto a build. It is the same work as making the site fast, done with a second reason to do it properly. Smaller images, less JavaScript, fewer requests, better caching. The list is identical.
We like this framing because it makes the argument easier with clients who do not care about sustainability. You do not have to sell them on the environment. You sell them on speed and conversion, and the carbon saving comes along for free.
Most tools use the Sustainable Web Design Model, an open methodology now on version four. It estimates the energy used to transfer a given amount of data, splits that energy across the parts of the system, then multiplies by the carbon intensity of the electricity involved. Data transfer is the main input.
The model is a collaboration between Wholegrain Digital, Mightybytes, Footsprint, EcoPing, and the Green Web Foundation. Its fourth version divides operational energy across three segments, allocating 22% to data centers, 24% to networks, and 54% to user devices. That split is the single most useful thing in the whole model.
Look at where the energy actually goes. More than half of it is spent on the visitor's phone or laptop, decoding your images, parsing your JavaScript, and rendering your layout. Hosting choice matters, but what you ship to the browser matters more.
The model uses energy intensities of 0.055 kWh per gigabyte for data centers, 0.059 for networks, and 0.080 for user devices, then applies a global average carbon intensity of 494 grams of CO2 per kilowatt hour drawn from Ember's Data Explorer. You can substitute a regional figure if you know where your traffic comes from.
Because nothing forces them to get lighter. The HTTP Archive Web Almanac reported in 2025 that the median mobile home page reached 2.6 MB, growing 8.4% from 2.4 MB the year before. Desktop reached 2.9 MB, up 7.3%. Every year the number goes up.
The long view is worse. The same Web Almanac chapter notes that in July 2015 the median mobile home page was 845 KB, and by July 2025 it was 2,362 KB, an increase of 202.8% over the decade. Connections got faster, so nobody noticed, and the weight quietly tripled.
The breakdown tells you where to look. On desktop home pages the Web Almanac put median image weight at 1,058 KB and median JavaScript at 697 KB. Images and scripts are the two things worth fighting about. Everything else is rounding.
Images, almost always. They are the largest share of median page weight, and they are the easiest thing to fix without touching how the site works. Serving modern formats at the right dimensions, with proper lazy loading below the fold, routinely removes more weight than any other single change.
The common failure is uploading a 4000 pixel wide photograph and letting CSS scale it down to 600 pixels. The browser still downloads the whole thing. Modern formats like AVIF and WebP make the same picture dramatically smaller, and responsive image markup lets a phone download a phone-sized file instead of a desktop one.
We go through the whole process in our guide to image optimization for web performance. The carbon angle changes none of the technique. It just raises the stakes on getting it right.
More than its file size suggests. A megabyte of images gets decoded once. A megabyte of JavaScript has to be downloaded, parsed, compiled, and executed, and it keeps costing energy while the page is open. Given that user devices carry 54% of the energy in the model, script weight hits hardest where the model says it matters most.
This is the argument we make against loading a heavy framework onto a marketing site that could be static HTML. The framework is not wrong. It is simply expensive for a page whose job is to explain a product and collect an email address.
The audit is straightforward. Open the network panel, sort by size, and ask what each script is for. In most builds we look at there are two or three tags nobody can explain, usually a tool that was trialed once and never removed. Deleting those is the fastest weight loss available to most sites.
It helps, and it is not the whole answer. The Sustainable Web Design Model puts 22% of operational energy in the data center, so moving to a provider running on renewable energy addresses roughly a fifth of the picture. It is a real improvement, and it is a one-time decision rather than ongoing work.
The Green Web Foundation runs a public Green Web Check that tells you whether a given domain is hosted on green energy, backed by a dataset of hosting providers and a directory of verified green providers. Checking your own domain takes about ten seconds and is a reasonable first step.
They also publish CO2.js, a library for calculating digital emissions, and a Carbon.txt standard for disclosing carbon information. If you want to put a real number on your site rather than a rough estimate, those are the tools to start with.
Hosting choice sits alongside the other decisions we walk clients through in our guide to choosing web hosting. Renewable energy is one more column in that comparison, not a replacement for the rest.
Yes, on both counts. A file served from cache moves no data at all, which is the cleanest possible outcome. A file served from a nearby edge location travels a shorter distance through fewer network hops. Both reduce the network share of the model, and both make the site faster at the same time.
Long cache lifetimes on fingerprinted assets are close to free. Your CSS, fonts, and images barely change between deployments, so there is no reason for a returning visitor to download them again. Getting this right is often a single configuration change with a permanent payoff.
Video deserves special mention because it dwarfs everything else. An autoplaying background video can outweigh the entire rest of the page many times over. If a client insists on one, we compress it hard, cap its length, and never autoplay it on mobile. Often the honest conversation is whether a still image would do the same job.
Set a performance budget and check it on every deploy. A page that launches at 800 KB drifts to 2 MB over two years, one marketing tag at a time, unless something pushes back. The budget is what turns "we should keep this light" into a rule someone has to argue against.
Make the budget specific and boring. A maximum total page weight, a maximum JavaScript size, and a maximum number of third-party requests are enough. Wire it into your build or your testing so a breach shows up before launch, not six months later in an audit.
We cover how to set realistic numbers in our guide to performance budgets. The exact thresholds matter less than having any threshold at all.
Use it as a direction, not a fact. Tools like the Website Carbon Calculator produce an estimate from a model with published assumptions, and the model authors are open about that. It is useful for showing improvement over time on the same site. It is much weaker as an absolute claim in a marketing deck.
Our advice to clients is to report the input rather than the output. Saying the home page dropped from 2.4 MB to 700 KB is a fact you measured. Saying it now emits a specific number of grams per visit is an estimate stacked on several other estimates, and someone will eventually ask you to defend it.
Being careful here also protects you. Environmental claims attract scrutiny, and rightly so. A measured reduction in page weight is defensible. A precise carbon figure with no methodology attached is not.
Measure your current page weight, then fix your images. Those two steps take an afternoon and usually remove more weight than everything else combined. After that, audit your third-party scripts, set a performance budget, and check whether your host runs on renewable energy.
The reason we like this work is that it never involves a trade-off. Nobody has to choose between a fast site and a sustainable one, or between a beautiful site and a light one. The craft that produces one produces the others, which is why we build this way regardless of whether a client asks for it.
If you want an honest read on how heavy your site is and what is causing it, let's talk. We're happy to walk through the numbers with you at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.