A hundred kilobytes of image and a hundred kilobytes of JavaScript are not the same hundred kilobytes.
The image is downloaded and decoded. The JavaScript is downloaded, parsed, compiled and executed, and every one of those steps costs processor time on a device you do not control. That is why the carbon cost of JavaScript is disproportionate to its file size, and why it is the most expensive thing you can put on a page.
None of which is an argument against JavaScript. It is an argument for knowing what you are spending.
Carbon Cost of JavaScript: How to Cut Unnecessary Code
1. Where the bloat actually comes from
Four sources, in roughly the order they appear.
- Libraries imported for one function. A date formatting library for a single date. A utility library for two helpers the platform now provides natively.
- Frameworks carrying more than the site uses. A component framework on a page with no interactivity, shipping a runtime to render text that HTML would have rendered.
- Third-party scripts. Analytics, chat widgets, tag managers, testing tools, remarketing pixels. Each one is code you have not reviewed, executing on every visit, from a domain you do not control.
- Polyfills nobody needs. Compatibility code for browsers that have not been in meaningful use for years, still shipped because nobody revisited the build configuration.
The pattern is that none of these were bad decisions. They were reasonable decisions nobody returned to.
1. Finding yours
Open your busiest page in a browser’s network panel, cache disabled, and filter to scripts. Note the total and the largest individual files.
Then use the coverage tool in the same panel, which shows how much of each script actually executes on that page. Most teams find this uncomfortable the first time, because the proportion of unused code is usually higher than expected.
Record the conditions: which device, which connection, first or repeat visit. Without them, the numbers are not comparable to anything, including your own later measurements.
3. Cutting it without breaking things
- Audit dependencies before adding. Ask what problem each solves and whether the platform now solves it. A surprising number of utility libraries answer questions browsers answered years ago.
- Prefer the platform. Semantic HTML gives you keyboard operation and assistive technology support with no script. CSS handles transitions, layout, sticky positioning and container queries natively, in optimised browser code paths rather than in your bundle.
- Split and defer. Load what the page needs now, and load the rest when it is needed. A checkout script has no business executing on a blog post.
- Audit third parties ruthlessly. List every external domain and find an owner for each. Unclaimed ones cost nothing to remove and frequently account for a meaningful share of both weight and execution time.
- Remove rather than optimise. Minifying code you should have deleted is effort spent in the wrong place.
4. The accessibility connection, stated properly
Less script frequently means better accessibility, because native elements come with keyboard support and assistive technology semantics built in. A `<button>` is focusable and announced correctly; a styled `<div>` is neither until somebody rebuilds both by hand, usually incompletely.
That is a genuine overlap rather than a causal relationship. Reducing JavaScript does not make a site accessible, and an accessible site is not necessarily light. Work towards WCAG 2.1 Level AA on its own terms and take the efficiency benefit as a bonus.
What the reduction gives you
Faster rendering and better responsiveness, felt most on the mid-range phones where a large share of your visitors actually are. Interaction to Next Paint in particular improves when there is less script competing for the main thread.
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.
Then set a bundle size budget and enforce it in your build process, because dependencies accumulate through ordinary development and manual vigilance stops working within months.
Our website sustainability audits include script and coverage analysis, which is usually where the largest unused payload turns up.