What we talk about when we talk about the sustainable web, Part 2: Building a Better Digital Carbon Footprint
In Part 1, we reviewed the context of the web, the cloud, data centers, and CDNs. In this post, we’ll talk about how to measure the carbon emissions of a website, and why it requires more than typing a domain into a text field.
What’s a Product Carbon Footprint?
A Product Carbon Footprint (PCF) is the total greenhouse gas emissions generated throughout a product's lifecycle, from raw material extraction and manufacturing to distribution, use, and disposal.
It’s easiest to think about a real, physical object when we talk about a PCF. Your iPhone is a perfectly fine product to consider. Here’s a PCF-ish document from Apple about the iPhone 14 Pro.
Throughout the lifecycle of an iPhone 14 Pro with 128GB of storage, from source materials to construction to shipping to use to discarding and recycling, Apple estimates the device’s carbon footprint is 65 kilograms of CO2e. CO2e, or carbon dioxide equivalent, is a standardized unit used to express greenhouse gas emissions in terms of the equivalent amount of CO2.
What’s a Digital Carbon Footprint?
Software isn’t a physical object, but it runs on physical hardware, with real wires connecting that hardware to a network of other wires, and very real electricity being produced and consumed to move all those bits around.
Have you ever had the experience of asking your computer to do something hard (like me reloading 147 open tabs in quick succession because I can’t find the one I’m looking for?) and hearing the fan whine in response?
Scale that experience up:
- Have you ever walked into a data center and heard the whine of 1,000 server fans keeping things cool while keeping busy websites online?
- Have you ever checked monitoring systems on your company’s data center on a busy day – or in response to an urgent support ticket – to find the temperature of the servers and electricity consumption rising in response to what looks like a DDoS attack?
- Have you ever investigated the root cause of those issues only to find existing performance issues in a codebase that were exacerbated by a spike in traffic?
This is one of those “if you said yes to any of these questions” moments, but it took me years to understand the direct correlation between these occasional issues and increased carbon emissions.
A website’s digital carbon footprint depends primarily on how much electricity it consumes. This is measured over time to reflect real usage patterns.
The most basic version of the formula goes something like this:
But it can get more complex, starting with the Software Carbon Intensity Specification from the Green Software Foundation, which also includes the long-term emissions of the hardware your website runs on, and continuing when we start thinking about ways to reduce the amount of emissions. Making that digital carbon footprint smaller often involves levers like Time and Location.
For now, let’s address those two factors in the basic formula: Electricity and Intensity.
It’s not that hard to measure how much electricity your application consumes, using conventional monitoring tools. I've used dashboards that show a periodic electricity usage total, like kilowatt hours (kWh) over 30 days, 7 days, or even 24 hours, but that eliminates key information, washing out critical detail about what time of day more energy was consumed.
Without that real-time data, we can't properly calculate intensity.
Measuring consumption in real-time isn’t trivial. To do this well, you need to log the data somewhere useful. This allows you to capture waves, shifts, and spikes in traffic and computing as they happen, and to build visualizations that help identify the peaks and valleys.
Why is real-time data necessary to calculate Carbon Intensity?
When we talk about “Carbon Intensity,” the question we’re asking is “Where did this electricity come from?” Was it from coal, natural gas, hydroelectric, solar, wind, geothermal, or nuclear? This is how we answer the question “How green is my website hosting?”
The complexity of the word “where” is a challenge.
We keep repeating this: The cloud is physical. Every website can be traced back to an origin data center. There, a real physical computer (a server) consumes electricity and generates heat. Water and air are being cooled to prevent everything from overheating.
- Do you know where your website hosting platform’s origin data centers are?
- Do you know which one your website is hosted in?
- Do you know which company owns the data center?
We need to answer these questions to get a clearer picture of the Carbon Intensity factor.
At a minimum, if we know the geographical location of the origin data center, we can use tools like Electricity Maps to identify the Carbon Intensity at any given moment.
This is when the "when" comes into play; both the time and the place of electricity usage are needed to effectively determine emissions.
As I type this, the Carbon Intensity in Northern Virginia – home to both a remarkable percentage of the world’s data centers and the author’s family – is 394g CO₂eq/kWh.
All of Virginia is encompassed by a multi-state grid called the PJM Interconnection, and the intensity factor for the PJM is reported in aggregate. At this time, we can’t discern between electricity produced by a wind farm, a solar array, or a natural gas plant to know which electrons were used by our origin data center.
At the time of this writing (4:31pm EST on Dec. 18, 2024 to be precise), the energy mix in the PJM includes about 40% gas, 34% nuclear, 16% coal, and smaller amounts of wind, solar, and hydroelectric, in descending order. That’s not great.
For comparison, Quebec’s intensity number is a tenth of the PJM right now at 39g CO₂eq/kWh, with more than 85% coming from hydroelectric. Great Britain, at 9:30pm at night, is running on 39% wind, leading to a 175g CO₂eq/kWh intensity.
Time and location matter.
The problem with most online digital carbon footprint tools
Visit your favorite search engine and use any combination of words like “website carbon checker” and you’ll find a text field. Type in your URL, click Submit, and after some significant wheel-spinning, the tool will provide you with a score or grade for your site, and perhaps some context and recommendations for improvements.
There are three layers this sort of approach can address:
- Front-end browser performance metrics: Using frameworks like Google’s Lighthouse, similar to familiar flavors of PageSpeed Insights and other Google Webmaster Tools. How fast does the website load, and ideally, what are the slowest parts and how could you fix them? There’s nothing particularly climate-centric about this, but unless you’re increasing emissions by scaling up more servers to meet the demands of a flawed codebase, faster-performing websites will usually use less electricity. Adding carbon-specific libraries like CO2.js to the mix can apply the Sustainable Web Design guidelines and more, including applying some static carbon intensity data to do the last mile math on how much carbon your website is burning when it loads in a browser.
- Application-layer performance metrics: It’s much more rare to see the application layer addressed in simple online “website checkers,” but there are some solid open-source projects that can be used if you have access to the codebase. Cardamon is an interesting one. There are other framework-specific solutions like CodeCarbon.io for Python. Application performance data is a rich area to mine for energy efficiency improvements, but a simple online website checker can’t get this job done.
- Hosting: This is the biggest challenge, and where we think the most hands-on direct review of systems is required to get an accurate answer. What the online website checkers do today:
- Ping the domain to get an IP address
- Search that IP address to find out where it’s hosted
- Check that host against a list of “green” web hosts maintained by the Green Web Foundation.
- Report back with a yes/no answer on whether the domain is on “green” hosting.
The first problem with this approach is that the IP address of a domain owned by any company of a reasonable size is rarely going to reveal the origin data center where the bulk of its processing takes place. What the IP address reveals is often an edge data center, and in many cases, even that is a Point of Presence (PoP) data center for a third-party Content Delivery Network (CDN).
This leads to false positives and false negatives. CDNs exist (helpfully) to improve performance, caching website files closer to the consumer, but they also (unhelpfully for our purposes, but certainly helpful for security reasons) mask the origin data center.
Figuring out where a website is really hosted is a multi-step process that neither the simple online checker forms nor the existing frameworks can reliably resolve.
Who is the intended audience for these simple online digital carbon footprint tools?
Everyone building and deploying these tools means well, and if the result of the check is to let a business know they are earning a failing grade and need to make improvements, that can only be a positive thing.
If you’re using these tools to find out if your own company is on “green” hosting, you either need to dig deeper internally, or you need our help.
On the other hand, if your customers are using these tools to find out whether your website is “green,” false negatives are bad news.
What would a better Digital Carbon Footprint look like?
The whole point of measuring carbon emissions is to provide actionable data about where to start reducing carbon emissions.
Measurement uncovers the “hot spots” in a company, a process, a piece of software, and a website. If you don’t measure emissions, you don’t know which improvements will have the most impact.
A better Digital Carbon Footprint would include, yes, measurement of a website’s front-end, application, and hosting layers, but with much more context added, and recommendations on which areas need the most improvement, along with concrete and actionable advice about how to make progress toward reducing emissions.
A better Digital Carbon Footprint would go beyond the superficial layer of the CDN and dig into the details of where your website is hosted, where its origin data center is geographically located, what kind of sources of electricity are in its mix, how much electricity your application uses on a real-time basis, identify the hot spots in your codebase, and importantly, identify the hot spots in your third-party stack of partners, advertisers, marketing software, and more.
A better Digital Carbon Footprint could involve researching your data center provider’s sustainability policies, reports, emissions, hardware, and approaches to cooling and construction.
A better Digital Carbon Footprint would provide your company with a prioritized list of changes to make, estimates of the potential emissions reduction for each change, and recommended ways to make quick progress.
Want to get started?
Get in touch with us today.