Green Computing: Reducing Your Digital Carbon Footprint

Where the energy actually goes

Energy is consumed at three points: the data centre serving the request, the network moving the bytes, and the device rendering the result. The third is easy to forget and frequently the largest, because it is multiplied by every visitor.

A heavy JavaScript bundle does not just cost transfer. It costs parse and execution energy on every device that loads it, which on a low-end phone is a substantial and repeated draw.

Page weight is the lever you control

Images are usually the largest single contributor, and modern formats at appropriate dimensions typically cut that substantially for no visible quality loss.

JavaScript is the second, and it is worse per byte because of the execution cost. Every dependency you remove reduces transfer and computation on every device, forever.

• Serve modern image formats sized to their display dimensions.
• Lazy-load anything below the fold.
• Subset fonts to the characters actually used.
• Audit dependencies regularly and delete what is unused.
• Cache aggressively — the greenest request is the one never made.

Efficient measurement counts too

Analytics scripts are loaded on every page of every site that uses them, so their weight is multiplied enormously across the web.

This is a large part of why we hold our tracking script under 2 kB. At that scale the difference between a 2 kB script and a 45 kB one is not a rounding error, it is a meaningful aggregate energy cost imposed on every visitor.

Choose infrastructure deliberately

Providers differ substantially in the carbon intensity of the electricity they use, and many publish region-level figures. Choosing a low-carbon region is often a configuration decision with no performance penalty.

Edge caching helps for the same reason it helps latency: serving from close by moves fewer bytes across fewer network hops.