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

112 Comments

View All Comments

  • Stephen Barrett - Tuesday, August 12, 2014 - link

    Our test script uses windows API calls to move mouse, click, scroll, type, etc... so it will take some time for us to make an OS X version
  • PhilipJM - Tuesday, August 12, 2014 - link

    I just ran the powercfg /energy command you suggested and noticed that both steam and spotify set the request period to 10000 in the same way as chrome, (version 37.0.2062.68 beta-m 64-bit) on my machine. I hope you can inform them :)
  • The_Mantis - Tuesday, August 12, 2014 - link

    If you uncheck "Enable Hardware Acceleration" (both of them) in Spotify's Preferences, then it will not speed up the timer resolution.
  • lucas1024 - Thursday, August 14, 2014 - link

    The Hardware Acceleration setting did not have any effect on the timer, I also checked other potential culprits like the Flash plugin. I didn't find any setting or plugin that correlated with the timer. If it is an extension that's causing this, it is not something obvious.
  • lucas1024 - Thursday, August 14, 2014 - link

    Never mind, wrong post, and I can't delete it!!
  • Klimax - Wednesday, August 13, 2014 - link

    IIRC Steam uses Chromium. That could explain that.
  • Flying Goat - Saturday, August 16, 2014 - link

    I didn't know that, but looking but looking at the command line steam's subprocesses use, you're absolutely correct. Learn something new every day.
  • a1exh - Tuesday, August 12, 2014 - link

    This would have made for a more interesting read had it been about Android browsers.

    Although a critical bug in Android Chrome and Android Chrome beta has users leaving in droves!
  • johnny_boy - Tuesday, August 12, 2014 - link

    I too would have liked to see similar testing done across various oses.
  • johnny_boy - Tuesday, August 12, 2014 - link

    I would like to see similar testing done on linux and os x. It would make this article massively more interesting.

Log in

Don't have an account? Sign up now