Chapter 7. Digital Carbon Footprints
What You Will Learn in This Chapter
Building a more sustainable website is great, but can you actually calculate its emissions? This chapter covers why that’s quite a challenge, with many moving parts.
Estimating a Carbon Footprint
What is the carbon footprint of a website or mobile app? It’s a question I have been trying to find an answer to for several years. My holy grail has always been to find a simple formula that could be applied to a digital product or service to estimate its environmental footprint. Turns out, someone actually owns a patent for that very thing.
More on that in a bit.
Let’s first take a step back. Everything we do produces some measure of waste: eating, driving, working, even breathing. Much of this waste either creates or consists of greenhouse gases (remember CO2e from Chapter 1?). To decipher the level of impact our activities have on the environment, it becomes important to measure, or at least accurately estimate, the amount of greenhouse gases they produce.
Writing for Carbon Management, authors Laurence A. Wright, Simon Kemp, and Ian Williams define a carbon footprint as:[160]
A measure of the total amount of carbon dioxide (CO2) and methane (CH4) emissions of a defined population, system or activity, considering all relevant sources, sinks and storage within the spatial and temporal boundary of the population, system or activity of interest. Calculated as carbon dioxide equivalent (CO2e) using the relevant 100-year global warming potential (GWP100).
According to Nathan Shedroff, author of Design Is the Problem:
A carbon footprint is a way of estimating the amount of carbon dioxide our activities generate, and by understanding this, we can find ways to lower these emissions.[161] It represents the total amount of carbon dioxide our activities generate—from heating our homes to driving cars to eating and drinking to working and living. Carbon footprints are difficult to calculate exactly because there are so many variables. However, most carbon footprint calculators do a great job of estimating our personal or corporate carbon emissions by using averages.
In their book Ecological Economics Research Trends, authors Thomas Wiedmann and Jan Minx offer what is, in my opinion, the most concise definition:[162]
The carbon footprint is a measure of the exclusive total amount of carbon dioxide emissions that is directly and indirectly caused by an activity or is accumulated over the life stages of a product.
Their definition can be broken down to include the activities of individual people, populations, governments, companies, organizations, processes, industry sectors, and so on with consideration not only on direct emissions (such as those occurring presently with internal materials or processes), but also indirect emissions (those that are external and upstream or downstream in the life cycle).
Calculation Criteria
Remember the virtual life cycle proposed by Pete Markiewicz that we discussed in Chapter 1? This could be a jumping-off point for determining where digital products and services use or influence sustainability principles over the course of their lifetimes.
Life cycle assessment | Virtual life cycle assessment |
Materials | Software and visual assets |
Manufacturing | Design and development |
Packaging | Uploaded to the Internet |
Distribution | Downloaded through the network |
Usage | Interaction, user experience, completing tasks |
Disposal | Data erased from client |
It’s important to remember that impacts are harder to measure in retrospect, so keeping the virtual life cycle assessment (VLCA) components in mind as you devise, design, and develop will make estimating impacts easier than trying to decipher them when you’re all done. For digital products and services, this would best be taken on by a product manager versus a designer, developer, or project manager.
Here are some questions to ask at the outset:
How many workstations and devices are you using throughout the process? What are their electricity needs?
How long are your computers running during design and development? (If you already track your time, this can give you a rough estimate.)
How big are your source files? Do they live on an internal server or in the cloud?
Similarly, how big are the files you upload to your server? What’s the total amount of data?
How many users on average do you have per day? How much data do they download? How long do they stay? Where do they come from?
What devices do they use? What are the power requirements of those devices?
How many unused files are taking up space on your servers? How much time/effort/electricity does it take to delete them?
Of course, it’s tough to estimate some of the aforementioned components. Adobe Photoshop, for instance, is 26 years old as of this writing. That’s a long life cycle. How many hours and resources went into making that thing what it is today? Hard to know.
Pete Markiewicz offers some thoughts on VLCA’s usefulness in estimating the footprint of a digital product or service:
Computing carbon footprints in a hardcore faction requires considering the local site’s energy use—along with the energy use by external features needed to keep the site going, or “externalities.” As an analogy, take a hydrogen-powered car. The car itself is highly efficient and hardly pollutes. But at present, hydrogen is created via a steam process which releases lots of CO2. If you also factor in hydrogen loss from the fuel tanks over time and the cost to build a hydrogen infrastructure, the next is more polluting than our current fossil fuel system.
Deep analysis requires including the site, along with the externalities be subjected to an LCA, or Life Cycle Assessment. In other words, you compute the energy footprint of the site, its external resources (e.g., a team of content creators), and sum it over the expected lifetime of the site. Compared to physical projects, this is open-ended but most sites go several years between major design revisions which might provide a stopping point.
In practice, one should do an 80/20 approximation of an LCA, getting a reasonable energy budget for:
Embodied energy of creating the website (including keeping the lights on in the design shop).
Maintenance energy of creating the website (including content maintenance and IT).
Site delivery energy (traditional WPO and web footprint).
Site inclusiveness (how many people could use the site can actually use it).
For international sites, one might use the Web Index (http://webindex.org) to adjust the score, based on the value of the Internet to the target audience by country.”
The VLCA seems to be the most comprehensive approach, but the inventory analysis of a VLCA is also potentially the most complicated to accurately estimate, given the conditions just noted.
Proposing a Framework
For this section, I asked interviewees featured in other sections of this book to outline a potential framework or approach they might use to accurately estimate the carbon footprint of a digital product or service. Here are their answers.
In a 2013 article titled Sustainable Web Design on A List Apart, James Christie proposed a framework for estimating the carbon footprint of a website:[163]
A 2008 paper from the Lawrence Berkeley National Laboratory suggests it takes 13 kWh to transmit 1 GB.[164]
According to EPA figures, the average power plant in the United States emits 1.2 pounds of carbon dioxide equivalent (called CO2e) per kWh produced (other countries have higher or lower averages depending on their energy policy).[165]
If we multiply 13 kWh by 1.2 pounds, we get 15.6 pounds of CO2e—and that’s just to transfer 1 GB of data.
If one million users each download a typical page, which now averages 1.4 MB, that’s a total of 1,367 GB of data.
At 15.6 pounds per gigabyte, that’s more than 10 tons of CO2e.
Mobile data, with its reliance on 3G/4G, is up to five times more polluting—77 pounds CO2 per gigabyte.[166]
If one million mobile users on 3G download a 1.4 MB page, that’s 1,367 GB times 77 pounds, which totals 52 tons of CO2.
In a subsequent interview, James notes that better figures must exist somewhere. In a perfect world, he says, it would be a simple formula, something like:
Kilowatt hours per megabyte of data sent multiplied by the carbon intensity of the prevailing source that provided the power.
That simple formula, though easy to understand, doesn’t take the amount of electricity burned by the end user into consideration. Nor does it take into consideration the amount of energy needed to upload and store the data on servers. Digital products and services have many moving parts and the stats James mentions in his article are constantly changing. For example, the 1.4 MB average page size he quoted in his post is, as of this writing, over 2.4 MB, according to the HTTP Archive.[167]
James notes that the moving target of defining the environmental impact of any online product or service is dependent on three things:
- Storage and transmission
How much energy is needed to power servers and data centers, the telecommunications infrastructure that manages transmission, and the delivery mechanism (for example, 3G uses much more energy than hardwired Internet)?
- Electricity transmission
How much energy is lost in transmission as well as how much energy is used by things like cell towers and electrical transformers to get data from its point of origin to the end user?
- End-point use
What is the amount of energy needed to get data the final meter to the home or device, including how much power that device uses and if there are increases/decreases in power use depending on content served (Flash, for instance, can make people’s machines work much harder and hence use more power)?
Similarly, here’s how sustainability consultant JD Capuano suggested proposing a website sustainability framework to estimate an organization’s digital footprint:
As James himself states, estimating a site’s carbon footprint is tricky and imprecise even on the best of days. The long and short of it is I’d get more recent data and include alternative sources of data to tweak and add calculations to adjust for more realistic usage.
First, are we just talking about the United States? If we are, data released by the government is always dated because it takes time to collect and update. If I were adding rigor to the process, I’d try to track down more recent figures. Similarly, we are in an era when coal plants are being shut down and natural gas plants are coming online to replace that baseload power. Renewables are also coming online each month, though still a small percent of overall power. I would look for related trends that are quantifiable and assess what adjustments could be made, and if none, at least footnote the known differences. I’d also keep an eye at fugitive emissions from natural gas extraction and distribution, which may affect overall emissions reporting in the United States. If we aren’t talking just about the United States, things get a lot more complicated.
Second, I’d revisit the mobile figures. Mobile plans have cut back our data and we don’t want our data throttled back, so people I know use WiFi whenever they can while on mobile. Instead of just looking at 3G/4G network usage, I’d adjust for the percent of time mobile users are on WiFi instead of the network. This would still be imperfect, but better than a blanket approach.
Third, I’d ask if we want to measure the carbon footprint for viewing an average webpage, or the carbon footprint of the average webpage view. These are two different things. If we look at the latter, I’d want to break out sites with the most views—social media sites, Google’s digital ecosystem, Amazon, etc.—and which of those have renewably powered (or free cooled) data centers. This would allow for an adjustment of Christie’s input of emissions related to transmitting 1 GB of data for the term of the equation related to data centers. I would be curious to see if this would result in a meaningful reduction, as in something bigger than a really small decimal. I think you may be more interested in an organization’s website and not all web pages (email, social media, etc.), but I still find this thought fascinating. Measuring both would help determine how well we’re collectively moving the needle.
Building off that last point, if there are industry standard metrics such as I suggested, introducing elements like virtualization, caching, etc., and getting actual measurements from sites would be the way I’d like to see this proceed. We’re a long way off from that and would need cooperation of cloud hosts, etc., but I think it’s the direction in which we need to move.
Shawn Mills from Green House Data states that rough estimation is probably the best we can get:
Like any calculation of this sort, it wouldn’t be completely accurate, as you’d have to rely in most cases on average energy consumption of a personal computer or a percentage of overall energy consumed by a data center over the period of time the app is in use, those types of statistics. If you knew everything about the company and their equipment, plus the users’ equipment, you could get more accurate.
You have to take into account the development time (computers used to create the application, the network traffic consumed, data centers resources, local backup—all of these have energy consumption). Then the energy used by the application itself, which is the data center load plus the users’ own devices, plus the network traffic between them. I’ve seen wildly varying studies on the average energy consumption of one gigabyte of network traffic. So this would be a difficult metric and you’d have to make some assumptions. Even on just the network traffic, you have WiFi versus wireless broadcast versus different types of wired connections...it gets complicated very quickly.
The easiest way to get a ballpark, which is what most carbon footprint–type calculations are providing anyway, would be recording the time used on the app or website, the average energy used per gigabyte of network traffic depending on the connection type, plus the average consumption of the type of device being used (PC, laptop, smartphone...), plus the percentage of the data center’s overall energy use attributable to the provisioned resources used for the application. Then depending on the energy source used to power all of those components you could adjust the overall footprint.
John Haugen from Third Partners, a New York–based sustainability firm offers the following approach:
Like any carbon footprint assessment, the first step is to break down the process into assets and actions. For this digital example, the assets are all the digital data and physical equipment that are needed to produce the page. The actions are all the steps that must be taken to transmit data from the server to the user’s device. Each action requires electricity, and the assets involved determine how much electricity is needed. The overall carbon footprint is a function of:
How many times those assets were called
From what fuel source is the electricity generated
All carbon footprint assessment studies have scope boundaries, primarily to exclude both immaterial aspects and difficult-to-measure assets or actions. In many cases—and especially with complex digital scenarios—it is necessary to use proxies, estimates, and previous research. The reasons for this are both a matter of technical and economic limitations.
Any website carbon footprint should consider pageviews, page size, device type of end user, and any content hosted outside the website by a third party (e.g., YouTube, Soundcloud, Dropbox).
The approach to a mobile app would be similar, except it’s broken down into two action categories.
The initial application download and all subsequent application update downloads
Use of the application
Since the device stores a portion of the application content locally, the digital footprint of calling on local application data is limited to the usage of the device. Of course, any external data would still rely on the Internet for transmission to the device. And since mobile devices and tablets use per-minute a fraction of the electricity of personal computers, the degree to which the app can be operated locally without additional data will have a direct impact on its usage carbon footprint.
Product Science is a London-based agency that partners with organizations that are working on social or environmental problems as part of its business. Here is what its founder Chris Adams has to say on estimating a digital product or service’s footprint:
I would split it between the main phases:
Initial travel and work on the project—commuting to an office, and sitting in air-conditioned rooms uses noticeable amounts of energy.
Once the site is up, I’d measure how much goes into keeping it online, including any external monitoring or analytics services.
I’d also look at the cost of transmission—how much traffic is going to mobile versus desktop, and through that, how much is likely to be traveling wirelessly over 3/4G networks, as opposed to homes and offices.
For a mobile app, I’d consider the same factors, with the adjustments for increased cellular network use.
If you were to try to do this really thoroughly, and factor in the full life cycle of the devices involved, you would amortize the cost of the servers used to run a site, and the typical hardware upgrade cycle of the devices you’re using. This gets really hard, and I’m not aware of any published examples of this.
Finally, I noted at the beginning of the chapter that someone owned the US patent on a digital carbon footprint calculator. After initially filing in 2007, in 2014, Alex Wissner-Gross and Timothy Michael Sullivan received US patent number 8,862,721 B2 for an environmental footprint monitor for computer networks. The methodology outlined in the patent includes the following steps:
Viewing a website embedding with a unique identifying tag from a user terminal.
Identifying the tag associated with the website.
Placing a cookie on a user’s terminal.
Updating the cookie on the user’s terminal with time data.
Updating the environmental footprint detection database.
Calculating the environmental footprint of the website.
This is, ostensibly, the methodology the owners used to create their website footprint calculation tool, CO2stats.com, discussed later in this chapter. The baseline for this would be the time at which the aforementioned unique identifying tag is placed on the website, which means that although you would receive important data on your website’s footprint based on usage, you would still need to assess cradle-to-cradle considerations if you wanted to ascertain a comprehensive impact estimate of its entire virtual life cycle. Plus, given that the patent application was originally submitted in 2007, one has to wonder how the energy footprint of mobile devices factored into this methodology.
All this said, my original intent for this chapter was to find a solid formula for devising an accurate estimation of a digital product or service’s carbon footprint. After all my research and given the complexity of this undertaking as well as the differing opinions on how to approach it, my best answer to a question of how to estimate the carbon footprint of a website would unfortunately have to be the answer that consultants and lawyers give (that everyone hates)....it depends.
Ecograder: A Case Study
As I mentioned in the book’s Preface, my company, Mightybytes, really began paying attention to Internet sustainability issues around 2011, after becoming a certified B Corp. At that time, we explored different ways in which to use our own skills and talent as a force for good. Given the services we offer to clients, focusing on the Internet’s environmental impact made most sense. Plus, I read Greenpeace’s annual Clicking Clean report for the first time in 2012 as well as Pete Markiewicz’s article “Save the Planet Through Sustainable Web Design,” which really influenced our thinking about these issues.
Thus, we began figuring out how to apply what we learned during the process of becoming a B Corp to our entire business, not just the environmental impact of our office supplies, lighting, and so on. We started offering better healthcare benefits, paid volunteer time, and many other things companies do as part of the B Corp certification process.
We were also just getting underway on what would eventually become a long, drawn-out saga trying to find reliable web hosting powered by renewable energy, so the Internet’s environmental impact was front-of-mind at the time.
During the 2012 B Corp Champions Retreat, the annual conference for B Corps that took place that year in Half Moon Bay, California, attendees were given downtime to connect and brainstorm ideas for using business as a force for good. During an oceanside stroll with a coworker and fellow B Corp owner, the idea for Ecograder was hatched.
Vision and Goals
Our hope was to create something as easy to use as HubSpot’s Website Grader—put in a URL and go—that would help website owners, designers, and developers better understand that, however small, their site has an environmental impact.
We also wanted Ecograder reports to provide easy-to-understand, actionable roadmaps for improving efficiency in website performance, “findability,” and user experience (UX), given that they were natural extensions of a more sustainable website. Of course, not everyone understands CSS sprites and content delivery networks (CDNs), but site owners could easily share the report with web teams using a simple link displayed directly below the score.
Another long-term goal was to connect users to green web hosts or resources for carbon offsets. At the very least, we wanted users to better understand why powering their site with renewable energy is important.
Finally, while the minimum viable product (MVP) for Ecograder was based on the idea of building awareness, the long-term business case should also be sustainable.
The Business Case
Because Ecograder was an app built by an agency, its business case was a little different than your standard startup. Even though we had aspirations of eventually making Ecograder a freemium model (free for basic services, pay for others), there were other important considerations, as well:
- Awareness
Ecograder should first and foremost bring awareness regarding the Internet’s environmental impact.
- Profit
It should have a roadmap for income generation:
As a lead generator for Mightybytes.
Potentially as a Software-as-a-Service (SaaS) product.
- Education
The process of building it should educate our team on Agile and Lean startup methods.
- Advocacy
The launch, which we decided to do on Earth Day, should encourage companies to think more sustainably about their online properties.
To date, we have made good on all the preceding considerations except for finding the elusive SaaS revenue stream. In talking to a wide variety of sustainability consultants, general consensus was that for numerous reasons, lack of awareness among them, Ecograder’s value proposition isn’t something people would pay for.
The Methodology
The biggest challenge by far was to devise a product methodology that increased awareness while providing actionable reports and also staying within our tight timeline, budget, and resource constraints. In other words, how could Ecograder quickly crawl a website without losing users and still provide easy-to-understand data that can help make sites more sustainable?
We knew with our constrained resources and timeline it would be impossible for the product to crawl an entire website and estimate the entire carbon footprint. For all the reasons mentioned earlier in this chapter, we decided that estimating a website’s actual carbon footprint would not be within the scope of our MVP. To do so would undermine the “input your URL and go” simplicity we wanted and we simply didn’t have the resources to take on a project of that scope.
We also knew that many of Ecograder’s desired metrics could be generated by existing tools with APIs we could tap into and extract relevant data. Here’s the methodology we came up with:
Ecograder analyzes the contents of a web page (HTML, CSS, JavaScript, images, and hosting information) and runs a series of tests to compile a score. We devised several tests to help determine your cumulative score. These tests are meant to answer the following questions:
Is your site hosted with a hosting provider that powers its servers by renewable energy?
How many HTTP requests are made?
Is your page optimized using industry standard methods?
How easy is it to find your website?
Will your site work on mobile devices?
Did you avoid using Flash on your site?
Each of these tests produces a single score that is then weighted to help produce the final output score of Ecograder.
Green Hosting
Ecograder scores green hosting high in its algorithm because the single biggest positive effect your website can have on the environment is to host it with a provider that runs on 100% renewable energy. After all, the servers that host websites require power 24 hours per day. Our challenge was to decipher whether a site was hosted by a green host and then score accordingly.
Green hosting methodology
We initially created a homespun list of hosting providers that powered their data centers with 100% renewable energy. That quickly proved problematic (more on that in a bit). We then tapped into the Green Web Foundation’s API to access its much more comprehensive database of green hosting providers. Through data provided by its API, Ecograder gives 15 points for providers that used renewable energy credits (RECs) or offsets, and the full 25 points for onsite renewable power.
Performance optimization
The challenge was to score sites based on how quickly they loaded and whether they followed standard practices for performance optimization. We decided that Ecograder would measure performance optimization in three ways: running a site’s Google PageSpeed Insights score, measuring the number of HTTP requests the crawled page makes, and assessing the site’s use of shared resources.
Google PageSpeed insights
This easy-to-use tool from Google offers recommendations for improving the performance of any web page. It also provides an overall score based on how many best practices are followed by a crawled page. We decided to use this overall score as a metric in Ecograder’s algorithm.
HTTP requests
To render a page in a browser, HTML pages send requests via HTTP to the hosting server for page components like stylesheets, images, JavaScript, and so on. Each HTTP request takes a certain amount of energy to complete and time to load, so more requests means longer wait times for content and more energy wasted. Reducing HTTP requests can improve both site performance and energy efficiency. Ecograder counts HTTP requests and assigns a score based on averages.
Shared resources
When you surf the Web, many of the sites you visit pull resources from common frameworks. Enabling your browser to access any resources that are already cached—rather than downloading them again—saves time, energy, and bandwidth. Ecograder assesses use of shared resources and assigns a score based on percentage of the page’s total weight that is shared.
Findability
Our challenge was to help Ecograder determine how easy a site’s content is to find on the Internet. Sites that are optimized for search help users find what they need faster because their content ranks higher in search engines. When users input search terms, they shouldn’t have to navigate dozens of pages to find what they need. The process uses less energy when sites are search-optimized. We decided on MozRank to assess site findability.
MozRank
Created by Moz, a Seattle-based inbound marketing software company, MozRank is a “general, logarithmically scaled 10-point measure of global link authority (popularity). Because measures like MozRank are global and static, this ranking power applies to a broad range of search queries rather than pages optimized specifically for a particular keyword.” Like Google’s PageRank, MozRank takes advantage of the democratic nature of the Web. Your rank reflects the importance of your web page on the Internet. Ecograder uses your page’s MozRank to add points in this category to its scoring algorithm.
Design and UX
Design is already subjective in nature, so the challenge of using software to assess a site’s usability proved quite a challenge when devising scoring metrics for this Ecograder category. We explored many options, but we landed on two: mobile optimization, and whether a site uses Flash. The latter is less relevant now than it was in 2013 when we built Ecograder, but plenty of video and ad-heavy sites still use Flash to embed that content, even though in 2014 Google began penalizing sites that do this.
Mobile optimization
For the purposes of scoring, we define mobile optimization in two ways: sites that have separate experiences for mobile devices, and sites that are built with responsive design. Both of these approaches result in more energy-efficient sites because they both require streamlined content and design assets that load quickly. Ecograder analyzes the site’s contents and qualifies a site as being mobile optimized if any of the following criteria are met:
The stylesheet declaration contains the term
min-widthormax-widthThe stylesheet contents reference
@mediaThe site returns different style.css files when the user agent string is set to emulate a mobile device.
Use of Flash
As noted earlier in this section and in Chapter 5, Flash consumes more energy than standards-based equivalents and doesn’t work on most mobile devices, including all Apple and Android operating systems. From both an energy efficiency and performance standpoint, Flash is not the way to go, so we programmed Ecograder to look for embedded .swf files on pages it crawls and penalize a site’s overall score accordingly if it finds any.
The Process
Ecograder went from concept to MVP in 11 weeks. Though the initial product was far from perfect, we considered it a success for many reasons. For the first time, with a few fits and starts, we used Lean/Agile methods on a project start to finish. We attempted to validate every hypothesis along the way through sprints while also sticking to an aggressive production timeline. We collected many email addresses. We even got a few client leads.
Here are some things we learned in the process:
The 11-week timeline was aggressive—it caused some stress, but also motivated our team to rally around getting an MVP to market quickly without sweating every little detail.
Folding UX deliverables into product sprints driven by features proved challenging for our design team at the time.
Working with reporter timelines while also sticking to an Earth Day launch made for some long days.
It is also important to note that we were juggling client work at the time, too. Most work on Ecograder happened in dedicated work sessions purposefully scheduled around client deadlines.
Over the contracted timeline, we focused on research, competitive analysis, sprints, and design and UX. The following sections look at each of these areas more closely.
Research
For starters, we interviewed dozens of agencies, sustainability practitioners, and B Corp community members to ascertain whether the idea was viable and if we could find a product-market fit. Feedback was encouraging, though many expressed trepidation over the value proposition being something for which they would consider paying. Most people didn’t realize that Internet sustainability was a thing they should pay attention to and noted that the interview process opened their eyes. Based on the awareness factor, target users encouraged us to proceed.
Competitive analysis
We ran a competitive analysis and found others trying to address these same issues:
- Greenalytics[168]
An open source tool developed at KTH Royal Institute of Technology in Stockholm, Sweden, Greenalytics mashes up data from Google Analytics and environmental research to estimate the carbon footprint of websites, including server, infrastructure, and final user. Its data is open source and posted to GitHub. The last GitHub update was made in 2013.
- CO2 Stats
A pay-per-month service, CO2 Stats calculates your website’s environmental footprint, finds ways to make your site more energy-efficient, automatically neutralizes its calculated carbon footprint, and displays a green-certified “trustmark” on your site.[169] Owners of this site own the previously mentioned patent on calculating a website’s carbon footprint.
- Web Energy Archive Ranker[170]
Created by Green Code Lab in France, this tool pulls data from the HTTP Archive, Webpagetest, and the Power API to track Internet energy use trends and raise awareness of energy consumption and environmental footprint. Of the three resources noted here, this one seems to still be an ongoing concern and provides the most comprehensive information.
These tools were critical in helping us stay focused on simplicity in usability.
Sprints
Sprints were driven by specific integrations and occurred in one- to two-week timeframes, depending on our existing client workload and complexity of the integration. After we had an initial roadmap based on the methodology just outlined, we were able to quickly pull data from the APIs we identified.
Design and UX
As I noted earlier, our design team at the time struggled with how to incorporate deliverables like wireframes and visual comps into the Agile processes we used to build Ecograder. They also struggled initially with making more sustainable design choices. As Pete Markiewicz notes, “Designers can’t just follow their muse—they must balance against the needs of their audience (UX) and the environment (design carbon footprint).”
We’ve since learned that challenges integrating design practices is common for teams just getting started with Agile methods and have incorporated techniques such as those outlined in Chapter 5 to address this. Of course, we have become better at incorporating more sustainable choices into our design process overall, as well.
Creating Ecograder Content
To make Ecograder’s reports more useful, we wanted to link out to additional resources that could help site owners and product users make their sites more efficient and environmentally friendly. But the problem was that most of those blog posts didn’t exist anywhere on the Internet. Sure, there were posts all over about how to use techniques like CSS sprites, shared libraries, and so on, but none specifically addressed why those were more sustainable strategies. Our content team went to work creating a series of posts to bridge the gap between Ecograder’s metrics and efficiency-driven web design techniques.
Promoting Ecograder
It was mentioned previously that advocacy was part of our strategy for Ecograder. Not only did we want to use these techniques on our own sites, but we wanted others to embrace them too...or at the very least, be aware of them. To accomplish this, our content team worked with a PR team to run every one of the Fortune 500 companies’ websites through Ecograder and track the scores. We shared this data with a few members of the press, which resulted in an article on Fast Company’s Co.Exist blog titled “Measuring the Efficiency of Fortune 500 Websites.” It was also covered by a number of other blogs and media outlets, including Chicago Sun-Times and Sustainable Brands.
Results
Although we haven’t yet cracked the nut of how to make money with Ecograder, it has generated positive business results for Mightybytes. Above and beyond the aforementioned press coverage, it has provided other benefits:
We have used it to benchmark site performance for clients who care about sustainability.
It has crawled thousands of URLs and connected us with thousands of users all over the world who are using it to benchmark the creation of more sustainable websites.
It gets regular mentions on social networks.
For much of the first year after launch, it was one of the highest ranking pages on our site.
It has resulted in speaking engagements around the United States, a TedX Talk, and was part of the pitch for writing this book.
On Earth Day 2016, three years after its initial launch, we collected data from nearly 70,000 website crawls by Ecograder and created infographics with the data, including that slightly more than 2% of the sites crawled were hosted on servers powered by renewable energy and only 24% were optimized for mobile devices.
For all these reasons, we consider Ecograder a great success. It met nearly all of the considerations in our business case. It has helped differentiate Mightybytes from the hundreds of thousands of other agencies out there that do what we do, and it has raised awareness on the issue of Internet sustainability.
In keeping the entire product life cycle in mind, was the process of creating Ecograder as sustainable as the product itself? For the short term, I’m sure there were many things we could have done more efficiently. We could have been more Lean in our user research. We have hosted it on a handful of different green web hosts, with mixed results. The design has evolved over time. Over the long haul, however, creating Ecograder helped our team become more proficient at Agile methods and we gained consensus on which design and development techniques should be considered more sustainable than others. All in all, the learning opportunities far outweigh any extra resources we might have used during its creation.
Ecograder Benchmarking
Here’s how we use Ecograder to help clients improve their websites. Climate Ride is a US-based nonprofit that produces charity endurance events that raise money for the environment, active transportation, and sustainability. Participants register for these transformative, multiday events and use peer-to-peer fundraising techniques to raise money for one or more nonprofit beneficiaries. Like many small nonprofits, the organization takes a Lean and iterative approach to its growth while always paying attention to people and planet as they scale. Its website is no exception.
Mightybytes redesigned Climate Ride’s original website back in 2011. At that time, as part of the redesign, the site was migrated to a hosting provider powered by 100% renewable energy. Two years later, we ran the site through the first version of Ecograder. Even though Ecograder didn’t provide every metric needed to make Climate Ride’s site more efficient, its scoring mechanism was enough to help its team better understand how recommended improvements would make its site more efficient and environmentally friendly while also enhancing UX.
Climate Ride’s initial Ecograder score in 2013 was 71. Because Ecograder gives 25 points out of the total 100 available for green hosting, we can safely say that their score would have been at 46 prior to 2011. This low score was not at all a reflection of the organization’s overall environmental impact; however, it was a great place to begin benchmarking website sustainability.
In 2014, we again updated their website to continue improvements to the sustainable web design concepts outlined in this book. The following sections outlines some of the things we improved.
Findability/SEO
Mightybytes streamlined the content structure of Climate Ride’s site to make popular content types easier to find, cutting down on user search time. We continue to improve the site’s search engine results by optimizing pages, helping them create qualified inbound links, and so on. Also, the scenic beauty of Climate Ride’s events makes photos a big part of its online marketing strategy, so Climate Ride performs very well on social media, which is the second highest referral channel behind direct traffic. As soon as users from social networks—like all users—are on the site, our efforts help them get to the content they need quickly.
Design and UX
Similarly, common user interactions such as finding a rider, registering for an event, or donating were given more prominent placement in the site interface, again in an effort to get users to the content they need quickly. Responsive design improvements helped make the site more mobile friendly.
Performance Optimization
Large background images, which each triggered a separate server request and ranged anywhere from 60 to 300 KB per image, were removed.
The home page slideshow, which sometimes contained up to 10 images, was replaced with a single, lightweight hero image, significantly cutting down load times and server requests. The Mightybytes team also introduced Climate Ride to tools like Smush.it, PicMonkey, and ImageOptim to further compress site images.
During this time, Mightybytes also updated Ecograder’s scoring algorithm, adding more metrics to check against. After the site overhaul, Climate Ride’s website scored a 91, a notable improvement of 45 points over the 2011 website.
As a small, virtual nonprofit working primarily with online tools, Climate Ride has always focused on implementing sustainability in all aspects of its operations. It is committed to providing optimized, energy-efficient online communications that serve our community’s needs and, whenever possible, are powered by 100% renewable energy.
Conclusion
We covered just how complicated it is to estimate a website’s carbon footprint in this chapter. Herein lies a big challenge with Internet sustainability. With the Greenhouse Gas Protocol, we have a standard process for estimating greenhouse gas emissions. We could apply that process to a business or even to a data center and generate a relatively accurate estimate of that entity’s emissions. This would give us a better understanding of that entity’s environmental impact in terms we could easily understand.
But if you’re talking about an end-to-end assessment that includes all the potential variables where a digital product or service might have potential environmental impact—from the process of its creation to its hosting and distribution through the infrastructure that serves it to end-user devices—this becomes an incredibly complicated undertaking. Until someone cracks this nut, however, it is difficult to talk about Internet sustainability in terms we can gain consensus on and easily digest.
In the meantime, if someone wants to fund a research grant, this would be a good, meaty project.
Action Items
Try these things:
Use Ecograder to benchmark your site score.
Identify a list of potential improvements.
Improve your site and track score improvement.
How would you estimate your website’s carbon footprint?
[160] Laurence A. Wright, Simon Kemp, and Ian Williams, “‘Carbon Footprinting’: Towards a Universally Accepted Definition”, Carbon Management 2:1 (2011): 61–72) (http://www.tandfonline.com/doi/abs/10.4155/cmt.10.39)
[161] Nathan Shedroff, Design Is the Problem (Brooklyn, NY: Rosenfeld Media, 2011). (http://rosenfeldmedia.com/books/design-is-the-problem)
[162] Thomas Wiedmann and Jan Minx, “A Definition of ‘Carbon Footprint” in Ecological Economics Research Trends (New York: Nova Science Publishers, 2007), 5.
[163] James Christie, Sustainable Web Design, A List Apart, September 24, 2013. (http://alistapart.com/article/sustainable-web-design)
[164] Cody Taylor and Jonathan Koomey, “Estimating Energy Use and Greenhouse Gas Emissions of Internet Advertising”, February 14, 2008. (http://evanmills.lbl.gov/commentary/docs/carbonemissions.pdf)
[165] US Environmental Protection Agency, “Energy and the Environment”. (http://www.epa.gov/cleanenergy/energy-resources/calculator.html)
[166] Rainer Schoenen, Gurhan Bulu, Amir Mirtaheri, and Halim Yanikomeroglu, “Green Communications by Demand Shaping and User-in-the-Loop Tariff-Based Control”, Proceedings of the 2011 IEEE Online Green Communications Conference (IEEE GreenCom’11). (http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6082509&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6082509)
[167] HTTP Archive, “Interesting Stats”. (http://httparchive.org/interesting.php)