The EcoPigs Measured-Carbon Model (EMCM)

v2.0 changed how we measure a single scan: real CPU-time from the browser instead of a bytes guess (the detail below still stands — it is the engine underneath). v3 changes what number we report. Instead of a single bare figure, EMCM produces a calibrated estimate with a 90% confidence range and an honesty tier, so the figure never claims more certainty than it has.

Every figure carries a range and a tier

We never show a bare gram number. Each headline figure is shown as a median with its 90% range (for example, 0.012 g, range 0.009–0.016 g) and one of three tiers:

Measured energy, modelled conversion

This is the honest heart of EMCM. We measure the work a page does — CPU-time from the browser, bytes on the wire — but browsers do not expose actual joules, so energy is estimated from that work using device power profiles, then converted to carbon using grid intensity. That conversion carries a coefficient-and-grid floor of uncertainty that does not shrink with more visits. More real visits pin down your average traffic; they do not make the coefficients exact. So the ~±30% range is correct and stays — we will never render it tighter than the data supports.

The ladder: free scan → install the badge

A free scan gives you an estimate — a cold, first-visit number with no caching and no return visitors (the conservative end). Installing the EcoPigs badge turns that into a measurement of your real visitors' actual footprint. The grade letter often barely changes — but the reportable figure can move by around 2.5x once caching and return visits are counted, which is exactly why a site doing a CDP, SECR, or B Corp disclosure needs the badge, not just the scan.

How thin-data sites are calibrated (empirical-Bayes)

The scientific core of EMCM is an empirical-Bayes shrinkage estimator on log-emissions — the mechanism SWD and CO2.js categorically lack. A site with rich real-visit data gets a tight estimate centred on its own measurement. A site with thin or no data borrows strength from a class prior — the corpus pattern for sites sharing its sector, tech stack and hosting region — and its interval honestly widens. Where a class is thin, the prior pools up a hierarchy (sector × stack × region → stack × region → region → global) to the most specific level with enough sites. This is what a single-number estimator cannot do: it cannot know when it is guessing. EMCM does, and says so in the width of the interval. Full derivation in the EMCM technical methodology.

The dataset behind the priors

The priors are fitted on real measurement: around 1,130 graded sites and 16,000+ measurements over 10 continuous months (Aug 2025 – Jun 2026), with a clean measured-tier subset of 218 sites across 13 countries. We are precise about its shape — it is deep, not broad: the measured set is concentrated (heavily UK and WordPress, mostly one account). So the priors are tight where the data is rich and honestly wide elsewhere, and any benchmark we publish is scoped to a like-for-like cohort with its sample size shown. We say "deepest," never "largest" or "the web."

Reproducible by design

Every published figure must be reconstructable from its inputs. A machine-readable methodology and a per-score reproducibility trace are live at api.ecopigs.co.uk/api/v4/methodology: for any measured site, the trace returns the inputs, the exact coefficients used (each with its source and citation flag), which grid fallback fired per segment, the calibration state, and the output median and interval — so any EcoPigs number can be audited end to end.

Your score vs your system footprint (v3.1)

v3.1 adds a second, clearly-separated figure: an Estimated System Footprint, shown beneath the score — never replacing it. The two are a hierarchy, not rivals:

• Your score & grade — what you can actually move (operational + transfer). This stays the headline and the graded number; it is unchanged.
• Estimated System Footprint — the fuller picture, adding a fair time-share allocation of the visitor's device-manufacturing carbon. It is a bigger number (around 10× the score), with a wide band and low confidence.

Two honesty points make this work. First, it is context, not a "truer" number — it is fuller-boundary, not more honest than the score. Second, the device-manufacturing share is an allocation of hardware that exists regardless of this visit (the device owner's Scope 3) — informational, not additive to a corporate carbon inventory. Why keep it out of the grade? A grade must respond to action, and device-manufacturing-by-time is driven by session length and device mix, which a developer cannot move (grading on it would perversely reward bounce rate) — the same principle that keeps Scope 3 separate from Scope 1. For now the session's active time is assumed, not measured, so the figure is tier modelled-assumed-active-time with a deliberately wide band; when real active-session measurement lands (§ the roadmap), the band tightens and the tier flips to measured. In one line: your score is what you can move; your system footprint is the whole picture, including the device life this visit rents — shown honestly, with its uncertainty.

1. The Measurement Engine: What Changed and Why

For over a decade, the web carbon industry has measured the wrong thing.

Every tool out there -- Website Carbon Calculator, Ecograder, Beacon, CO2.js -- rests on one idea: device energy scales with bytes sent. Multiply bytes by a constant. Call it a carbon score. Publish it as fact.

It is not fact. It never was. It was the best proxy when these tools were built. Credit to them -- it moved the talk forward when nothing else existed. But over time, a proxy became a standard. Agencies cite it in green reports. Standards bodies use it in guides. The industry treats it as real data when it is, at best, a rough guess -- and often a wildly wrong one.

Using bytes to guess device energy is like using a banana to measure a football pitch. You get a number. It does not tell you much.

Here is why: a 2MB page of compressed images and a 2MB page of heavy JavaScript look the same to a bytes model. They are not the same. The JS page forces the CPU to parse and run code for seconds. The image page decodes in moments on the GPU. These are very different energy profiles. No amount of tuning a bytes constant will tell them apart.

EcoPigs v2.0 replaces the proxy with real data.

On every scan, we open a Chrome DevTools Protocol (CDP) session. We capture real CPU time, layout work, and render steps from the V8 and Blink engines. We turn those into energy using device power profiles from hardware specs, research papers, and tested benchmarks. The result is a carbon score based on what the page actually did, not what a formula guessed from file size.

We tested this on our own site first. ebbb.io is a light, fast static site -- the kind the bytes-proxy should handle well. On desktop, the proxy guessed 12x too high. Across all device types, 71x too high. On mobile: 320x too high.

That is not a tuning problem. It is a method problem. It has sat at the heart of web carbon scoring for a decade. v2.0 fixes it.

2. Why We Built Something New

The web carbon industry has a data problem. Every tool -- Website Carbon Calculator, Ecograder, Beacon, CO2.js -- rests on one idea: device energy scales with bytes sent.

SWD v4 gives user devices 0.080 kWh/GB of energy (Malmodin et al. 2023). This is a proxy, not a reading. A 2MB image page and a 2MB JavaScript page score the same, even though the JS page makes the CPU work far harder. In our tests, a light page used 12x less device energy than the proxy said it would.

EcoPigs v2.0 replaces that proxy with real browser data. On each scan, we capture CPU time, layout work, and render steps from the engine itself. We convert those into energy using device power profiles from hardware specs and research papers. The result is a carbon score based on what the browser did, not what we guessed from the file size.

Every other tool runs a version of the same formula with the same data. They will always agree on the same site. But agreement is not accuracy. EcoPigs gives a different number because it measures something different: what the browser did, not what a formula said it should do.

3. The Five-Score System

EcoPigs shows five carbon scores. Each adds one layer of detail. This clarity helps you see what drives your number and how different inputs change it.

Grid Intensity Values Used

4. Measured Device Energy: How It Works

On every scan, our tool opens a CDP session and turns on performance tracking. After the page loads, we pull metrics straight from the V8 JavaScript engine and the Blink renderer:

What CDP Measures (main thread only)

These are real seconds of main-thread CPU work. They show what the chip actually did, not what we guessed from file size. Web Workers, Service Workers, and off-thread compositing are not included (see Limits).

Conversion to Energy

Three energy parts are worked out:

Comparison with Bytes-Proxy

For ebbb.io (a light static site, 838 KB transfer, 0.22s script time, scanned as desktop via Puppeteer):

Real data also shows the real difference. Two pages with the same byte size but different CPU loads get the same proxy score. Measured data shows the true gap:

• A 2 MB page with 0.1s script execution: ~5 mWh on desktop (screen-dominated)
• A 2 MB page with 3.0s script execution: ~25 mWh on desktop (CPU-dominated)
• The proxy gives both ~156 mWh

5. Per-Segment Grid Splitting

v1.0 used one grid value for all three segments. That is handy but not correct. Your server in London, the cables across the Atlantic, and the visitor's laptop in Berlin draw from three different grids with different carbon levels.

6. Core Scientific Principles

The core equation stays the same:

We track carbon across three segments and two emission types:

Operational Energy Intensity (kWh per GB transferred)

Embodied Emissions

We include the carbon locked in the making of the hardware that runs the web. This is turned into an energy-like rate (0.106 kWh/GB) using the global grid average.

How Server-Side Energy Is Estimated

EcoPigs does not read server CPU or memory use directly. Server energy is estimated as bytes sent x 0.057 kWh/GB. This is the same method used by SWD v4 and all other tools. Future versions may add server-side tracking where possible.

7. Updated Data Sources (February 2026)

What Changed from v1.0

8. Live Grid Tracking

A key difference is that EcoPigs uses live, local grid data. A fixed global average (494 gCO2e/kWh in the SWD model) can be far off. A site hosted in the UK has a very different impact than one in a coal-heavy region.

EcoPigs shows grid carbon and energy mix but does not say which source is "better." A low-carbon grid may run on nuclear, hydro, wind, or a blend. The choice between low-carbon and renewable power is a value call we leave to you. We give the data. You decide what it means for your hosting.

Our Data Integration

Country Reference Values (Ember 2024 data, via Global Electricity Review 2025)

9. Conservative Baseline Assumptions

Our baseline uses cautious, upper-bound values:

This aligns with the GHG Protocol Corporate Standard (complete, clear, consistent, accurate, cautious) and follows ISO 14064-1 methods. EcoPigs reports have not been checked or verified against either standard by a third party.

10. Green Hosting: A Nuanced Approach

When a host is verified as "Green," we apply a 0.2 factor (an 80% cut) only to the Data Centre segment.

Green hosting does not reduce:

• Energy used by global network infrastructure
• Energy consumed by the end-user's device
• Embodied emissions from hardware manufacturing

This detail lowers the risk of over-counting the green hosting benefit. A green-hosted site still has network, device, and hardware-making emissions.

11. EcoPigs vs Website Carbon Calculator -- Key Differences

Website Carbon Calculator (WCC) uses the Sustainable Web Design Model v4. EcoPigs v2.0 uses Chrome DevTools Protocol (CDP) instrumentation. Here is how they differ in practice.

11.1 What Is Actually Being Measured

11.2 Component Breakdown Visibility

WCC returns one number. EcoPigs returns a per-component decomposition stored in the database:

This is the diagnostic differentiator -- you can tell a JS-heavy 1 MB page apart from a media-heavy 1 MB page. WCC cannot.

11.3 Grid Intensity

11.4 Magnitude of Result

On the same site, EcoPigs CDP measurement is consistently 5-13x lower than WCC bytes-based estimates:

The reason: WCC inflates the device-side estimate via bytes x 0.080 kWh/GB, which assumes every byte transferred drives proportional CPU work. CDP shows that is wildly wrong for heavy-asset, light-CPU sites. Amazon's homepage is fat with images and video assets but the CPU executes very little of it on first paint.

11.5 Grading

11.6 Hosting Status

11.7 Methodology Auditability

11.8 Population Characteristics

From our 558-site CDP dataset:

The CDP data tells you something WCC structurally cannot: network transfer dominates the actual carbon cost of a page visit. Device CPU is small; server processing is noise. This reframes optimisation priorities from "shrink JS bundles" toward "reduce transferred bytes" -- the same conclusion WCC reaches but for a defensible measured reason rather than because it is the only thing the model knows about.

11.9 The Honest Summary

12. Scope and Boundaries

13. Versioning and Comparability

v2.0 uses the Ember 2024 global average (473 gCO2e/kWh) for Baseline. v1.0 used 494. The grade bands (A+ to F) are the same, so grades still compare across versions. But raw gCO2e values from v2.0 will be a bit lower than v1.0 for the same page due to the updated grid value.

Grade Thresholds

Grades come from total emissions per view (gCO2e). In v3 we deliberately align our grade bands with the Website Carbon Calculator / Sustainable Web Design v4 Digital Carbon Ratings (July 2025), so a grade is comparable across tools — we compete on measurement accuracy, not on grading. (The earlier HTTP-Archive-percentile bands are deprecated.)

Source: Sustainable Web Design v4 Digital Carbon Ratings (July 2025), sustainablewebdesign.org/digital-carbon-ratings.

Every report shows which method version was used. When you compare reports over time:

• Grade comparisons are valid across v1.0 and v2.0 (same thresholds)
• Absolute gCO2e values should be compared within the same methodology version, or with awareness of the 4.3% reduction
• The Traditional score uses the SWD v4 built-in grid (494) and provides the closest comparison to v1.0 values

The measured score adds to the other four. It does not replace them. You can track your traditional score (for industry benchmarks) and your measured score (for accuracy) at the same time — and in v3 the measured score feeds the EMCM calibrated figure with its 90% range and tier.

14. Device Power Profiles

v2.0 adds four device power profiles. These turn measured CPU time, estimated GPU compositing, and screen-on time into energy numbers.

Source types: Values come from Academic (peer-reviewed papers), Manufacturer (published specs), and Community (repeatable tests by hardware testers -- not peer-reviewed but consistent and reproducible).

Academic References

1. Carroll, A. & Heiser, G. (2010). An Analysis of Power Consumption in a Smartphone. USENIX ATC.
2. Mahesri, A. & Vardhan, V. (2004). Power Consumption Breakdown on a Modern Laptop. PACS.
3. Microsoft IE Team (2011). Browser Power Consumption: Leading the Industry.
4. Torchbox (2024). How Much Power Do Web Assets Use? M1 MacBook powermetrics measurements.
5. arXiv:2205.11399 (2022). Energy Efficiency of Web Browsers in the Android Ecosystem.
6. arXiv:2401.15985 (2024). Dissecting software-based measurement of CPU energy consumption.
7. Stanford/Boneh (2012). Who Killed My Battery? WWW 2012.
8. ASE 2020. Energy Wars -- Chrome vs Firefox. RAPL-based browser energy comparison.

15. Relatable Metrics

Grams of carbon are hard to picture. We turn emissions into everyday examples so teams can share their impact clearly. All conversions use DEFRA 2025 UK grid data (0.177 kgCO2e/kWh) where it applies.

These metrics are provided at both per-visit and annual (x10,000 page views) granularity. All relatable metrics use the same source constants defined in constants/carbonMethodology.mjs, ensuring consistency across all outputs.

16. Limitations

Being open about limits makes the method stronger, not weaker.

Measurement Scope

Energy Estimation

Methodology

17. References

Primary Research

• International Energy Agency (2024). Energy and AI. Updated data centre energy consumption to 415 TWh.
• International Energy Agency (2022). Data Centres and Data Transmission Networks.
• Malmodin, J. & Lunden, D. (2023). The energy and carbon footprint of the global ICT and E&M sectors 2010-2022. Telecommunications Policy.
• ITU (2024). Facts and Figures 2024. Global data transfer volumes.
• Ember (2025). Global Electricity Review. Country-level grid carbon intensity data for 2024. Source of 473 gCO2e/kWh global average.

Standards and Frameworks

• GHG Protocol. Corporate Accounting and Reporting Standard.
• ISO 14064-1:2018. Greenhouse gases -- Specification with guidance.
• SBTi. Science Based Targets initiative -- ICT Sector Guidance.

Government Data

• DEFRA (2025). UK Government GHG Conversion Factors. Electricity factor: 0.177 kgCO2e/kWh.
• National Grid ESO. Carbon Intensity API. carbonintensity.org.uk.
• U.S. EPA. Emissions & Generation Resource Integrated Database (eGRID).
• ENTSO-E. Transparency Platform. transparency.entsoe.eu.

Hardware Specifications

• Intel. ARK Product Specifications -- i5-12400. Package power and RAPL measurements.
• Qualcomm. Snapdragon 8 Gen 2 Product Brief. Big core cluster power consumption.
• EnergyStar. Display Product Database. Typical panel power consumption.

Industry Models (for comparison)

• The Green Web Foundation. CO2.js -- Sustainable Web Design Model v4. Uses 0.080 kWh/GB operational + 0.081 kWh/GB embodied for user device segment. 494 gCO2e/kWh default global grid.
• Fershad Irani (2024). Exploring the Sustainable Web Design Model v4.