Greener Software is Mostly Less Waste

Software sustainability gets vague very quickly if we let it.

It is easy to write about green technology as a brand position: care about the planet, choose responsible vendors, reduce your footprint, be better. None of that is wrong, but it is not very useful when a team is deciding whether to ship another tracking script, run a giant CI matrix on every commit, rebuild a site unnecessarily, or ask a large model to summarise something a cheaper process already structured properly.

The credible route into greener software is less theatrical.

It is mostly waste reduction.

Fewer wasted requests. Smaller pages. Better caching. Less unused JavaScript. Fewer pointless builds. Less noisy observability. More deliberate AI use. Infrastructure that is scaled for real demand rather than forgotten defaults. Product decisions that do not make every user pay for features only a tiny minority need.

That sounds like ordinary engineering because it is ordinary engineering. Sustainability does not need to replace performance, cost control, accessibility, or operational discipline. It should make those disciplines harder to ignore.

Carbon is Hard to Measure, Waste is Easier to See

The first caveat is measurement.

Most product teams cannot accurately calculate the exact carbon cost of every request, build, model call, dashboard query, or third‑party script. Cloud providers expose different data. Supply chains are complicated. Regional energy mix changes. A page view on one device and network is not the same as a page view on another. AI inference cost depends on model, provider, prompt size, output size, batching, hardware, and operational choices that are often hidden from the application team.

That does not make the problem imaginary. It means teams should be honest about what they can measure directly and what they can infer.

The Green Software Foundation's Software Carbon Intensity specification is useful here because it keeps the conversation tied to emissions per unit of software work rather than vague intent. Its green software patterns catalogue then turns that kind of thinking into more concrete interventions around demand, data, networking, workload, and infrastructure choices.

The W3C Web Sustainability Guidelines are useful for a complementary reason. They treat web sustainability as testable design and engineering work, while warning against both carbon tunnel vision and greenwashing. That matters because a software team can reduce one visible metric while still making poor choices about accessibility, device lifespan, privacy, or operational waste.

Most teams do not need to begin with a perfect SCI calculation. They can begin by finding obvious waste.

If a page ships hundreds of kilobytes of unused JavaScript, that is waste. If a build runs ten expensive jobs when only two are relevant, that is waste. If analytics tools send duplicate events because two teams added overlapping tags, that is waste. If a serverless function is invoked repeatedly because caching is wrong, that is waste.

Waste is not the whole sustainability story, but it is a very good place to start because it is visible, measurable, and usually expensive.

Performance Work is Sustainability Work

Performance has always had an environmental dimension. A lighter page usually means less network transfer, less CPU work, less battery drain, and less infrastructure pressure.

That is not the only reason to care. Slow pages lose users. Heavy pages hurt mobile experience. Poor interaction performance damages trust. Search visibility can suffer when pages are slow, unstable, or too dependent on late‑running scripts.

The sustainability point simply adds another reason to do the work properly.

Core Web Vitals give teams a useful user‑facing frame. Google's Core Web Vitals guidance focuses on loading, interaction, and visual stability. Those metrics are not carbon metrics, but they point teams towards wasted work users can feel: slow largest content, long input delays, layout shifts, and overloaded main threads.

That is why a Core Web Vitals regression after a redesign is not just a Lighthouse problem. It is often a product decision made visible in runtime behaviour: more scripts, heavier imagery, larger components, new fonts, extra layout work, or fragile data loading.

That is the practical shape of performance optimisation and Core Web Vitals work: find the expensive behaviour, connect it to user impact, and make the page lighter without pretending a single score is the whole product.

Good performance work asks:

• what work happens before the user can see or do anything useful?
• which assets are needed on this route?
• which scripts are global only because that was convenient?
• what can be cached safely?
• which images are oversized for their slots?
• which components render before they are needed?
• which interactions are paying for state or data they do not use?

Those are also sustainability questions.

Front‑End Weight is a Product Decision

JavaScript weight rarely appears by accident. It accumulates through decisions.

A chat widget here. A tag manager there. A consent tool with default settings. A personalisation library on every route. A design system component that imports more than it needs. A client‑side dashboard embedded where static content would do. A small A/B test that never gets removed.

The front end becomes a landfill of good intentions.

That is why third‑party script cost needs route‑level ownership, and why third‑party script performance optimisation should be treated as product governance rather than tag cleanup. Some scripts are valuable. Some are legally or commercially necessary. Some are dead weight. The work is not to ban everything. It is to decide what each route can afford.

A service enquiry page, checkout, article, logged‑in account page, and campaign landing page do not have the same budget. They do not need the same scripts. They do not have the same user intent.

If every route loads everything, the architecture is choosing convenience over cost.

Caching is a Sustainability Lever

Caching is one of the least glamorous sustainability tools in software.

Done well, it avoids repeated work. It reduces server load, database calls, API requests, render cost, and user wait time. Done badly, it serves stale content, hides bugs, creates invalidation confusion, and makes teams afraid to trust their own platform.

The sustainability version of the question is simple: why are we doing this work again?

That applies at several layers:

• CDN and edge caching for stable public assets
• browser caching for versioned files
• data caching for expensive reads
• static generation where content does not need request‑time rendering
• incremental regeneration where freshness and cost need balancing
• memoisation only where profiling shows repeated expensive work
• build caching for CI and deployment pipelines

Caching should not be used to hide slow architecture indefinitely. But if a system repeatedly recalculates, refetches, rerenders, or transfers the same stable thing again, it is wasting time, money, and compute.

That is the same practical discipline behind front‑end performance budgets. A budget is not a moral statement. It is a way to stop cost from becoming invisible.

CI and Build Pipelines Have a Footprint Too

Engineering teams often treat CI cost as background noise.

Every commit triggers install, lint, type checks, unit tests, integration tests, previews, visual checks, security scans, static analysis, container builds, deployment steps, and notifications. Some of that work is essential. Some of it is duplicated. Some of it runs far more often than it needs to. Some of it exists because nobody removed old checks after the stack changed.

If a full expensive pipeline runs on every small documentation edit, that may be wasted effort. If a preview deployment builds every route and image derivative when the changed file cannot affect them, that may be wasted effort. On a Next.js or Vercel‑style workflow, the problem can be as simple as regenerating content routes for a copy‑only change that cannot affect the rendered app, or rerunning image processing because a cache key is too broad or too fragile. If a flaky test forces repeated reruns, that is waste with a quality problem attached.

Validation should stay strong. Bad software is waste too. Bugs cause rework, incidents, support contact, duplicated investigation, and user frustration.

The point is to make validation proportional:

• run narrow checks for narrow changes
• cache dependencies and build artefacts safely
• split expensive suites by risk
• remove dead jobs
• make flaky tests visible and owned
• avoid rerunning the same work because the pipeline cannot tell what changed

Sustainability and delivery economics overlap here. Less unnecessary CI work usually means faster feedback and lower cost before it means a greener badge.

Observability Can Become Noise with a Bill

Logs, traces, metrics, replay tools, analytics, and alerting systems are essential in production systems. They are also easy to overproduce.

If every minor event becomes a high‑cardinality metric, every request logs large payloads, every browser session records too much, and every service emits traces nobody reads, the observability stack becomes another source of waste.

Worse, noisy observability makes incidents harder to understand. Teams pay for data volume and still struggle to find the signal.

Useful observability is deliberate:

• log what helps diagnose real failures
• sample where full fidelity is not needed
• protect personal and sensitive data
• define retention periods
• review dashboards that nobody opens
• make alerts actionable
• remove duplicate instrumentation

The environmental case is not separate from the operational one. If the data does not help someone make a better decision, why are we storing it?

AI Compute Should Be Used Deliberately

AI complicates the sustainability conversation because the useful work and the waste can look similar from the outside.

A model can save hours of human effort. It can also be used lazily for tasks that a smaller model, retrieval system, rules‑based workflow, template, cache, or better content structure would handle more cheaply and predictably.

Before making a large model the default path, I would check:

• does this task need a large model?
• can the prompt be shorter without losing necessary context?
• can repeated context be cached or retrieved more selectively?
• can a smaller model handle classification or routing?
• can deterministic code handle the final transformation?
• can the system avoid regenerating answers that do not change?
• can the user approve once rather than forcing repeated model calls?

This is not anti‑AI. It is pro‑engineering.

The International Energy Agency's 2025 report on Energy and AI is a useful antidote to vague thinking here. It frames AI as an energy and infrastructure question, not just a software capability question. That does not mean every model call is irresponsible. It does mean model choice, prompt size, retrieval strategy, caching, and default product behaviour are engineering decisions with cost beyond the invoice.

The article AI will be OK if we stop treating it like magic makes the broader point: AI becomes healthier when it is treated as real technology. Real technology has cost, latency, failure modes, security boundaries, and support requirements.

Product Teams Need to Own Demand

Engineering can optimise a lot, but product decisions create demand.

Infinite scroll loads more content. Personalisation multiplies variants. Rich media increases transfer. Dashboards query constantly. Notifications trigger downstream workflows. Search‑as‑you‑type calls APIs on every keystroke. Realtime features keep connections open. AI assistants summarise everything because the interface made that the default action.

Sometimes those choices are right.

But they should be choices, not defaults nobody priced. A feature that increases compute, transfer, and operational support should be able to explain the user value it creates.

The FinOps Foundation framework is useful as a parallel discipline. Cloud cost is not only an infrastructure problem. It is a product, engineering, and finance collaboration problem. The same is true of software sustainability. Teams need shared visibility into cost and demand, otherwise the easiest route is always to consume more.

Wrapping Up

Greener software is not mostly about saying the right thing on an about page.

It is about reducing wasted work in the systems users actually touch and the systems teams use to build them. Lighter pages. Fewer unnecessary requests. Better caching. Leaner pipelines. More useful observability. Deliberate AI use. Infrastructure and product choices that treat compute as something with cost, not an infinite background supply.

That work is plain, but credible.

If a team cannot explain why a page is heavy, why a build runs, why a model is called, why a script loads, or why data is stored, it probably cannot make a serious sustainability claim about that system.

Key Takeaways

• Perfect carbon measurement is hard, but visible software waste is still worth reducing.
• Performance work often reduces network, CPU, battery, infrastructure, and user‑experience cost together.
• Front‑end weight is usually a product and governance decision, not just an engineering accident.
• Caching reduces repeated work when invalidation and freshness are designed properly.
• CI pipelines should validate proportionally rather than rerun expensive work by default.
• Observability should produce useful signal, not expensive noise.
• AI compute should be used deliberately, with model size, prompt length, caching, and deterministic alternatives considered.
• Sustainable software is an engineering constraint, not a brand claim.