Estimating Digital Emissions
What is the Sustainable Web Design Model?
The Sustainable Web Design Model (SWDM) is a model for estimating digital emissions. It is an open-source, multi-year collaboration between Wholegrain Digital, Mightybytes, Footsprint, EcoPing, and the Green Web Foundation.
The aim of the project is to publish an open, easily approachable methodology for estimating GHG emissions from digital products and services. It is intended to be plug-and-play, reducing the barrier to entry for people and teams who are getting started estimating digital emissions. It also aims to be modular, so that those with specific data relating to their use case for individual parts of the model can easily swap in those values.
This is Version 4 of the Sustainable Web Design Model methodology. If you are looking for information about the previous version of this methodology, you can find that on this archived page.
Understanding the Sustainable Web Design Model
Estimating greenhouse gas emissions from digital products and services isn’t easy. Before starting out, there are a few questions you should ask:
- Why are you trying to estimate digital greenhouse gas emissions?
- How broad or narrow are the system boundaries you need to measure?
- Do you need to estimate operational emissions only, or include embodied emissions too?
System Segments
This model uses the broadest system boundaries possible to represent a comprehensive GHG footprint. The results of this model can be segmented into sub-systems to provide greater insight. These sub-system segments are:
- Data centers: Energy required to house and serve data.
- Networks: An allocation of energy used by networks to transfer data.
- User devices: Energy used by end users interacting with a product or service.
Based on combined information from the International Energy Agency (IEA 2022), research by Anders Andrae (Andrae 2020), and Jens Malmodin (Malmodin 2023) these segments account for a portion of the total system energy used:
| Data centers | Networks | User devices |
| 22% | 24% | 54% |
Broad v. narrow system boundaries
By their very nature, models and estimates are imprecise. The results they produce will either under or over estimate whatever is being estimated. By using broad system boundaries for our methodology, it is likely that the total estimation results produced by this model will overestimate actual emissions. We are comfortable with this trade-off, as we believe that it is better to overestimate now and refine our estimates down as more data comes to light rather than to underestimate and play catch up.
Recommended reading
To better understand system boundaries and the impact they have on estimating digital carbon emissions, read Tom Greenwood’s post Why do estimates for internet energy consumption vary so drastically?
Operational and embodied emissions
Each system segment is further broken down into two categories — operational and embodied emissions. This is done by first looking at the energy used by devices during their manufacturing and operation. These energy figures are converted to emissions by then multiplying them by a grid intensity factor. We go into the breakdown for these sections, which are based on the work in Malmodin 2023.
- Operational: The emissions attributed to the use of the devices in a segment.
- Embodied: The emissions attributed to the production of the devices in a segment.
This is done by first looking at the energy used by devices during their manufacturing and operation. These energy figures are converted to emissions by then multiplying them by a grid intensity factor. We go into this process in more detail later in this post. The breakdown for these sections are based on the work in Malmodin 2023. For each segment, the split of operation emission and embodied emissions differs:
| Data centers | Networks | User devices | |
| Operational | 82% | 82% | 49% |
| Embodied | 18% | 18% | 51% |
Key inputs
There are two key inputs into the Sustainable Web Design Model. These are:
- Data transfer: The amount of data transferred when loading or using a digital product/service. In this methodology, we convert all data sizes to gigabytes (GB) for consistency and to make them more comprehensible.
- Carbon intensity: The default figure used for carbon intensity is the global average carbon intensity of electricity (494g/kWh), which is pulled from the CO2 intensity dataset for “World” of Ember’s Data Explorer. Users may choose to replace the default grid intensity with regional, country, or local values as appropriate. We will aim to update this figure periodically as time allows.
Why we use data transfer as an input
We acknowledge that there has been robust discussion in the web sustainability community on the suitability of using data transfer as a metric when estimating digital carbon emissions. These same debates are also playing out between researchers whose work we rely on to construct carbon estimation models like Sustainable Web Design.
For the Sustainable Web Design Model, we have decided to continue using data transfer as the key input of our estimations. We have done this for several reasons:
• It provides consistency with the previous iteration of Sustainable Web Design, allowing those using the model to compare results over time.
• It is the metric that is most widely used in digital sustainability research. At the same time, we acknowledge the ongoing research community debate around using this metric.
• It is a metric that is easy to understand, and easy to access by developers and non-technical users alike.
• Most importantly, it is a proxy metric to account for the bloatware issue. For instance, over the last ten years, mobile page weight has increased 594%, according to the HTTP Archive’s Web Almanac. This increase in data transfer is a primary driver for the rapid and unsustainable turnover of end-user devices, which is a significant emissions source.
The Sustainable Web Design Model
Average Emissions per Page View (gCO2e) = ([(OPDC × (1 - Green Hosting Factor) + EMDC) + (OPN + EMN) + (OPUD + EMUD)] × New Visitor Ratio) + ([(OPDC × (1 - Green Hosting Factor) + EMDC) + (OPN + EMN) + (OPUD + EMUD)] × Return Visitor Ratio × (1 - Data Cache Ratio))Where:
- OPDC – Operational Emissions Data Centers.
- Green Hosting Factor – The portion of hosting services powered by renewable or zero-carbon energy, between 0 and 1 (see FAQ).
- EMDC – Embodied Emissions Data Centers.
- OPN – Operational Emissions Networks.
- EMN – Embodied Emissions Networks.
- OPUD – Operational Emissions User Devices.
- EMUD – Embodied Emissions User Devices.
- New Visitor Ratio – The portion of first time visitors to a web page, between 0 and 1.
- Return Visitor Ratio – The portion of returning visitors to a web page, between 0 and 1. (What is this? See FAQ)
- Data Cache Ratio – The portion of data that is loaded from cache for returning visitors, between 0 and 1. (What is this? See FAQ)
In the next section, we will walk through each part of the calculation, breaking down each component and including relevant links to data sources.
Calculation walkthrough
At its simplest, the model for estimating website emissions looks like this:
Estimated emissions (gCO2e/GB) = Operational emissions + Embodied emissionsFor the rest of this section we will explain the models for both operational and embodied emissions.
Operational emissions
To estimate operational emissions, first, we define the energy consumption intensity. To do so, we follow a top-down approach, which means that we look at the global energy consumption for each segment, as well as total data transfer. Here are the values we use for our calculations:
- Total energy consumption for data centers: 290 TWh (IEA 2022)
- Total energy consumption for the network: 310 TWh (IEA 2022)
- Total energy consumption for user devices: 421 TWh (Malmodin 2023)
- Total data transfer across the internet: 5.29 ZB (ITU 2023)
By dividing the energy consumption by the total data transfer, we get the energy intensity based on data transfer for each segment:
Energy intensity (kWh/GB) = Energy consumption (kWh) / Data transfer (GB)Then, to get the estimated energy use for each segment, we perform the following calculations (converting TWh to kWh and ZB to GB as we go):
Operational energy intensity data centers = (290 × 109 (kWh)) / (5.29 × 1012 (GB)) = 0.055 kWh/GB
Operational energy intensity networks = (310 × 109 (kWh)) / (5.29 × 1012 (GB)) = 0.059 kWh/GB
Operational energy intensity user devices = (421 × 109 (kWh)) /(5.29 × 1012 (GB)) = 0.080 kWh/GBThe final values we obtain for operational energy intensity are:
- Data centers: 0.055 kWh/GB
- Network: 0.059 kWh/GB
- User devices: 0.080 kWh/GB
Once the energy intensity is known, we can use the carbon intensity previously mentioned to obtain the carbon intensity of data transfer for each of the segments.
Operational emissions for segment (gCO2e/GB) = Data transfer (GB) × Energy intensity (kWh/GB) × Grid carbon intensity (gCO2e/kWh)You can estimate this for each segment, and then sum the totals to get the total estimated emissions. In the example below, we use a global average grid intensity of 494 grams CO2e/kWh which is pulled from the CO2 intensity dataset for “World” of Ember’s Data Explorer. This can be replaced by numbers for the specific country or state where this is known (see FAQ).
Operational emissions (gCO2e/GB) = OPDC + OPN + OPUDWhere:
Operational emissions data centers (OPDC) = Data transferred (GB) × 0.055 kWh/GB × 494 gCO2e/kWh
Operational emissions networks (OPN) = Data transferred (GB) × 0.059 kWh/GB × 494 gCO2e/kWh
Operational emissions user devices (OPUD) = Data transferred (GB) × 0.080 kWh/GB × 494 gCO2e/kWhEmbodied emissions
To estimate embodied emissions, we assume that the values provided by Malmodin are equivalent to electricity consumption with a global electricity emissions factor (421 TWh, Malmodin 2023). For calculating embodied emissions, we have allocated a portion of the total LCA energy consumption to each of the three system segments based on research from Jens Malmodin and co authors in 2023. The values we use are the following:
- Percentage of total embodied energy for data centers: 11% (62 TWh)
- Percentage of total embodied energy for the network: 12% (68 TWh)
- Percentage of total embodied energy for user devices: 77% (430 TWh)
We can then apply the same process as before to estimate embodied energy and plug that into an embodied GHG estimation calculation for each segment.
Embodied energy intensity data centers = (62 × 109 (kWh)) / (5.29 × 1012 (GB)) = 0.012 kWh/GB
Embodied energy intensity networks = (68 × 109 (kWh)) / (5.29 × 1012 (GB)) = 0.013 kWh/GB
Embodied energy intensity user devices = (430 × 109 (kWh)) / (5.29 × 1012 (GB)) = 0.081 kWh/GBThe final values we obtain for embodied emissions are:
- Data centers: 0.012 kWh/GB
- Network: 0.013 kWh/GB
- User devices: 0.081 kWh/GB
Again, in calculating embodied emissions we use a global average grid intensity of 494 grams CO2e/kWh which is pulled from the CO2 intensity dataset for “World” of Ember’s Data Explorer. This can be replaced by numbers for the specific country or state where this is known, although in most cases we strongly recommend that you leave this value as the global average (see FAQ).
Embodied emissions (gCO2e/GB) = EMDC + EMN + EMUDThe breaks out into:
Embodied emissions data centers (EMDC) = Data transferred (GB) × 0.012 kWh/GB × 494 gCO2e/kWh
Embodied emissions networks (EMN)= Data transferred (GB) × 0.013 kWh/GB × 494 gCO2e/kWh
Embodied emissions user devices (EMUD) = Data transferred (GB) × 0.081 kWh/GB × 494 gCO2e/kWhWhere does our data come from?
The sources used for this model are:
- Total energy consumption for data centers: IEA 2022 data
- Total energy consumption for the network: IEA 2022 data
- Total energy consumption for user devices: Andrae 2020
- Total upstream energy consumption: Andrae 2020
- Upstream energy consumption segments split: Malmodin et. al. 2023
- Total data transfer across the internet: ITU 2023 data
- Carbon intensity of electricity: Ember 2022 data
Whenever possible, we exclude data related to cryptocurrency mining and activities from the values that are used in the model.
To update the methodology, we conducted a new literature review, selected relevant values from credible sources, and challenged them in conversation with field experts before final inclusion. Having said that, there are big discrepancies among different sources, and we welcome any input that challenges those values.
Frequently asked questions
The Sustainable Web Design Model is designed to work with well-known standards like the GHG (Greenhouse Gas) Protocol Corporate Standard. It is an attributional model in that it estimates the emissions from a system attributable to an organisation, for their own reporting purposes.
Because we have adopted broad system boundaries, the Sustainable Web Design Model can be used for estimating and reporting emissions from a wide variety of digital activities. This includes, but is not limited to websites, apps, web browsing, file downloads, video and audio streaming, and API responses.
The Sustainable Web Design Model is less suitable if you are looking to identify which specific parts of a system should potentially be optimised to reduce emissions. Since the SWDM is an top-down, attributional estimation model it looks at the entire system and attributes total energy consumed to units of usage. In the case of SWDM, that is gigabytes per kilowatt-hour.
Meanwhile, consequential approaches are bottom-up, and often taking narrower system boundaries. They look at individual components, and estimate the impact those components have as part of the larger system.
Therefore, SWDM can help you estimate the emissions for a whole system segment (e.g data centers, networks, user devices), it will not help you estimate emissions for individual parts of those systems (e.g. emissions for server CPU utilisation).
For a thoroughly detailed explainer on attributional and consequential approaches, we recommend this guide from Hubblo.
We updated most data sources for the Sustainable Web Design Model version 4. We also expanded the methodology, making it possible to estimate operational and embodied emissions separately if desired, or to combine them in one single metric for ease.
Yes, this calculation can be used to estimate emissions from other activities that involve the transfer of data over the internet (excluding cryptocurrency related activities). In the case you want to do this, you can set the New Visitor Ratio, Returning Visitor Ratio, and Data Cache Ratio values to 1 in the calculation.
Although, one should also be aware of how those activities differ from using a web page. For example, when using this model to estimate the emissions from an API, there would likely be a very small impact at the user device segment, but potentially more impact at the data center segment. Such variations are not covered by this methodology, and it would be an exercise for the implementor to make any such changes beyond adjusting the variables mentioned above.
While some members of this group are part of the World Wide Web Consortium’s Sustainable Web Design Community Group, this methodology and the work to maintain it does not fall within the remit of the W3C at this time.
The Sustainable Web Design Model could be considered as a tool to assessing the environmental impacts of websites. Meanwhile, the W3C’s Web Sustainability Guidelines (WSGs) are a repository of recommendations and guidance on how to improve the sustainability of websites that goes well beyond emissions.
If you know the carbon intensity of the electricity grid in which your data center, network, or user devices are located, you should adjust the grid intensity to estimate the operational emissions of that segment. This will give you results that are more representative of how your website is operated and used.
You can obtain location-specific grid carbon intensity information from a variety of sources:
Ember’s Data Explorer
Table A1.3 in this EIB guide
You can also use this global electricity map
Table A.III.2 in this IPCC report, which is specific to data
The Green Web Foundation has added country codes to CO2.js (also pulled from Ember data)
We do not recommend changing the grid intensity value used for the embodied emissions calculations. This is due to the fact that production of nearly all digital hardware products involve a global supply chain. For this reason, we recommend using the global average grid intensity value.
The green hosting factor allows for data center operational emissions to be adjusted for the percentage of hosting that comes from renewable or zero-carbon fuel sources.
The ratio is a value from 0 to 1, representing the percentage of hosting services powered by renewable or zero-carbon energy. For instance, you may know that your hosting provider operates in a region where 40% of total electricity production is from renewable sources. In this case, you would use a green hosting factor of 0.4 in your estimates.
You can check if your hosting provider is a known, verified green host by using the Green Web Foundation’s online checking tool, or their Greencheck API. If your website returns as hosted green in these checks, then you can use a green hosting factor of 1 in your estimates.
The return visitor ratio is a value that represents the number of website visitors who have returned to a page. Since many website cache static assets on the visitors device, this data is neither being transferred via the network or computed in a data center. The returning visitor ratio is used alongside the data cache ratio to reflect this behaviour in estimates. We have made the simplifying assumption that a return visitor will consume only energy on its device to handle the non-cached data.
Yes! If you have actual emissions figures for any segment, you can use those in place for the operational emissions for that segment.
Work on this project is done on a volunteer basis, and no single member of the working group has dedicated time allocated to it. Despite this, the working group aims to periodically review the methodology, and assess it against new research as it comes to light. Future updates may be made to the methodology based on new research findings or new sources of data.
At the same time, we will continue working with the W3C SustyWeb Community Group to further refine the metrics available for and used in estimating digital carbon emissions.
We welcome the robust discussion that has been ongoing for the past couple of years based on this model. We also greatly appreciate the feedback of the community, so that we can continue to improve and refine this model.
If you have feedback on the Sustainable Web Design Model, please contact us.
When sending your feedback, please be sure that you:
• Understand that there’s another human being receiving your feedback. We accept there are some strong opinions in this space, but that is not an excuse for being rude.
• Are clear as to the part of the model you are providing feedback on, and why you are providing the feedback.
• Provide links to relevant research papers, presentations, or data sources. This is especially important if you disagree with parts of the model, and want to suggest changes.
• If you believe that parts of the methodology are incorrect, then please indicate the alternative approaches that you believe should be considered.
We know that this model is used in a number of places. However, we cannot monitor them all. We appreciate any feedback through the method outlined above. Thank you.