Software Carbon Intensity for web products: measure the rate, then lower it

Most carbon reporting answers “how much did we emit last year?”. A product team needs a different question: “is each visit, each search, each checkout getting cleaner as we ship?”. The Software Carbon Intensity specification is built for that question. It expresses emissions as a rate per unit of useful work, so the number moves when the software changes.^{1 2}

The equation

SCI = ((E × I) + M) per R

O   = E × I                          operational emissions
M   = TE × (TiR / EL) × (RR / ToR)   embodied share:
      TE   total embodied emissions of the hardware
      TiR  time reserved for this software   EL   expected lifespan
      RR   resources reserved                ToR  total resources

Two rules make SCI useful for design decisions. Carbon intensity must be location-based, for the grid the software actually draws from, and the score cannot be reduced by carbon offsets or market-based measures such as renewable-energy certificates.¹ The only way to lower it is to change the software, or where and when it runs.

Draw the boundary first

The specification asks you to include everything that significantly supports the software: compute, storage, networking, logging and monitoring, build and deploy pipelines, backup and failover, and the end-user devices it runs on. It also asks you to disclose what you included and what you left out.¹ For a website that usually means servers, the CDN, the network and the visitor’s browser.

Choosing R for a website

R is the decision that makes the number mean something. For a content site, per page view. For a product, per active user per day, or per completed task such as a search or a checkout. Pick the unit your team already uses to describe value, use it for every component inside the boundary, and keep it stable so the trend means something.

A worked example

Suppose a campaign site serves one million page views a month. Inside its boundary the servers, CDN share and database use 120 kWh in that month, on a grid averaging 700 gCO₂e per kWh, and the month’s share of the hardware’s embodied emissions is 30 kgCO₂e.

E × I        = 120 kWh × 700 gCO₂e/kWh   =  84,000 gCO₂e
M                                         =  30,000 gCO₂e
(E × I) + M                               = 114,000 gCO₂e
R            = 1,000,000 page views
SCI          = 114,000 / 1,000,000        =  0.114 gCO₂e per page view

What moves the number

• Send less. Right-sized images in modern formats, fewer fonts, less JavaScript. The work that improves Core Web Vitals also lowers energy across the network and the visitor’s device.
• Cache more. A response served from a nearby cache does far less work than one rebuilt at the origin.
• Compute less. Remove unused tags and third-party scripts; render pages that do not change once, not on every request.
• Shift work in time and place. Reports, image processing and model training can run where and when grid intensity is lower.³
• Right-size the hardware. Idle servers still carry embodied emissions. Fewer, busier machines lower M per unit.

Make it part of the release

Treat SCI like a performance budget. Measure a baseline for the templates or journeys that carry most of your traffic, set a target rate, and check it at release. The Web Sustainability Guidelines, published by the W3C Sustainable Web Interest Group as a draft group note, collect the design and engineering practices that move it.⁵ We fold this into Audits & Assessments and into every Websites & Apps build.