Why a fast website is a low-carbon website
Speed and carbon are the same problem wearing two labels. Both come down to how much a page makes a device fetch, run and render. Here is how we build light, and how we measure it honestly.
Speed and carbon are the same problem
It is tempting to treat website carbon as a separate, slightly worthy concern, bolted on next to performance. It is not. The thing that makes a page slow is, almost always, the thing that makes it carbon-heavy: it asks a device to fetch too many files, run too much code and repaint the screen too many times before it settles. A megabyte of unused JavaScript is a megabyte that has to travel down a network, sit in memory and be parsed by a processor, whether that processor is in a data centre, a phone mast or the phone in someone's hand. Each of those steps draws power. So when we make a page faster, we are not doing two jobs. We are doing one job that happens to pay out in two currencies: milliseconds for the person waiting, and grams of CO2e for everything else. The useful mental model is that the internet is not weightless. Every visit moves real data across real infrastructure that runs on real electricity, much of which is still generated by burning something. The heavier and busier your page, the more of that machinery it wakes up, and it does so on every single visit, not once. A site that is visited ten thousand times a month pays its weight ten thousand times over. That repetition is exactly why front-end decisions matter more than they look: a saving that seems trivial per page becomes substantial once you multiply it by an audience.
Where the weight actually comes from
In practice, the biggest offenders are predictable. Images are usually first: photographs shipped at two or three times the dimensions they are displayed at, in formats a decade out of date, with no consideration of the screen requesting them. Then comes JavaScript, and specifically JavaScript that runs on the visitor's device to build a page that could have been built once, on the server, and sent as finished HTML. Third-party scripts are the quiet third: analytics, chat widgets, tag managers, embeds and marketing pixels, each of which drags in its own payload and often its own further requests, none of which you fully control. A page can be beautifully coded and still be heavy because it invited a dozen guests who each brought luggage. None of this is exotic to fix. Right-sizing images and serving modern formats removes a large fraction of the weight on most sites before you touch anything clever. Being honest about which third-party scripts earn their place, and loading the survivors without blocking the page, removes another slice. And choosing a rendering approach where the server does the heavy lifting once, rather than shipping the work to every device, changes the baseline rather than trimming the edges. The point is that building light is not a special discipline. It is ordinary engineering care, applied to questions people often skip.
How we build light, in the front-end
Our default is to send the browser as close to finished HTML as we can, and to add interactivity only where interactivity genuinely earns it. That means server-rendered pages, with JavaScript reserved for the parts of an interface that actually need to respond in real time, rather than shipped wholesale to reconstruct static content the visitor was always going to see. It is a large part of why we build production sites on Next.js: it makes the light path the natural path, letting the server render and the browser receive, instead of asking every device to assemble the page from parts. The framework is not the point, though. The discipline is: do the work once, in a place with efficient hardware and, where we can arrange it, clean power, rather than thousands of times on hardware and grids we do not choose. Alongside that sit the unglamorous habits that do most of the work. Images sized and compressed for the container that holds them. Fonts subset and served locally so a page is not held hostage by a third party's server. Scripts audited so the ones that survive are loaded deferentially rather than blocking the first paint. Layout reserved ahead of time so content does not jump as it loads, which is both a courtesy to the reader and a measured performance signal. Individually these are small. Together they are the difference between a page that lands cleanly and one that thrashes a device for two seconds before it is usable.
The honest measurement
The environmental angle attracts a lot of vague, unfalsifiable marketing, and we would rather not add to it. So when we talk about a page's carbon, we mean a number produced against a published method: the Sustainable Web Design model, which estimates grams of CO2e per visit from the data a page actually transfers and maps it onto a rating scale from A+ down to F. It is an estimate, and we say so, but it is an estimate anyone can reproduce and check, which is the whole difference between measurement and assertion. A grade is only worth showing if the reasoning behind it is in the open. Ours is published, so a claim we make about a page is a claim you can audit rather than take on trust. The same honesty applies to hosting. Plenty of sites claim to run on green energy; far fewer can point to a verification. We only make the green-hosting claim for a domain when an independent check, the Green Web Foundation's register, actually confirms the host runs on renewable power. If the check does not confirm it, we do not say it. That restraint matters more than it sounds, because the credibility of the whole exercise collapses the moment one number turns out to be decorative. A footprint you can trust is worth more than a flattering one you cannot.
Why this is not a trade-off with performance
The reassuring part, and the reason we are comfortable putting effort here, is that lowering a page's carbon does not cost you speed or ranking. It buys them. The work that reduces weight is, almost line for line, the work that improves Core Web Vitals: less to download improves loading, less script to execute improves interactivity, reserved layout improves visual stability. Those are the signals Google measures as part of page experience, and they are also, more importantly, what a visitor feels as the difference between a site that responds and one that makes them wait. So the environmental case and the commercial case point the same direction, which is a rare and pleasant thing. That is worth stating plainly because sustainability is too often framed as a sacrifice, a good deed you pay for in convenience or results. On the web it usually is not. A lighter page loads faster, converts better, costs less to serve and, yes, emits less. You do not have to care about the carbon for the engineering to be worth doing, and you do not have to sacrifice results to care about the carbon. The two align because they share a root cause, and once you see that, building light stops being a moral choice and becomes simply the better way to build.