Measuring Web Carbon Intensity Beyond Data-Transfer Proxies: A Hardware-Calibrated Telemetry and Validation Framework

By Dr Sam 7 sources cited

Abstract

Current methodologies for estimating the environmental footprint of web applications rely heavily on data-transfer proxies, often conflating browser-observable events with actual hardware energy consumption. The established ISO/IEC 21031:2024 Software Carbon Intensity (SCI) standard and the developing SCI for Web specification define the conceptual accounting boundaries for software emissions. However, operationalizing these frameworks in heterogeneous environments requires rigorous empirical measurement rather than broad approximation. This paper proposes a multi-layer telemetry architecture defining an explicit measurement ladder that isolates physical reference measurements from hardware counters, calibrated estimators, and browser proxies. By detailing a protocol across controlled laboratory environments and heterogeneous devices, we establish an experimental design to estimate measurement error with robust confidence intervals. A systematic, causally-controlled ablation matrix tests whether telemetry-based metrics can reliably detect the impact of software engineering interventions, establishing the empirical foundation necessary to measure web carbon intensity with quantified uncertainty.

1. Introduction

The environmental footprint of digital technology is traditionally estimated using static, spend-based proxies or data-transfer averages. While these methods successfully fulfill high-level Scope 3 inventory reporting, recent studies report that existing web-energy approximation services often overestimate measured consumption and behave inconsistently across frameworks. This protocol addresses a complementary but distinct research gap: while standards define what should be counted, we must determine how accurately each component of that accounting boundary can actually be measured in real-world execution environments.

1.1 Research Questions and Hypotheses

This protocol establishes an empirical framework for evaluating measurement accuracy through a tiered hierarchy, addressing the following research questions and formal hypotheses:

2.1 Web-Carbon Estimation and Standards

The ISO/IEC 21031:2024 standard specifies the formal methodology for calculating software carbon intensity. Concurrently, the Green Software Foundation's SCI for Web consensus-built methodology expands this boundary to explicitly include servers, CDNs, third-party services, and end-user devices. However, standard calculation methods heavily utilize data transfer (GB over the wire) as a proxy, ignoring the specific micro-architectural differences in end-user hardware execution.

2.2 Software Energy Measurement

Research into hardware energy counters such as Intel’s Running Average Power Limit (RAPL) demonstrates a strong correlation with physical power meters (Khan et al., 2018). Crucially, recent literature reveals that RAPL can overestimate actual power in heterogeneous memory scenarios (Alt et al., 2024). This limitation reinforces the necessity of grounding all telemetry against an external physical reference rather than treating hardware counters as infallible ground truth.

3. Measurement Model

The functional unit for this protocol is defined as 1 standardized user journey—a predefined sequence of interactions terminating at task completion, with a nominal maximum duration of 120 seconds.

Total carbon () is the sum of operational and embodied emissions:

Where , is the spatial-temporal grid intensity, and represents the allocated embodied lifecycle contribution of component to the functional unit.

Because operational measurement precision varies wildly across web architectures, this framework introduces Attribution Confidence Levels:

ComponentPrimary MeasurementAttribution Confidence
ClientExternal meter ()High
Server (Dedicated)External meter ()High
Server (Shared VM)Resource allocationMedium/Low
Network/CDNTelemetry/AllocationMedium/Low
Third-Party ServicesInferred allocationLow
Embodied HardwareLCA modelModel-dependent

4. Measurement Ladder

The architecture enforces an explicit progression of abstraction, quantifying the error (, ) at each stage relative to the external baseline.

The error at each layer is explicitly isolated against Tier A:

5. Experimental Infrastructure and Dataset

5.1 Sample-Size Justification

A pilot study will estimate within-application and between-application variance. These estimates will inform the final sample-size power calculation () to determine the minimum practically meaningful reduction in . The baseline target comprises 50 web applications (10 per architecture class: Static, News/Content, E-commerce, SPA, Data-Intensive).

5.2 Test Environments

6. Calibration and Statistical Analysis

To prevent data leakage, no reference-energy observations from the held-out application are used during model calibration or hyperparameter selection. Predictive accuracy is evaluated using two rigorous schemes:

  1. Leave-one-application-out cross-validation.
  1. Leave-one-architecture-class-out cross-validation (evaluating out-of-distribution generalizability).

The protocol utilizes a mixed-effects statistical model:

Where Application () and Device () are random effects, and Architecture is a fixed effect.

6.1 Uncertainty Propagation

When estimating total carbon, uncertainty is propagated mathematically:

Monte Carlo propagation will be employed when component distributions exhibit non-Gaussian dependencies. Both Sobol first-order () and total-order () sensitivity indices will be calculated to formally decompose the sources of total uncertainty.

7. Intervention Experiments

To estimate the causal effect of software interventions (H5), we enforce randomized treatment orders, crossover (), and thermal state controls.

ConditionInterventionExpected Effect
BaselineReference
JavaScript ReducedClient Energy
Payload OptimizedNetwork / Client Energy
Database OptimizedServer Energy
Temporal ShiftingCarbon Intensity (Energy unchanged)
Structural Placebo(Negative Control)
Expensive JS LoopClient Energy (Positive Control)

8. Threats to Validity

9. Discussion and Conclusion

(To be populated upon dataset execution)

By implementing this physical reference protocol, we provide the empirical foundation to quantify measurement error, testing exactly how much telemetry is required to reliably attribute digital carbon emissions.

10. Selected References

(Note: Excerpted from the full 45-65 item bibliography spanning LCA, sustainable software engineering, and uncertainty analysis.)

  1. ISO/IEC 21031:2024. Information technology — Software carbon intensity (SCI) specification. International Organization for Standardization.
  1. Green Software Foundation (2026). Software Carbon Intensity (SCI) for Web Assembly Report.
  1. Kalliola, A., & Vepsäläinen, T. (2025). Challenges Related to Approximating the Energy Consumption of a Website. IEEE Access, 13, 139001–139017.
  1. Alt, L., Kozhokanova, A., Ilsche, T., Terboven, C., & Müller, M. S. (2024). An Experimental Setup to Evaluate RAPL Energy Counters for Heterogeneous Memory. 15th ACM/SPEC International Conference on Performance Engineering, 71–82.
  1. Khan, K. N., Hirki, M., Niemi, T., Nurminen, J. K., & Ou, Z. (2018). RAPL in Action: Experiences in Using RAPL for Power Measurements. ACM Transactions on Modeling and Performance Evaluation of Computing Systems, 3(2), Article 9.
  1. World Resources Institute & WBCSD (2011). Corporate Value Chain (Scope 3) Accounting and Reporting Standard.
  1. Saltelli, A., et al. (2010). Variance based sensitivity analysis of model output. Design and estimator for the total sensitivity index. Computer Physics Communications, 181(2), 259-270.

← All research articles How we build & check these tools