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

  • normadize - Wednesday, August 13, 2014 - link

    This had the opportunity to be a very valuable test but as it stands, it isn't.

    First, excluding Mac OS X (and Linux) is a big negative - at least it could have had a less misleading title, e.g. add "under Windows" to be fair.

    Secondly, and more importantly, the testing methodology is very vague and doesn't state how often the requests, scrolls etc are made. It also does not say how many tabs were open and what kind of content was browsed (static vs dynamic/animated ratio at least?), which websites?

    The most important aspect is that it seems it does not replay an actual user session of 10+ hours exactly as it happened, with large pauses between clicks and scrolls.

    There is a huge difference between actual idle/low usage and this article's seemingly rushed simulated idle/low usage. An actual idle/low usage spans a lot longer time scale, during which the user is reading (or away) and the browser is taxing the battery due to timers/IRQs of animated GIFs / Javascript / Flash / etc that keeps running in the background and in other tabs. Different browsers behave VERY differently in this scenario. The critical aspect is that this is the state the browser spends most time in.

    As it stands, although I commend the effort, this test is of little use to me, and in my opinion it should not be taken seriously due to the poor methodology and its reporting.

    A true test that lives up to the current (misleading) title would be a replay of an actual real-world browsing session, exactly as the user "played" it.
  • dstarr3 - Wednesday, August 13, 2014 - link

    Surely IE would give you the best battery life, as it would rid you of any desire to use the internet and make you pocket your phone.
  • wantthefun - Thursday, August 14, 2014 - link

    I am on Surface Pro 2 and I find Chrome reduces my battery life more than IE. I have almost quit using Chrome, because of this reason (switched to IE metro). I wonder if the extensions, or running it in a non-simulated environment with all the sync and programs installed makes a difference, else it could be the use of flash... Not sure, but does not agree with my 8 months of experience with this computer, had to make an account to chime in. Thanks for publishing this!
  • hallstein - Thursday, August 14, 2014 - link

    Safari for Windows was discontinued several years ago and should definitely not be included in this article.

    I thought this would be super interesting, especially as Apple have made a big fuss about Safari’s energy efficiency, alas it was windows-only. For mac, this could have been a really interesting contribution to the safari-chrome-firefox debate.
  • janawatson - Monday, August 18, 2014 - link

    I keep seeking for new fighting games. Can anyone provide me some new links? Thank you
  • Heavensrevenge - Tuesday, August 19, 2014 - link

    Then explain this: I set my power plan to "Power Savings and start Chrome AFTER setting to the power savings power plan and here: to see chrome NOT requesting the higher timer WHILE running sunspider twice during the recording period
    AND!thBUCKCT!RxVWNSEbw0b_-tCJCdrc... is the entire energy report that shows all the details of more chrome.exe processes vs just that single screen shot with 1 entry + the timer resolution to show u chrome doesn't ONLY request the high resolution timer no-matter what.
  • djsvetljo - Tuesday, August 19, 2014 - link

    Chrome has huge issues with utilizing graphic card acceleration for videos. It does NOT work on certain pro cards, such as NVIDIA NVS series, as well as certain Intel GPUs. As a result, a video that is a piece of cake for a GPU struggles to play with CPU only resulting in super high CPU usage, which results in high power consumption. I have 3 machines that suffer from the same issue, some don't - it depends on the GPU model. Same machines tetsed with FF or IE and CPU load is times less.
  • darwiniandude - Sunday, August 24, 2014 - link

    Can you test Safari Firefox and Chrome under OS X? And the others under Windows / Bootcamp on the same hardware? Would be good to test and challenge the 'OS X gets better battery life' rumor/myth
  • mtcn77 - Wednesday, August 27, 2014 - link

    Could this Micro-trololo article EVER be biased by any outside variable unbeknownst to the almighty editor? Something other than the new kid in town, the Google? No! ABSOLUTELY NOT! Microsoft Windows is the best engineered piece of hardware and this is an issue for Google to fix (only for Windows).
  • John.S - Sunday, August 31, 2014 - link

    This article is a bit miss leading, in future you may want to consider that these browsers all run differently on different OS. Run these tests again on OSX or Linux and you will find different results. I point this out because you put in Safari due to the "OSX / iOS crowd". This is a "MS Windows" , "browser face-off", not an overall "best browser face-off"

Log in

Don't have an account? Sign up now