WWWaste, Carbon Footprints, and Real vs. Expected WPO

WWWaste Carbon Footprint Dynamic Infographic

First, a note on a spectacular new (Fall 2012) website that uses an “infographic” approach to calculate carbon footprints.



The site uses published information on carbon footprints and the web (for more, see the “Factoids” page on this site). It then asks users to do a drag and drop of their social network use, estimate time of use, and spits back the amount of carbon they released into the atmosphere.  The site uses an innovative, drag and drop, which creates an intuitive User Interface. For its primary purpose – computing a web carbon footprint – WWWaste does a bang-up job.

However, there are a few issues with the site, which I hope will be addressed in future versions:

1. We need credits to substantiate the numbers given

Quantitative calculations require sources to justify themselves. This information is difficult to discover, though it can be found on inspection. The designers fell into the “mystery meat school” of navigation in the name of cool look-feel. The final calculations (a light web user produces about 1 ounce of carbon per day, a heavy user approaching a pound) are in-line with those reported here, but it would be valuable to see the actual formula.

In particular, we need to know what is included. Is the calculation solely for the data centers? Does it include local power consumption?

Using a recent (16.02) version of Firefox, my attempt to make the “about” work failed – no information. This is in contrast to the otherwise great design for the primary interactive system to calculate your carbon footprint.

2. The site is BROKEN

If you run WWWaste against the W3C validator, http://validator.w3.org, there are quite a few errors.  In other words, the site itself has a higher footprint that it would if it validated its markup correctly. One must practice what they preach!

3. The site’s factoids aren’t connected

While the factoids on the site are impressive, they aren’t connected to the calculation. It would be interesting for a user to compare their own footprint to the carbon footprint of Facebook itself, servers, and so on. Ideally this would show users that their contribution is small, but, as in other environmental causes, “every little bit helps.”

4. But thats…O.K.

Despite these concerns, I salute the creators of the website – it is one of the first that actually shows how sustainability and environmental thinking applies to the virtual world.

Performance Benefits: Real vs. Expected

Another factor we need to look at when avoiding the “WPO is everything” syndrome is outcomes in the real world. Most WPO books list lots of techniques for improving performance, but many, if not most of these techniques don’t always make things more efficient.

In a recent post on Web Performance Today, Joshua Bixby compared the rules from Souders’ books to actual performance he found in tests. The results are quite interesting:

Make fewer HTTP Requests
Benefit in IE6 Benefit in Chrome 19
Image map 25% 20%
CSS sprites
25% 18%
Use a Content-Delivery Network
Benefit in IE6 Benefit in Chrome 19
Image map 14% -2%
Add an Expires header
Benefit in IE6 Benefit in Chrome 19
Expires Header 70% 59%
Benefit in IE6 Benefit in Chrome 19
HTML GZiped 2% 10%
Everything GZiped
24% 44%
Put CSS Stylesheets at top
Benefit in IE6 Benefit in Chrome 19
CSS at top 74% 59%
JavaScript at bottom
Benefit in IE6 Benefit in Chrome 19
JavaScript at bottom 0.13% 18%
Deferred scripts
31% 18%
Make CSS and JavaScript external
Benefit in IE6 Benefit in Chrome 19
Cacheable external CSS, JS 37% 40%
Ajax downloads
42% 45%
 Dynamic inlining of external files  38%  44%
Benefit in IE6 Benefit in Chrome 19
Small script minify 14% 16%
Small script obfuscated
14% 15%
Large script minify  22%  21%
 Large script obfuscated  23%  21%

One thing that leaps out from this data is that some WPO techniques benefit new browsers, while others benefit older ones. In some cases, helping IE6 is not good for Chrome. This implies that, if we are going to do WPO, we need to take browser response to WPO techniques into account. In turn, if our audience is biased to a particularly old or new browser, or to one type of rendering engine (e.g. WebKit vs the world) we may need to adjust our WPO techniques, and even avoide some that will not help our target. Like code maintainability, this shows the trade-off that goes beyond simple optimization that is crucial to a sustainable, versus an “optimized” web.

Another interesting take-home is the limited effect of a Content Delivery Network (CDN), in terms of page speed. WPO doctrine tends to really push CDNs, but the actual results sometimes depart from what is expected. Clearly, CDNs have a place, but they don’t fix problems with slow code, especially when that code runs on browsers with slow legacy JavaScript engines.

In the future, we can expect WPO techniques to lower the reported carbon footprints on WWWaste (hope they update then!). But WPO isn’t a cure-all, and application of web performance needs to consider aspects outside of efficiency. Like other areas of design, sustainability is more than efficiency – and the big picture is needed to create long-term gains, avoiding Jevons’ Paradox.

1 Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.