Digital Waste: How to Clean Up Website Energy Usage

Digital Waste - How to Clean Up Your Website’s Energy Usage

Waste in the physical world announces itself. The overflowing bin, the van idling outside, the skip on the drive.

Digital waste does none of that. Nobody sees the two-megabyte image being scaled down in a browser, or the tracking script loading for a campaign that ended in March, or the video autoplaying behind a headline that nobody watches. It costs your visitors data, battery and patience, and it costs you nothing visible at all, which is precisely why it accumulates.

Finding it takes about twenty minutes. Fixing most of it takes an afternoon.

What digital waste actually looks like

  • Oversized media. Images served at four times their display dimensions. Video autoplaying on arrival. Photography exported straight from a camera and uploaded without a second thought.
  • Unused code. Stylesheets built for a template where most rules never apply. Libraries imported for one function. Polyfills for browsers nobody has used in years.
  • Abandoned third parties. Tags for analytics nobody reads, chat widgets nobody staffs, testing tools from a trial that lapsed. Each opens connections and executes code on every single visit.
  • Content nobody reads. Campaign pages that ended, duplicate explanations of the same service, an archive nobody has opened since 2021. Stored, served and crawled indefinitely.
  • Repeated journeys. Navigation so unclear that people load four pages to find what one should have given them. Every avoided page load is transfer that never happened.

Finding yours

Open your highest-traffic page in a browser’s network panel with the cache disabled, and sort by size.

Almost everyone finds the same thing: the top ten requests are images, and most are wrong in one of three ways. Then a list of external domains, several of which nobody can account for.

Use the coverage tools in the same panel to see how much of your CSS and JavaScript is actually executed on that page. The first time most teams run this, the result is uncomfortable.

Record the totals before you change anything: page weight, request count and Core Web Vitals, under stated conditions. Without a baseline, you can assert an improvement but not demonstrate one.

Clearing it, in order

  1. Images. Serve at display dimensions in modern formats, lazy-load below the fold, and remove autoplay video. Largest single win on most sites, no design compromise.
  2. Third parties. List every external domain, find an owner for each, delete the ones nobody claims. Costs nothing.
  3. Fonts. Two families at most; subset to the characters you use.
  4. Code. Audit dependencies and prefer browser-native solutions where they will do. Most effort, so last.
  5. Content. Archive expired campaigns, consolidate genuine duplication, and check accessibility and record-keeping needs before removing anything.

Re-measure after each step so you know what earned the improvement.

What this buys, stated carefully

A faster site, reliably and immediately.

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.

On search, faster and lighter pages help with mobile usability and crawl efficiency. That contributes rather than guarantees, and anyone promising ranking improvements from weight reduction alone is overstating it.

Accessibility sits alongside this, not underneath it

The practices overlap substantially. Semantic HTML reduces script dependence. Clear navigation reduces how many pages somebody loads. Text alternatives keep content usable when media fails.

What is not true is that accessibility automatically reduces carbon, or that a lighter page is automatically accessible. They are separate goals served by many of the same actions, and conflating them overstates both.

Work towards WCAG 2.1 Level AA on its own merits and take the efficiency overlap as a bonus.

WCAG 2.1 AA infographic of each level.

Stopping it coming back

An afternoon’s clean-up buys about a year without controls.

Set a page weight budget and enforce it. Give new third-party tools an owner and a review date. Give editors guidance on image sizes, because most regression arrives through the content management system.

Then re-measure quarterly. Drift is invisible without a comparison.

If you publish anything about the result, describe what you measured, with which tool, under what conditions. Environmental claims must be accurate and substantiated.

Our website sustainability audits produce that documented baseline.

Most common questions

01

What counts as digital waste?

Oversized media, unused code, abandoned third-party scripts, content nobody reads and journeys that force unnecessary page loads. All of it costs visitors data and time while remaining invisible to the site owner.

02

How do I find it on my site?

Open your busiest page in a browser network panel with cache disabled and sort by size, then use the coverage tools to see how much CSS and JavaScript actually executes. Twenty minutes usually surfaces most of it.

03

What is the quickest thing to remove?

Third-party tags nobody can account for. They cost nothing to delete, require no design decisions and frequently account for a meaningful share of both weight and delay.

04

Does removing digital waste improve search rankings?

It helps with mobile usability and crawl efficiency, which contribute. It is not a direct ranking lever, and removing useful content to reduce weight would cost more than the speed gains return.

05

Is an accessible website automatically a low-carbon one?

No. The practices overlap substantially, since semantic markup and clear navigation serve both, but neither guarantees the other. Pursue accessibility on its own merits and treat the efficiency overlap as a useful coincidence.

06

How do I stop the waste returning?

An enforced page weight budget, an owner and review date for every third-party tool, and editor guidance on image sizes. Most regression arrives through ordinary content work rather than development, so that is where the controls belong.