A carbon footprint measures the total greenhouse gases produced by an activity, product, person, or system. Expressing it as CO2 equivalent makes carbon dioxide, methane, and nitrous oxide comparable in one unit. For software, the useful engineering question is not whether code is elegant or fast alone, but how its resource use drives electricity demand, hardware use, and environmental cost. section 8.2.1 section 8.3
Digital emissions have two main sources. Operational emissions depend on electricity consumption and the carbon intensity of the regional grid. Embodied carbon covers manufacturing, transport, and end-of-life processing of hardware. Keeping devices in service through repair, reuse, or repurposing spreads this upfront cost over a longer lifetime; software can also cause premature replacement when support ends or requirements exceed working hardware. section 8.2.1 section 8.2.2
Figure 8.2 Using the two levers of sustainability: electricity and hardware usage
Reducing a software footprint means acting on two levers: consume less electricity and require less hardware. These levers guide code-level choices as well as infrastructure decisions. section 8.4
A software footprint cannot be computed exactly from source code. Electricity entering a grid cannot be traced to a particular generation source, and user-side power conditions are similarly uncertain. Estimates therefore combine assumptions and public emission factors. Software Carbon Intensity (SCI), standardized as ISO/IEC 21031:2024, considers electricity consumed, regional carbon intensity, and hardware’s embodied footprint, then normalizes the result by a functional unit such as a request, transaction, user, batch job, or gigabyte processed. section 8.5.1
Use estimates as decision support rather than claims of exact measurement:
- Check deployed cloud usage with provider reporting, such as AWS Customer Carbon Footprint Tool, or install server software that estimates operational emissions. section 8.5.1
- Estimate a web page’s client-side impact from page weight, request count, and DOM complexity with Website Carbon Calculator or GreenIt Analysis. section 8.5.2
- Flag resource-wasting patterns before execution through static analysis; Creedengo supports several languages through SonarQube. section 8.5.2
- Measure efficiency proxies with microbenchmarks and profilers, examining CPU behavior and memory allocation where direct carbon analysis is unavailable. section 8.5.2
A practical comparison unit
Rather than reporting one undifferentiated number for a running service, estimate emissions per HTTP request, transaction, batch job, user, or gigabyte processed. The normalized unit ties resource use to delivered work, making alternative implementations or deployments easier to compare while preserving the estimate’s uncertainty. section 8.5.1
Green design treats efficiency as achieving acceptable responsiveness with the smallest practical hardware footprint. It complements clean code and performance without equating sustainability with either one. Reducing unnecessary computation, storage, data transfer, dependencies, and hardware turnover can lower both operational cost and environmental impact. section 8.6 section 8.3
