Browser Power Consumption

Browser Power Consumption

By Robert Hansen
Date: 12/01/2008

Preface: In the modern era of green energy and power conservation, it is worth looking at methods of conservation that are closer to the average consumer. In combining the areas of modern browser security and the power needs of "rich" or dynamic web pages, an interesting crossover appears, that shows the two concepts work hand in hand with computer power conservation. While this exercise was not a real scientific study, it provided enough evidence to point to clear areas of power consumption in every day web applications.

Overview: By using simple tools, like a Kill A Watt and Windows' own Task Manager, the two provided enough anecdotal evidence to prove what sorts of websites tend to draw the most amperage. By multiplying amperage by voltage, it becomes rather easy to estimate the average draw. However, variance in the amperage over time makes measurements more complex and therefore this cannot be called a scientific study. However, by estimating the average, and performing the tests 100 times per browser, it was quickly apparent which types of sites were causing the most power drain.

SecTheory started with the Alexa 100 for the United States (as of October 24th, 2008), and performed an analysis of amperage over time against the two major browsers (Internet Explorer 7.0 and Firefox 3.0.4), to average out any anomalies. The tests were performed on a standard Dell Inspiron B130 notebook, with a 1.5GHz Celeron M processor and 1 Gig of ram, running fully patched Windows XP SP2. During idling, with no extraneous open processes other than Windows Task Manager and the browser, the normal amperage was measured at .36-.39. When the screensaver was on, the system continued to draw the same power, however, when the power save mode was enabled and the screen turned off the system drew only .23-.25 amps, proving power save on monitors does provide power savings.

Both browsers were fully patched, running the current builds. Both had JavaScript, Java, Flash and Silverlight - the most common client side dynamic programming languages. Of course with browser differences, some technologies were available to some browsers and not others, but no custom settings were enabled. Both browsers were "out of the box". Both browsers block popups naturally, which would have certainly made some sites far more abusive in power needs had they not been enabled, but in the spirit of trying to make both browsers as average as possible, no special settings were changed to provoke an excessive power need as an outcome. We did not click to allow any popups, requests to use or install add-ons or plugins and so on. This surely reduced the power load, but by an unknown amount.

The system itself has built in speakers, which were turned on, which clearly needs power for any sounds or music played by websites. Also, the laptop was using a standard Wireless 802.11b connection using its built in wireless card - which naturally will drive more power on network access, however, this was deemed to be okay, since it was consistent between each browser and across the entire experiment and is commonly used in homes and companies.

Caveats and Assumptions: The major assumption was that the most important measurement was not the amount of wattage pulled as the page loaded, but rather long term power consumption as the browser idled. Of course, users who switch pages often, and have many tabs open will naturally draw more power, but this measurement was far more erratic and difficult to measure. Between each site loaded, the browser was returned to about:blank and the power consumption was stabilized. The goal of this was to reduce the bleed-over of power needs due to onunload event handlers, and so on.

While it was clear that some of the front pages of websites aren't in any way the most abusive when it comes to power usage, rather than trying to illicit a response, we simply wanted a large sampling of the most popular sites. That said, some home pages were nothing more than introductions, and were completely non representative of the actual pages people spend most of their time on. Examples are the profile pages on MySpace, the movies on Youtube, the auctions on eBay and so on.

Like discounting onunload event handlers by waiting for power fluctuations to stabilize between tests, we did our best to reduce "noise" in other ways. By waiting for the page to complete its loading process we removed the network chatter of DNS lookups, 301/302 redirections, first time setting of cookies and more. However, landing pages that said things like "please click here to continue" were not clicked in order to reduce the power needs associated to onmouseover, onhover and onclick event handlers within the browsers. We spent no time analyzing the power consumption differences between http or https but the negotiation of the requests would have been ignored as initial page load fluctuation anyway since we did not use a stable test bed, but rather the live Internet. Although we understand that the average consumer will wait no longer than an average of 8 seconds, we often waited much longer for pages to stabilize before measuring them.

We urge the reader not to take any single value and over analyze the information, as there are a number of variables at play. Only by looking at the numbers in aggregate can any significantly accurate information be gleaned. There was a great deal of potential for human error as some measurements fluctuated heavily long after the page "stabilized" from its initial page loading. Other sites may look different between browsers, or even changed their layouts between the two tests (a good example of this is news sites that change their content extremely often). As a result, it was difficult to reliably guarantee that the page was the same between the multiple runs without built test-beds that were incapable of changing. Therefore, the numbers should be considered only a collective average, rather than looking at any single website metric. Nevertheless, the raw data is available here (please note some of the URLs contain explicit materials).

The Results: There were several significant results that were found during the tests. The first was that the most important attribute of a website in terms of power consumption appears to be things like Flash animations and AJAX. These draw a significant amount of power long after the page has completed. During the tests it was found that the amperage tracked almost perfectly with the task manager CPU graph, visually giving clues as to timed events. For instance, this graph was taken of gamespot.com during the page load spike and clearly shows the spikes of the power usage over time, associated with dynamic timed changes to the website:

This made "eyeballing" the power usage very difficult of course. To make matters worse there were many different types of sites that used this type of rotation for various means. For instance apple.com which looks nearly completely static has a news rotation banner that cycles every few seconds as well, and produces a similar power consumption/CPU graph. Other sites have movies that play for anywhere between ten seconds up to minutes on end. While it's unlikely that most people would sit through the entire movie and continue to idle on those pages, for consistency's sake, if we could sit through it we would. However, it was clear that a single web-page that an average user can interact with, can and does completely peg the CPU. This test should be repeated using faster multi-core hardware architecture to test the sensitivity to web surfing.

The number one most abusive technology appeared to be Flash banner ads. For the most part they are no different than the rest of the site, except that they continue to rotate. They could have easily been programmed to stop rotating after a few seconds, to return the site to a conservative power usage, but they weren't. While other technologies can and did cause power spikes, they caused issues far less often than Flash, making it the least "green" technology we came across. However, JavaScript, Java, VBScript and Silverlight all easily could have caused problems, and they should not be discounted as possible culprits for power consumption.

Going on this theory we took one of the browsers (Firefox 3.0.4) and installed two plugins, NoScript and Adblock Plus. These plugins are two of the most popular for the Firefox browser and both attempt to reduce the annoyances of the Internet by taking measures to white list (in the case of NoScript) and black list (in the case of Adblock Plus). We then took the ten worst offenders and ran them again using Firefox with Noscript and Adblock Plus. The results spoke for themselves:

Browser	Amperage	Watts
Average across entire Alexa 100 in Internet Explorer 7.0	0.414	48.852
Average across entire Alexa 100 in Firefox 3.0.4	0.406	47.908
Average for top 10 power abusers in Internet Explorer 7.0	0.474	55.932
Average for top 10 power abusers in Firefox 3.0.4	0.481	56.758
Average for top 10 power abusers in Firefox 3.0.4 with NoScript and Adblock Plus	0.382	45.076

Given that the normal idling power consumption was between .36 and .39, the fact that Firefox with NoScript and Adblock Plus scored .382 Amps (45.076 Watts), it showed how significant dynamic client side technologies and advertisements are to overall power usage of the average consumer. That's easy to prove since that's exactly what NoScript and Adblock Plus were designed to stop. While the average may not seem significantly different if you look at only the average across all sites, if you compare it against the worst abusers of power, there is a significant improvement (0.1 Amps and over 11 Watts better over the Firefox 3.0.4 without the plugins). To put that in perspective, that's the same savings as it costs to run a 11 Watt compact fluourescent light.

Conclusions: It does appear that it would be possible to surf in a "green" manner. That is, reducing the amount of client side scripting that runs within the browser, returning the browser to a static page while not viewing the page or closing the browser when not in use, and using power save modes built into the operating system. While the differences may appear to be minor in power usage, power consumption does add up over time.

The best way to conserve, of course, is to unplug equipment that is not being used, as even while turned off the laptop still pulled aproximately .01 amps, but while the browser is turned on, there do appear to be ways to surf in a manner that can reduce the power impact. Ultimately, there was no clear "winner" between the two browsers as to which was a less costly for power consumption, without the help of third party software. However, hopefully this paper will serve as a launching pad for future more scientific studies. It should not be considered the de facto authority on the subject, but rather a guide to help future researchers.

Thanks: Special thanks to James Flom for technical oversight and Mauricio Pineda for editing help (Source and details from http://www.sectheory.com/browser-power-consumption.htm).