Research paper on an applied LCA of a webpage (WIP)

Research paper on an applied LCA of a webpage (WIP)

This is work in progress (WIP) ๐Ÿš€ We are documenting our work and path towards making an LCA of our own SDIA website. If you want to get involved, feel to join our open and public steering group meeting. Join the steering group โ†’

Clear principles are guiding the development

To develop the DEF, the SDIA has first outlined clear principles for its development as an overarching, independent approach to quantifying the environmental impact.
  • Transparent: Methodology, framework and calculations must be open and accessible to all stakeholders; digital products & services are enabled to create transparency on their own environmental footprint.
  • Trustworthy: All information gathered and reported must be verifiable and scientifically-proven to ensure trustworthiness.
  • Life Cycle Assessment Approach: Utilize the existing Life Cycle Assessment methodology and collaborate with academia to adapt existing frameworks to be applicable to digital products & services. (Figure 3)
  • Open standard: Create an open standard that is accessible to all stakeholders at no cost and is non-competitive.
  • End-to-end: Make the entire environmental footprint across the supply chain and lifecycle of a digital product & service visible to all stakeholders.
  • Open source: The methodology, tools and frameworks should be part of the collective equity of society to support the reduction of the total environmental impact of the digital sector.
  • Impact focussed: Focus on energy, resource & pollution reduction rather than merely efficiency, in order to combat the climate crisis through minimizing the environmental impact burden created by the digital economy.
The long-term vision for the environmental footprint is to capture all environmental impacts created across the value chain and attribute them to the server-side application, and eventually the userโ€™s usage of that application (Figure 4).
Figure 3: An overview of the relevant impact categories and metrics from the Life Cycle Assessment framework
Figure 3: An overview of the relevant impact categories and metrics from the Life Cycle Assessment framework
Figure 4: Outline of the SDIAโ€™s overall environmental footprint framework and the required lifecycle assessment data & environmental product passports.
Figure 4: Outline of the SDIAโ€™s overall environmental footprint framework and the required lifecycle assessment data & environmental product passports.

Applying the LCA in a scenario: a simple LCA for Digital Products & Services

To simplify the complexity of the LCA itself, we have chosen to focus on two impact categories.
  • Climate change โ€“ total, fossil, biogenic and land use (kg CO2-eq)
  • Electricity consumption (kWh)
  1. Literature review (beginning of June)
  1. Scope & boundaries (half June)
  1. Several iterations of flow models (end of June)
  1. Collecting data (end of September)
    1. Data request for each component (Inky)
    2. Build our own measuring lab (Max)
    3. Host a data collection hackathon (Max)
    4. Request data from third parties (data request)
  1. Organising the data (September)
  1. Using LCA tool (end of July)
  1. Interpreting results/discussion (October)
  1. Conclusion (October)
  1. Publishing the research paper in the journal of Life Cycle Assessments (The International Journal of Life Cycle Assessment) (end of October)
  1. Trigger an academic partner who will reproduce our methodology

Systems View

To get a systems view of a digital product & service, consider the following visual. A digital product & service is a software application which consists of many software components (either existing, open source component or proprietary). The software application requires fuel to operate, digital resources, which are generated by digital infrastructure. We will define the concrete scope in the section below.
Source: Miro
Source: Miro

1. Goal & Scope

To enable people to reduce the environmental impact of the digital product and services they provide.
We have identified our system boundaries: as described in our taxonomy. In our first LCA for a digital product, we will be applying this to loading the homepage of 1 webpage, namely the SDIA homepage.
Out of scope
  • raw materials
  • end of life of developer and customer devices
  • Software obsolescence: we do not include the software having an effect on the hardware life
Assumptions made:
  • Chrome is used by the customer as a browser(data availability, used a lot, not OS bound)
Each build triggers all steps of building the webpage again
  • like manufacturing, taking all the things and making the
  • shipping is the delivery network
Data Quality Goals
Here, we โ€œdefine needs for representativeness, including temporal, geographic, and technological aspects, and completenessโ€ (LCI Data Quality Guidance).
Temporal: We will collect data over 1 year (01-01-2021 to 31-12-2021).
Geological: This is a tricky point within digital infrastructure, as the servers that are being used can be placedd all over the world.
Technological: process design, operating conditions, material quality and process scale
Completeness: The process completeness data quality goal details the system boundary and all flows entering, exiting and within the system boundary.
Data granularity/generality (manufacturing process used)
  • The type of website construction: Static website builder
  • The delivery mechanism of the website: Content delivery network
  • The components used to make the software: Gatsby / React

2. Life Cycle Inventory

Flow model v.1
Source: Miro
Source: Miro
We have started our inventory analysis, and created a first version of a flow model of the product. What are the inputs and outputs if we want to load the homepage of the SDIA website, and what happens if itโ€™s deleted?
A step deeper is to create a Life Cycle Inventory .
Source: Miro
Source: Miro
At the top you see the the state of the product.
In blue you see the different stages of the product, with lines indicating what type of LCA is being done (c2c,c2grave, c2cradle). Under that you see the input in green, or the different components needed to create that product at each stage. We assume to build on the server, and the testing is also done on the build server.
Digital resources are the same for each product used (e.g. servers, computers, and content delivery networks). For our approach, we will used assumptions for digital resources, so we can look at the overall applicability of the methodology. These assumptions are based on [sheet by Oeko institut].