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
ernipiggy - Thursday, August 14, 2014 - link
Right. Specially since suspending not visible tabs is a new Safari feature in the upcoming release.jonthanfielding - Saturday, September 6, 2014 - link
It is rather silly, in my own tests on OS X Chrome uses twice as much power as Safari so if I am out and about I use SafariSchwebbz - Tuesday, August 12, 2014 - link
Why no Opera this time? It's more alive than Windows Safari, judging by the rate of updates.Nexos - Tuesday, August 12, 2014 - link
The Opera that is getting updated is the Webkit based one, which would probably perform similarly to chrome, so there is little point in doing a separate test on it. The last bespoke version of opera is 12.17 which is 6 months old now and probably used by a tiny fraction of net users.medi02 - Tuesday, August 12, 2014 - link
"Would probably perform" - eh? Why test Safari then? Isn't it WEbkit based?DanNeely - Tuesday, August 12, 2014 - link
Even before the official forking (celebrated by Google and Apple by deleting millions of lines of the others code from their repos); Safari and Chrome had many major differences in implementation. Different javascript engines was the biggest but far from the only one; IIRC their rendering code used different sub-pixel smoothing rules too.Johnmcl7 - Tuesday, August 12, 2014 - link
At the moment, Opera still looks and feels much like a reskinned Chrome even though it's a year in now. I was hoping by this point we'd have something that looked and behaved like Opera but using Chrome's better supported rendering engine but it's nowhere near that stage and the updates from the developers are not promising. The features they were boasting about in their latest release are additional themes (which are little more than different backgrounds) and when people complain about the features missing from the previous versions of Opera, they're directed to use extensions instead.Obviously other browsers have worked fine with extensions but one of the reasons I liked Opera was because it didn't need extensions, it worked well out of the box with a good range of features. As it stands I don't see the point in using a slightly reskinned Chrome rather than just use Chrome itself and I'm doubtful we'll ever see a proper Opera again. Would love to be proved wrong on the latter though.
ct909 - Tuesday, August 12, 2014 - link
Opera 23 (current) is based on the Chromium 35 rendering engine and the V8 JavaScript engine. It would likely produce different (even if similar) results to Chrome 36 (current).SanX - Wednesday, August 13, 2014 - link
Current versions of Opera are based on the concept "Written by retards for retards"sluflyer06 - Tuesday, August 12, 2014 - link
Like I mentioned earlier, Opera has hardly any users so it really isn't signifigant to include. Opera marketshare is only .87%