Results and Analysis

There is a lot to talk about with these results. While Google Chrome's 1ms timer request certainly uses more power than otherwise, everything else about Google Chrome seems to make up the difference -- at least for Chrome 36. Unfortunately, Chrome 37 takes a dive of almost 25% placing it roughly tied for last place with Firefox. Considering Chrome 36 and Safari are the only browsers on our list that do not support HiDPI displays, that could be the difference. I have added an asterisk on the chart to indicate Chrome 36 is not quite doing the same work as the other browsers. There seems to be a significant battery penalty when natively rendering at 3200x1800 instead of 1600x900 and then scaling up via Windows.

Browser Battery Life

It would be interesting to repeat this test on a lower resolution display, but that would be largely academic, as many laptops today ship with HiDPI displays and more are always on the way. To be honest, I'm not sure anyone could actually use Chrome 36 on a HiDPI display without going crazy anyway, so the fact that Chrome 36 leads the pack here is probably irrelevant.

Update: Chrome has been tested at 1600x900

Just to confirm, I did run a powercfg /energy report and Google Chrome was indeed requesting the high resolution timer.

Energy report while Google Chrome was browsing our test web sites

A few of our test websites also contain flash advertisements, so I was curious if these also caused Firefox and IE11 to increase their timers. Running the same powercfg /energy report did not show any timer increase for those browsers.

Energy report while Firefox or IE11 were browsing our test web sites

As for Safari, unfortunately the browser was having all kinds of trouble being automated by our test suite. The browser window would lose focus every ten seconds and result in lost keyboard inputs. Looking into task manager, whenever Safari would lose focus "Windows Error Reporting" would appear in the processes list. After disabling the Windows Error Reporting Service, Safari instead threw unhandled exceptions every 10 seconds.

Tough to automate a program that throws errors every 10 seconds...

Apple's website does not list any known issues regarding this error. Disabling display scaling, running at 1600x900 resolution, and reinstalling Safari did not resolve the issue. Considering Safari for Windows is still on version 5.1.7 from over two years ago and apparently won't be receiving any further updates, we decided it was best to simply exclude the browser from any further testing.

The Test Final Words
Comments Locked


View All Comments

  • asmian - Saturday, August 16, 2014 - link

    Please note - the Pale Moon developer states that it does NOT use 1ms timers, and since this is directly based on FF code (and he does not state that he has changed that part of the code) it is unlikely that FF does either. Maybe there is another app causing this behaviour.
  • lucas1024 - Thursday, August 21, 2014 - link

    And yet in reality it DOES use a 1ms timer, even when all plugins and extensions, as well as hardware acceleration, are disabled. powercfg reports the timer requested by mozjs.dll.
  • rhughesjr - Tuesday, August 12, 2014 - link

    Often beta software will not have all optimizations enabled in order to more easily debug issues. I wonder if that is the case, and would be very interested in seeing this revisited once Chrome 37 comes out of beta.
  • Freakie - Tuesday, August 12, 2014 - link

    Would have been kind of interesting to compared 64bit Firefox (Nightly) to 64bit Chrome, just to see which 64bit version is the best for battery. Would be humorous if Firefox was.

    I use 64bit Waterfox myself, which even though it is a build of the latest version of Firefox, just compiled as a 64bit program. It's compiled using specific optimizations that the Firefox team doesn't use, so it wouldn't be fair to use a 64bit off-shoot version of Firefox, unfortunately.
  • Oxford Guy - Wednesday, August 13, 2014 - link

    Yes, I was wondering why Chrome was tested for 64-bit but not Firefox. However, one might say that Mozilla has been less supportive of the 64-bit variant than Google has been of its 64-bit Chrome variant.
  • AnnonymousCoward - Tuesday, August 12, 2014 - link

    I like Pale Moon over Firefox. No UI BS to deal with.
  • Paapaa125 - Tuesday, August 12, 2014 - link

    It would've been interesting to see how OSX+Safari would compare to Windows+Chore on the same MacBook Pro.
  • tuxRoller - Tuesday, August 12, 2014 - link

    Any chance of running these tests for both osx and linux (fedora, preferrably as they tend to be amongst the most vanilla [least amount of changes from upstream] of the major distros)? Linux, at least, also supports various levels of timer coalescence (timer_slack), and attempts to wakeup as little as possible when not under load. I'd imagine osx does the same.
    Also, firefox has beta, aurora, and nightly that are easy to get ( , ,, and chrome has the same.
  • Samus - Wednesday, August 13, 2014 - link

    Firefox is definitely an underrated browser. It's amazing how it still gets such a bad rap from a few crap versions from years ago. Firefox has been an especially superior browser, in my opinion, since the customizable menu center released earlier this year.
  • xype - Wednesday, August 13, 2014 - link

    This is kinda stupid. Compare Firefox, Chrome and Safari on OS X and Firefox, Chrome and IE on Windows, if you want to get a good idea of the differences between browsers. Eventually Chrome and Firefox on Linux, too, if you have too much time.

    As it is, the Safari "part" is meaningless, and without Safari you don’t even have a "Browser Face-Off". And having Firefox and Chrome compared between Windows and OS X (and Linux) would at least allow people to get a good idea of how much of a difference the operating system makes in these tests.

    I expected a better article, but then, this is still better than no article (and no information), so thanks for it anyway.

Log in

Don't have an account? Sign up now