Greener Website Code: Build Lighter, Faster Web Sites

Greener website code, The Carbon Cost of JavaScript

There is a particular kind of website that scores well in a design review and badly on a train.

It looks considered. The typography is careful, the spacing is generous, the photography is good. Then you open the network panel and find eleven hundred kilobytes of JavaScript, four font families and a stylesheet where roughly nine per cent of the rules are ever applied.

Greener website code is the work of closing that gap. Not making the site look different. Making it stop sending things nobody uses.

Greener website code starts with what you delete

Most sites ship a stylesheet built for a template rather than for the pages they actually have. Rules for components that were removed, for a layout variant nobody chose, for a theme’s demo content.

It is quiet because it rarely feels slow in an obvious way. It is still downloaded, parsed and evaluated on every page by every visitor.

Coverage tools in browser developer panels will show you how much of your CSS and JavaScript is actually used on a given page. The first time most teams run this, the result is uncomfortable.

JavaScript costs more than its file size

A hundred kilobytes of image is downloaded and decoded. A hundred kilobytes of JavaScript is downloaded, parsed, compiled and executed, and on a mid-range phone that final step is where the delay becomes visible.

Audit dependencies rather than accumulating them. The recurring pattern is a library imported for one function, a framework carrying features the site never touches, and polyfills for browsers nobody has used in years.

Prefer the platform where it will do the job. Semantic HTML gives keyboard operation and assistive technology support with no script at all. A `<button>` is focusable and announced correctly; a styled `<div>` is neither until you rebuild both by hand.

CSS now handles transitions, layout, sticky positioning and container queries natively, and it does so in optimised browser code paths rather than in your bundle.

Third-party scripts are somebody else’s code on your page

Every external tag is a connection to a domain you do not control, executing code you have not reviewed, on a schedule you cannot predict.

List every external domain your highest-traffic page connects to, then find an owner for each. The ones nobody can account for are your easiest win, and there are usually several: analytics added twice by different teams, tags for campaigns that ended, a chat widget nobody staffs.

Removing these costs nothing and frequently accounts for a meaningful share of both weight and delay.

Media, sized properly

Images dominate page weight on most sites. Serve them at the dimensions they display at, in modern formats, and load anything below the fold only when needed.

Fonts deserve a budget of their own. Two families at most, subset to the characters you use, with a readable fallback so text appears while a custom face loads.

What this actually buys you

A faster site, first and most reliably. 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 those environmental figures remain modelled rather than directly measured.

Be careful about the size of the claim. A single site’s code improvements are a small contribution in absolute terms, and inflating that into planetary significance invites the scepticism it deserves. The honest version is that the work is cheap, it makes your site better, and the environmental effect is real but modest.

The W3C Web Sustainability Guidelines cover the practices across development and hosting decisions.

Where hosting fits

Renewable-powered hosting changes the emissions profile of the server portion. It does not affect what your pages send, which governs network transfer and the work done on the visitor’s device.

Treat it as one of three levers rather than the answer. An agency whose sustainability offering is essentially a hosting recommendation is selling you a third of the work.

Our sustainable web development work starts by measuring what a site actually ships.

Most common questions

01

What makes greener website code different from ordinary optimisation?

Shipping less of it. Removing unused CSS and JavaScript, auditing dependencies, cutting unaccounted third-party scripts and preferring browser-native solutions. The result is a faster site, with lower estimated energy use per visit as a secondary effect.

02

How do I find unused code on my site?

Use the coverage tools in your browser's developer panel on your highest-traffic pages. They show how much of each stylesheet and script is actually executed. Check several page types, since a rule unused on one page may be essential on another.

03

Is JavaScript bad for sustainability?

Not inherently, but it is the most expensive payload byte for byte because it must be parsed, compiled and executed rather than simply rendered. The question is whether each dependency earns its download and its maintenance cost, not whether to avoid the language.

04

Does semantic HTML actually make a difference?

Yes, in two ways. It removes the need for scripts that rebuild behaviour browsers already provide, and it gives assistive technology what it needs by default. Efficiency and accessibility improve together, which is why it is worth doing first.

05

Can I claim environmental benefits from code improvements?

Only in terms you can substantiate. Report what you measured, with which tool, under what conditions, and what changed. Carbon figures from estimation tools are modelled rather than measured, and describing them otherwise is inaccurate.

06

Where should a developer start on an existing site?

Run coverage analysis and list external domains on the highest-traffic page. Unused code and unaccounted third parties are usually the largest wins and the least disruptive, since neither requires design changes or stakeholder negotiation.