Skip to main content

You are viewing a project that is currently in draft state for the Standards Working Group in the Green Software Foundation. This project should not be considered finished or officially supported in any way by the Green Software Foundation or its members.

Getting Started

In short: SCI for Web measures the carbon emissions of a web application per unit of useful work it does for people, such as a completed purchase or an article read. It counts the servers that build each response, the devices that render it, the hardware that carries it across the internet, and the third-party services woven into the page. This site explains how to work that score out in practice. The SCI for Web Specification itself states the formal requirements.

This site is draft guidance. It is a Standards Working Group (SSWG) work item within the Green Software Foundation and is not yet officially endorsed. Page structure, worked examples and data-source pointers should all be expected to change as the SSWG's work progresses.

What this site is​

This is the SCI for Web Guidelines site: a non-normative companion to the SCI for Web Specification, which extends the Software Carbon Intensity (SCI) specification, ISO/IEC 21031:2024, to web applications. It follows the relationship the GSF's SWI Guidance has to the Software Water Intensity specification: the specification states the principle; the guidelines explain how to fulfil it.

The two documents are deliberately kept apart. Worked examples, tool lists, default values and data-source guidance need frequent revision as tools appear and data improves. Revising a normative specification is slow by design, so that material lives here, where it can change without a new version of the standard. Nothing on this site creates, relaxes or tightens a requirement. Where a page relies on one, it names the clause ("Clause 7.5 requires…") so you can check the source.

Why measure web applications this way​

Web applications spread their computation across infrastructure that no single party controls: origin servers and edge nodes, the networks between them, third-party services and the phones and laptops on which browsers run the code. A measure that looks only at the data centre rewards moving work onto users' devices, which saves nothing. SCI for Web closes that gap by drawing one boundary around all of it.

The original draft set out several aims for the method, and they explain much of its shape:

  • Meaningful comparison between implementations and architectures of the same kind of application, so that teams can judge design choices.
  • Genuine reductions, not displacement. Moving work from a measured component to an unmeasured one should never improve the score (Clause 10 makes this a core characteristic).
  • Market pressure on suppliers. Making third-party and hosting emissions visible gives web teams a reason to ask suppliers to disclose and reduce their impact.
  • Better decisions in design, development and operation, by showing where emissions actually arise.

Like the parent SCI, an SCI for Web score is a rate, not a total: emissions per functional unit. Lower is better. A score never reaches zero, but it can always improve, and it improves only when emissions are eliminated through more efficient code, more efficient infrastructure or lower-carbon electricity. Carbon offsets and renewable energy certificates do not reduce it.

Teams also start from very different places. Some can only run a browser profiler on a handful of devices; others run continuous telemetry across their fleet. The original draft described this as a progression of implementation tiers (Entry, Standard and Advanced). The proposed specification does not use tiers, but they remain a useful way to plan how to improve data quality over time: see Implementation Tiers and Data Quality.

The formula, at a glance​

SCI for Web follows the parent SCI's shape, (O + M) per R, and splits each part by where the emissions arise:

SCI_Web = (O_server + O_client + M_server + M_network + M_client) / R
  • O_server, O_client: operational emissions (energy × location-based carbon intensity) of servers and of the end-user devices running the application;
  • M_server, M_network, M_client: embodied emissions of server, network and end-user hardware;
  • R: the functional unit, such as one completed transaction.

Operational network emissions, O_network, are optional. Clause 7.1 requires the score above always to be reported; where O_network is quantified, a second, clearly labelled score that adds it may be reported alongside. The Formula Walkthrough explains why.

The five steps​

Clause 4 sets out the procedure every assessment follows. These guidelines are organised around it:

  1. Bound: decide what is inside the software boundary (Scope, Third-Party Attribution).
  2. Scale: choose the functional unit (Choosing a Functional Unit).
  3. Define: choose measurement or calculation for each component (Implementation Tiers and Data Quality).
  4. Quantify: calculate each component and sum them (Operational Emissions, Embodied Emissions).
  5. Report: disclose the score and how you reached it (Disclosure Template).

Where to go from here​

Please submit any comments you have here.