Browser Face-Off: Battery Life Explored 2014
by Stephen Barrett on August 12, 2014 6:00 AM ESTResults 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.
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.
Facebook
Twitter
RSS
112 Comments
View All Comments
zodiacsoulmate - Tuesday, August 12, 2014 - link
Also where is the CPU load graph? would love to see it !NatePo717 - Tuesday, August 12, 2014 - link
Could we see some numbers for Pale Moon?BillBear - Tuesday, August 12, 2014 - link
Safari is already scriptable using OSX's built in Applescript scripting system, so you don't have to invent anything new. At worst you'll have to pick up a bit of a new scripting language.I'm looking forward to seeing how Apple's claim that they spank the other browsers on energy efficiency pan out..
Oxford Guy - Wednesday, August 13, 2014 - link
There is also a program called Automator. http://macosxautomation.com/mabellon - Tuesday, August 12, 2014 - link
Could you clarify the following please: "Additionally, the browsers are all run in private browsing mode to prevent local content caching from interfering with reloading our limited set of server-cached sites."Don't most browser have one big session for all in-private tabs? So there will be caching across tabs and sites until you close every instance?
Please consider using a more standard laptop in the future. A quad core 37W CPU seems incredibly unrealistic. Something more along the lines of a 15W/17W CPU would make sense. The power profile of an ultrabook will likely be vastly different to this beast. That would seem to matter a lot more given the trade off in rushing to idle, and the cost of idle wakeups will vary by CPU by some amount. Just my 2c.
Stephen Barrett - Tuesday, August 12, 2014 - link
Good question. The automated test does open up several private browsing tabs but it closes them all (and the entire browser) between iterations.Intel power gates unused cores so there shouldn't be too much difference between a dual core and a quad core for idle power. I agree it would be interesting to test other hardware as well. Unfortunately these tests already take days, so using an even lower power laptop will make it take a really really long time and would probably just exacerbate the differences we already observed even more.
KhalidShaikh - Tuesday, August 12, 2014 - link
Great write up.lucas1024 - Tuesday, August 12, 2014 - link
Bad news - I checked the timers with Firefox on two different machines and on both Firefox is maintaining a 1ms timer.linj - Wednesday, August 13, 2014 - link
I can confirm this. Tested Firefox with a new profile (no extensions), and navigating to most websites (but especially Flash-enabled ones) will ramp up the 1ms timer. Closing down to even a blank page doesn't release it.Stephen Barrett - Wednesday, August 13, 2014 - link
Strange. I did not see that in my testing. I wonder what the difference was.