Website and Digital Service Emissions
Every page load pulls bytes from a server, through the network, onto a screen — and each of those three steps burns electricity somewhere on a grid. A single visit is almost nothing; a million visits a month is a measurable corporate emission.
The methodology is not about one page. It is about which bytes you are allowed to count, how often, and on whose grid.
A website’s carbon is the data transferred per page view, split across data-centre, network, and device energy, each multiplied by its grid intensity, then scaled by annual page views. Page weight and the returning-visitor caching ratio are the dominant levers.
The Website Footprint Problem
A website does not have a carbon footprint — a page view does, and the site’s footprint is the sum of its views. The unit of analysis is the byte delivered to a visitor, and the methodology is the chain that turns bytes into grams: data transferred, split across three energy segments, each multiplied by the grid intensity where that energy is consumed, then scaled by how many times the page is loaded in a year.
The reason “what is this website’s carbon?” has no single answer is that the footprint depends on three things the question hides: how heavy each page is (page weight in bytes), how many times it is viewed, and how much of each repeat view is served fresh versus from cache. A heavy page viewed once is trivial; a light page viewed ten million times a month is a real line in a corporate inventory. Conflate the per-view figure with the annual figure — or assume every view transfers the full page weight when caching means most do not — and the estimate is wrong by an order of magnitude.
The convention of expressing digital carbon as emissions per page view, computed from the data transferred for that view across three system segments (data centre, network, end-user device), then aggregated to an annual site footprint by multiplying by page views. The per-view figure is the atomic unit; the annual figure is the reportable quantity. A digital footprint cannot be read without knowing both the per-view intensity and the view volume.
The dominant standard for this chain is the Sustainable Web Design Model (SWD), now in version 4 (2023), which assigns a per-byte energy intensity to each of three system segments and a grid-carbon factor to convert energy to emissions. It is the page-default model here, treated as a cited external model because per-byte intensity is not yet a MasterBrain row family.
The two largest controllable levers in a website’s footprint are page weight (bytes per view) and the returning-visitor caching ratio (how much of a repeat view is re-downloaded). Screen size and device — which dominate video streaming — matter far less for a text-and-image web page.
Provider directory
Now it has to hold up all year.
See who does this work. Every listing names the standards it works to, and paid placements are labelled. Including Attain Zero and Anthesis Group.
Browse 6 carbon accounting & inventory providers →Do this work? A listing is US$390 a year. Get listed →
What a Digital Footprint Measures: The SWD System Segments
SWD v4 partitions the energy of delivering bytes into three segments, plus a fourth methodological dimension — the new-versus-returning visitor split — that governs how much data is actually transferred.
| Segment | What it covers | Energy basis | Site-owner scope |
|---|---|---|---|
| Data centre / hosting | Origin server, database, CDN edge, storage — amplified by facility PUE | Per-byte intensity (kWh/GB) | Scope 2 (own server) or Scope 3 Cat 1 (cloud / managed hosting) |
| Network transfer | Backbone + access network moving bytes to the visitor | Per-byte intensity (kWh/GB) | Scope 3 (telecom upstream) |
| End-user device | The visitor’s screen + processor rendering the page | Per-byte intensity (kWh/GB) — SWD folds device energy into a per-byte term | Scope 3 Cat 11 (downstream use) |
| New vs returning split | First view loads full page weight; return views load less (browser cache) | Data-transfer multiplier, not a segment | Applies across all three segments |
Data centre and hosting
The server, database, and content-delivery edge draw electricity amplified by the facility’s power usage effectiveness. SWD bundles this into a per-byte data-centre intensity, but the PUE multiplier is live in the MasterBrain and matters for any site that hosts its own infrastructure: hyperscale facilities run at 1.1 [GreenCalculus digital.data_centre.pue.hyperscale.low · IEA AI 2025 · v2026.264]–1.2 [GreenCalculus digital.data_centre.pue.hyperscale.high · IEA AI 2025] against an enterprise range of 1.5 [GreenCalculus digital.data_centre.pue.enterprise.low · IEA AI 2025]–1.7 [GreenCalculus digital.data_centre.pue.enterprise.high · IEA AI 2025]. The cloud-allocation question — splitting a shared facility across tenants — is treated in the cloud-compute allocation methodology.
Network transfer
Bytes travel from origin (or CDN edge) through the backbone and access network to the visitor. As with streaming, network energy is largely fixed — the equipment runs regardless of any single page load — so SWD uses an attributional per-byte average rather than a marginal figure. A CDN reduces the network distance bytes travel, which lowers the effective network term; the methodology credits this only if the CDN’s own energy is in-boundary.
End-user device
The visitor’s device renders the page. SWD v4 expresses device energy as a per-byte term rather than a per-second wattage, on the basis that heavier pages drive more processing and longer engagement. The MasterBrain carries per-device operational wattage and embodied carbon for the Lövehagen (2023) device set, which a more granular bottom-up model can substitute for the SWD per-byte device figure.
The new-vs-returning visitor split
This is the dimension most calculators omit and the one that most distorts results. A first-time visitor downloads the full page weight; a returning visitor, with assets cached in the browser, downloads only the uncached portion — often a small fraction. SWD applies a returning-visitor data ratio (a typical default assumes a share of return traffic loads materially less data). Assuming every view transfers full page weight overstates a real site’s annual footprint substantially, because most production traffic is repeat or cached.
The Canonical Calculation
The per-view footprint is the data transferred for that view, multiplied by the per-byte energy intensity of each segment, multiplied by grid intensity. The annual footprint scales by views and applies the new-vs-returning ratio.
E_view = V × ( i_dc + i_net + i_dev ) × G
E_annual = [ N_new × V_full + N_return × V_cached ] × ( i_dc + i_net + i_dev ) × G
where V = data transferred for the view (GB) · i_dc, i_net, i_dev = SWD per-byte intensities for data centre, network, device (kWh/GB) · G = grid emission intensity (kgCO₂e/kWh) · N_new, N_return = new and returning page views · V_full = full page weight · V_cached = reduced data for a cached return view.
Three rules govern the combination:
- Page weight is measured, not estimated. Unlike streaming, where data volume is reconstructed from bitrate, page weight is directly measurable: load the page and record total transferred bytes (HTML, CSS, JS, images, fonts, third-party scripts). Use the transferred size over the wire, not the uncompressed size.
- The returning-visitor ratio is a real input, not a default to ignore. Annual footprint without a caching adjustment is an upper bound that overstates reality. Source the new-vs-return split from analytics where available; use the SWD default only as a fallback and disclose it.
- Grid intensity is per-segment by location. Data-centre energy on the hosting grid; device energy on the visitor grid. For a globally-visited site the device term should use a visitor-weighted grid average, not the host-country grid. The CO₂e step uses grid.<iso3>.electricity.location_based (GB 0.13096 [GreenCalculus grid.gbr.electricity.location_based · DEFRA 2026 'UK electricity'!E25]) with a well-to-tank companion at grid.<iso3>.electricity.wtt_generation (GB 0.03682 [GreenCalculus grid.gbr.electricity.wtt_generation · DEFRA 2026 'WTT- UK electricity'!E19]).
Per-Byte Energy-Intensity Reference Values
The parameter library. Values resident in the MasterBrain render live and are labelled MB live; SWD per-byte intensities are cited and hardcoded, labelled cited, pending a future digital.web.* MasterBrain row family.
SWD v4 per-byte segment intensities cited
| Segment | Operational (kWh/GB) | Embodied (kWh/GB) | Share of total energy |
|---|---|---|---|
| Data centre | 0.055 | 0.012 | Lower |
| Network | 0.059 | 0.013 | Moderate |
| End-user device | 0.080 | (per SWD device term) | Largest |
Source: Sustainable Web Design Model v4 (2023). The device segment is the largest operational term per byte, mirroring the streaming finding that the end-user side dominates. Hardcoded pending a digital.web.swd.* MB row family. The operational + embodied split lets the model produce either an operational-only or a full-lifecycle per-view figure.
Data-centre PUE MB live
| Facility class | PUE low | PUE high |
|---|---|---|
| Hyperscale | 1.1 | 1.2 |
| Enterprise | 1.5 | 1.7 |
Relevant where a site self-hosts or wants to refine the SWD bundled data-centre term with its actual facility PUE. Governed by ISO/IEC 30134 and the Uptime Institute survey.
End-user device — operational + embodied MB live
| Device | Operational (W) | Embodied (kgCO₂e) |
|---|---|---|
| Smartphone | 1 | 50 |
| Laptop | 22 | 200 |
| Desktop + monitor | 68.5 | 350 |
Live from the Lövehagen 2023 device set. A bottom-up device model substitutes these for the SWD per-byte device term where a site has device-mix analytics; the end-user devices methodology covers the substitution.
Green Hosting and the Grid-Mix Question
The single largest infrastructure lever a site controls is the carbon intensity of the grid powering its hosting. SWD applies a green-hosting adjustment to the data-centre segment when the host runs on verified renewable energy. The MasterBrain carries per-region carbon-free-energy percentages for major cloud providers, which let a site replace a generic grid factor with its actual regional mix — for example a Google Cloud region’s CFE share at digital.gcp.region.<region>.cfe_percentage (live via [gc_factor] by region key).
Green hosting reduces the data-centre segment only — typically the smallest of the three. It does nothing for the network and device segments, which run on the visitor’s grid. A site claiming to be “carbon neutral because it is green-hosted” has decarbonised perhaps a fifth of its footprint. Never extend a green-hosting claim across the whole per-view figure (failure mode F5).
The correct treatment is to apply the host’s actual grid (or CFE-adjusted) intensity to the data-centre segment, and a visitor-weighted grid average to the network and device segments. Substituting a single low-carbon factor across all three because the host is green is a structural overstatement of the benefit, and an auditor will reverse it.
Beyond Per-Byte: What the Model Omits
The per-byte model is tractable and reproducible, but it draws a boundary that excludes real energy. A complete methodology states what is outside the boundary rather than pretending it is zero.
| Omission | What the per-byte model misses | Materiality |
|---|---|---|
| Idle device time | Energy the device draws while the page is open but not actively transferring data (long-dwell pages, video backgrounds). | Moderate for high-dwell pages |
| Third-party / ad-tech scripts | Tags, trackers, and ad auctions that execute on the device and pull additional bytes from domains the site owner does not control. | High — often the heaviest part of a commercial page |
| Edge / serverless compute | Compute executed at the CDN edge or in serverless functions, not captured by a pure data-transfer model. | Growing |
| Rebound effect | Efficiency gains that increase usage (a lighter, faster site that attracts more views) — a consequential effect outside the attributional boundary. | Contested |
The third-party-script omission is the most consequential for commercial sites: an ad-funded page can carry more third-party bytes than first-party content, and a per-byte model that measures only the site owner’s own assets understates the real transfer. The audit-grade approach measures total transferred bytes including third-party domains, and attributes them — a boundary decision that must be stated, because attributing third-party ad-tech carbon to the publisher versus the advertiser is itself contested (failure mode F3).
The Model-Choice Debate — Three Positions
Three models coexist for converting web activity to carbon, each with a different boundary and a different per-view number. A figure cannot be interpreted without knowing which produced it.
Position A — SWD per-byte (attributional)
Assign each transferred byte its average share of system energy across the three segments. The Sustainable Web Design Model, the page default. Reproducible, auditable, widely adopted by web-carbon calculators. Critique: charges a marginal page load with a slice of fixed network energy, and the single global per-byte intensity smooths over real grid and infrastructure variation.
Position B — Marginal / OneByte-style
Count only the energy genuinely caused by the additional transfer, separating fixed infrastructure energy from marginal data energy. More physically honest about the incremental page load; harder to audit and easy to misuse to make any single site look negligible. Closer to the IEA’s preferred marginal framing.
Position C — Bottom-up measured energy
Instrument the actual energy: server power draw allocated per request, real device power measurement, measured network energy. The most accurate and the most resource-intensive; appropriate for a large platform optimising its own infrastructure where the measurement cost is justified.
The reconciliation rule is the same as for streaming: pick one model, apply it to every segment, and disclose it. The audit failure is silently mixing — taking the data-centre term bottom-up from measured server energy and the network term from the SWD per-byte average within one total.
Does Data Volume Drive Network Energy At All?
All three positions above share an assumption, and so does this page’s default: that network energy is a function of bytes moved. There is a serious published argument that it is not. Our video streaming methodology already carries that argument in full — and explicitly names this page as one of the things it cuts against. Making that admission there and staying silent here would be owning up only where it costs nothing.
Malmodin (2020) and Kamiya & Bertoldi (JRC 2024) argue that network energy is not instantaneously correlated with data volume at all. Network capacity is built and powered against forecast peak demand, not average traffic. The routers and line cards are provisioned, switched on and drawing power before your page loads; they draw almost the same power after it finishes. On this reading, a kWh/GB coefficient is not a measurement of anything physical — it is an accounting convention for dividing a largely fixed quantity of energy among whatever traffic happened to share the pipe.
The JRC’s 2024 assessment is blunt about the consequence: studies “overestimate energy use — particularly by networks — by using outdated energy intensity values (kWh/GB) and assuming that energy use is proportional to data traffic.” The same report records the Shift Project revising an estimate down by 88% after a unit-conversion error, and Marks et al. revising down by more than 90%.
This lands squarely on Position A, which is this page’s default. The SWD v4 network term is per-byte by construction. We are not going to pretend otherwise.
The exposure is larger here than on the streaming page
The streaming methodology can partly absorb this argument. After its 2026 revision, its network term fell to about 13% of a fixed-line session — small enough that even a large error there barely moves the headline. That defence is not available on this page. Read the segment table above: the network term is 0.059 of 0.194 kWh/GB of operational per-byte energy — roughly 30%, more than double the streaming share. If the peak-demand critique is right, the term it attacks is close to a third of the operational number this page produces. We would rather say that plainly than let the streaming page’s more comfortable arithmetic stand in for this one.
So why does this page still run a per-byte network term? Three reasons, stated so you can disagree with them:
- Nobody has published an operational alternative at page-view scale. The peak-demand critique is a strong account of how network energy behaves. It is not yet a method for attributing that energy to one page view, which is the question a website footprint has to answer. Rejecting per-byte without a replacement does not produce a better number — it produces no number.
- The reference model is per-byte, and it is what the field audits against. The Sustainable Web Design Model v4 is openly published, openly governed and adopted across web-carbon tooling, so a figure produced with it can be checked against everyone else’s. A bespoke GreenCalculus model that dodged the critique would be comparable to nothing — a worse failure, for a methodology page, than an assumption we disclose.
- The segment that dominates is not the one in dispute. The end-user device is the largest operational term per byte (0.080 kWh/GB). Nobody argues that a screen draws power independently of being switched on. The contested term is real and material here — that is the point of the paragraph above — but it is not the term carrying the answer.
A published, auditable method for allocating peak-provisioned network capacity to an individual page view — or measured operator data showing session-level energy that does not track traffic — would obsolete the per-byte network term on this page, in the calculator, and in every other per-byte model we run. We are not aware of one. If you are, we would like to know: this is the parameter we would most like to be wrong about.
Attribution and Boundary Taxonomy
Six structurally distinct ways a website footprint understates, overstates, or misattributes. Each named for citation with a detection signature.
| # | Failure mode | What goes wrong | Detection signature |
|---|---|---|---|
| F1 | Full-weight-every-view | Assuming every page view transfers full page weight, ignoring browser caching on return visits. | Annual footprint = page weight × total views, with no new-vs-return ratio applied. |
| F2 | Single-grid intensity | Applying the host-country grid factor to the device and network segments, which run on visitor grids. | One grid factor multiplies all three segments despite a global visitor base. |
| F3 | Third-party omission | Measuring only first-party bytes, excluding ad-tech and third-party scripts that dominate commercial pages. | Measured page weight is far below the browser’s reported total transfer. |
| F4 | Model mismatch | Mixing SWD per-byte and bottom-up measured energy across segments within one total. | Methodology note cites two models for different segment lines. |
| F5 | Green-hosting over-extension | Applying a green-hosting low-carbon factor across the whole per-view figure, not just the data-centre segment. | A “carbon-neutral site” claim covering network and device energy on visitor grids. |
| F6 | Uncompressed page weight | Using the uncompressed asset size rather than the transferred (gzipped/brotli) size over the wire. | Page-weight figure exceeds the network panel’s reported transfer size. |
Governance, Scope Placement, and Framework Treatment
The same delivered byte lands in different inventory lines depending on the entity. A website’s footprint is split between the site owner, the hosting provider, the telecom network, and the visitor’s organisation.
| Reporting entity | Segment | Scope / category |
|---|---|---|
| Site owner | Own server electricity | Scope 2 |
| Managed / cloud hosting | Scope 3 Cat 1 (purchased services) | |
| Visitor device + network transfer | Scope 3 Cat 11 (downstream use) | |
| Hosting provider | Data-centre electricity | Scope 2 (own consumption) |
| Visitor’s organisation | Device electricity (office browsing) | Scope 2 (own consumption) |
Two governance consequences. First, a site owner’s own-server electricity is Scope 2, but cloud-hosted infrastructure is Scope 3 Category 1 (a purchased service), and the visitor-side device and network energy is Scope 3 Category 11 (downstream use of the digital service). Most modern sites are cloud-hosted, so the site owner’s largest controllable line is its Cat 1 hosting plus its Cat 11 downstream — not Scope 2. Second, because the same byte’s energy is the host’s Scope 2, the site owner’s Cat 1, and the visitor-org’s Scope 2, web carbon is structurally counted multiple times across the economy — correct under consolidation rules, never within one entity.
On disclosure, an embodied-inclusive web footprint aligns with the EU Product Environmental Footprint method for digital services; the data-centre efficiency metrics underpinning the hosting term are governed by ISO/IEC 30134. The per-byte model itself is the Sustainable Web Design Model.
Worked Examples — Audit Records
Three audit-record snapshots. All numerics hardcoded for audit-trail integrity — they reconcile to the stated inputs at this page’s review date regardless of future MasterBrain bumps. SWD v4 segment intensities used: DC 0.055, network 0.059, device 0.080 kWh/GB (operational). Grid: GB 0.131 kgCO₂e/kWh.
Inputs: page weight 2 MB transferred (0.002 GB) · first-time visitor (full weight) · SWD operational intensities · GB grid 0.131.
| Segment | Energy (0.002 GB × intensity) | × 0.131 grid |
|---|---|---|
| Data centre (× 0.055) | 0.000110 kWh | 0.0000144 kg |
| Network (× 0.059) | 0.000118 kWh | 0.0000155 kg |
| Device (× 0.080) | 0.000160 kWh | 0.0000210 kg |
| Total per view | 0.000388 kWh | ≈ 0.051 gCO₂e |
A single 2 MB page view is about 0.05 gCO₂e on the GB grid — trivially small, which is exactly why the per-view figure is meaningless in isolation and the annual figure (example B) is the reportable one. The device segment is the largest of the three, consistent with the SWD finding that the end-user side dominates per-byte energy.
Inputs: 5,000,000 annual page views · 2 MB full weight · returning-visitor split 30% new / 70% return · return views transfer 25% of full weight (cached) · per-GB total intensity 0.194 kWh/GB (0.055 + 0.059 + 0.080) · GB grid 0.131.
| Step | Calculation | Result |
|---|---|---|
| New-view data | 1,500,000 × 0.002 GB | 3,000 GB |
| Return-view data (25% cached) | 3,500,000 × 0.002 × 0.25 | 1,750 GB |
| Total annual data | 3,000 + 1,750 | 4,750 GB |
| Energy | 4,750 × 0.194 kWh/GB | 921.5 kWh |
| × GB grid 0.131 | 921.5 × 0.131 | ≈ 121 kgCO₂e/year |
The caching ratio matters: ignoring it (assuming all 5M views transfer full weight) would give 10,000 GB → ~254 kgCO₂e, more than double. Applying the returning-visitor split (failure mode F1 if omitted) roughly halves the figure. This is the dominant reason naive web-carbon calculators overstate real sites.
Inputs: the data-centre segment of the annual footprint above · IT energy from the DC per-byte term · hyperscale facility · PUE applied live.
| Step | Calculation | Result |
|---|---|---|
| DC IT energy (4,750 GB × 0.055) | 4,750 × 0.055 | 261.25 kWh |
| × hyperscale PUE high | 261.25 × 1.2 | ≈ 313.5 kWh |
| × GB grid 0.131 | 313.5 × 0.131 | ≈ 41.1 kgCO₂e/year |
The data-centre segment with PUE applied is the line the site owner books as Scope 2 (self-hosted) or Scope 3 Cat 1 (cloud). PUE renders live from the MasterBrain; a green-hosted facility on a CFE-adjusted grid would cut the grid factor on this segment only — not on the network and device segments (failure mode F5).
Implementation Workflow
- Measure page weight. Record total transferred (compressed) bytes per template, including third-party scripts. Use the network panel’s transfer size, not uncompressed size (F6, F3).
- Source the visitor split. New-vs-returning ratio and cached-view data fraction from analytics; SWD default only as a disclosed fallback (F1).
- Select the model. SWD per-byte (default), marginal, or bottom-up; apply to every segment and disclose (F4).
- Assign per-segment grid intensity. Host grid (or CFE-adjusted) on the data centre; visitor-weighted grid on network and device (F2, F5).
- Aggregate to annual. Per-view × view volume with the caching ratio; add embodied if a full-lifecycle figure is required.
- Place in the correct scope. Own server → Scope 2; cloud hosting → Cat 1; visitor side → Cat 11 (§9).
- Run the failure-mode check. Walk F1–F6 before assurance.
Standards Alignment
| Standard / model | Role for website methodology |
|---|---|
| Sustainable Web Design Model v4 | The per-byte operational + embodied energy intensities across the three system segments. The page-default model. |
| ISO/IEC 30134 | Defines PUE and the data-centre efficiency KPIs that refine the hosting segment. |
| Uptime Institute PUE | Empirical basis for the enterprise-vs-hyperscale PUE spread used in §4. |
| EU PEF | Multi-criteria LCA method for an embodied-inclusive digital-service footprint. |
What the Calculator Handles vs What You Decide
The calculator handles
- Page weight → per-segment energy via SWD intensities
- New-vs-returning caching ratio applied to annual data
- Per-segment grid intensity, with WTT companion
- Live PUE and grid reads from MasterBrain
- Operational vs operational+embodied per-view toggle
- Scope tagging of each segment per the governance table
You must decide
- Model — SWD vs marginal vs bottom-up, applied consistently
- Boundary — first-party only vs total transfer incl. third-party
- Visitor split — measured analytics vs SWD default
- Grid basis — host vs visitor-weighted; green-hosting on DC only
- Embodied — operational-only vs full-lifecycle per view
- Hosting scope — self-hosted (Scope 2) vs cloud (Cat 1)
Audit Checklist — Pre-Assurance Pre-Flight
- Caching ratio applied. Annual footprint uses a new-vs-returning split, not full weight on every view (F1).
- Transfer size, not uncompressed. Page weight is the over-the-wire compressed transfer (F6).
- Third-party boundary stated. Whether ad-tech and third-party scripts are in or out is declared; if measured, total transfer is used (F3).
- Single model. SWD / marginal / bottom-up declared and applied to every segment (F4).
- Per-segment grid location. Host grid on data centre, visitor-weighted grid on network and device (F2).
- Green hosting scoped to DC only. No low-carbon factor extended across network and device segments (F5).
- Scope placement correct. Own server in Scope 2, cloud hosting in Cat 1, visitor side in Cat 11 (§9).
- GWP basis disclosed. AR5/AR6 basis of every term stated; no silent mixing of grid (AR5) and embodied (AR6).
Methodology Metadata — for GHG Inventory Documentation
| Methodology | GreenCalculus Website & Digital Service Emissions Methodology v1.0. Composing methodology — no dedicated MasterBrain section; assembled from the digital and grid primitives plus the cited Sustainable Web Design Model. |
| Per-view basis | Page weight × SWD per-byte segment intensities (DC 0.055, network 0.059, device 0.080 kWh/GB operational) × grid intensity. Annual = views × per-view with new-vs-returning caching ratio. Per §3. |
| Model | [ SWD per-byte attributional — default | marginal/OneByte | bottom-up measured ]. State which; apply to all segments. |
| Boundary | [ first-party only | total transfer incl. third-party/ad-tech ]. Third-party attribution between publisher and advertiser stated. |
| Data centre | SWD DC term, optionally refined by facility PUE (MB live: hyperscale 1.1–1.2) and host CFE share. |
| Grid basis | grid.<iso3>.electricity.location_based (GB 0.13096) + wtt_generation (GB 0.03682). Host grid on DC, visitor-weighted on network/device. |
| Scope placement | Own server → Scope 2; cloud hosting → Scope 3 Cat 1; visitor device + network → Scope 3 Cat 11. Per §9. |
| GWP basis | State AR5/AR6 per term; DEFRA grid factors carry AR5 by design — do not mix bases inside one total. |
Version History
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-06-26 | Initial publication. Composing methodology assembled from MB digital + grid primitives. SWD v4 per-byte segment intensities, page-weight→bytes conversion, and the returning-visitor data ratio hardcoded-with-citation pending a future digital.web.* MasterBrain row family. |
Frequently Asked Questions
By the per-page-view model: measure the data transferred for a page view, multiply by the per-byte energy intensity of three system segments — data centre, network, and end-user device — then by the grid intensity where each segment’s energy is consumed, and scale by annual page views. The dominant model is the Sustainable Web Design Model v4. The two figures that matter are the per-view intensity (atomic unit) and the annual footprint (reportable quantity), and the annual figure must apply a returning-visitor caching ratio.
Because most production traffic is returning visitors whose browsers have cached the bulk of a page’s assets. A first view downloads the full page weight; a return view downloads only the uncached portion, often a small fraction. Assuming every view transfers full weight (failure mode F1) can more than double the annual estimate. The worked example shows 5 million views at 2 MB falling from ~254 to ~121 kgCO₂e once a 30/70 new-versus-return split with 25% cached return data is applied.
No. Green hosting decarbonises only the data-centre segment — typically the smallest of the three. The network and end-user device segments run on the visitor’s grid, which green hosting does nothing for. A site that claims to be carbon-neutral because it is green-hosted has addressed perhaps a fifth of its footprint. Apply the host’s low-carbon factor to the data-centre segment only; use a visitor-weighted grid for network and device. Extending the green factor across all three is failure mode F5.
For a complete footprint, yes — and on commercial pages they often carry more bytes than the first-party content. A per-byte model that measures only the site owner’s own assets understates real transfer (failure mode F3). The audit-grade approach measures total transferred bytes including third-party domains. Whether the resulting carbon is attributed to the publisher or the advertiser is a contested boundary decision that must be stated explicitly rather than left implicit.
It depends on hosting and entity. For the site owner, own-server electricity is Scope 2, but cloud or managed hosting is Scope 3 Category 1 (a purchased service), and the visitor-side device and network energy is Scope 3 Category 11 (downstream use). Most modern sites are cloud-hosted, so the owner’s largest controllable lines are Cat 1 hosting and Cat 11 downstream — not Scope 2. The hosting provider books the data-centre electricity as its own Scope 2.
Reduce page weight and improve caching. Page weight sets the bytes transferred per view, and caching determines how much of each return visit is re-downloaded — together they drive every segment. Compressing images, deferring or removing third-party scripts, lazy-loading, efficient fonts, and strong cache headers cut the footprint across data centre, network, and device simultaneously. Green hosting helps the data-centre segment but leaves the larger network-and-device portion on the visitor’s grid.
They share the same three-segment chain and the same Sustainable Web Design Model intensities, but differ in unit and dominant lever. Streaming is measured per viewing hour and dominated by device screen size and bitrate-driven data volume; a website is measured per page view and dominated by page weight and the caching ratio. Both apply the same per-byte data-centre and network intensities, and both place the device term as the largest operational segment.
Related digital methodologies
This is one of GreenCalculus’s eight interlocking digital-emissions methodologies, all sharing the same grid-intensity and PUE factor lineage so their estimates reconcile. See also the AI compute, the Bitcoin emissions, the cloud compute allocation, the data-centre PUE, the end-user devices, the IT asset & e-waste lifecycle and the video streaming methodologies.