Last week we posted our Browser Face-Off: Battery Life Explored 2014, where the battery run down times of Firefox 31, IE11 Desktop, IE11 Modern, Chrome 36, and Chrome 37 beta were tested on Windows. We used GUI automation to open browsers, tabs, and visit websites to simulate a real user in a light reading pattern. The article answered a lot of questions about popular browser battery life on Windows, but it raised additional questions as well.

Chrome 36 tested with the best battery life, but was the only browser that did not render correctly at 3200x1800 due to lack of HiDPI support. In the Chrome 37 beta, HiDPI support improved rendering but also took a 25% dive in battery life tying it for last place. However, the Chrome 37 beta includes more changes than just HiDPI support (along with some debugging code), so was the battery life penalty from the now-native 3200x1800 rendering or was it something else? After a few more days of testing at 1600x900 with 100% DPI scaling, we can narrow in on an answer.

When both Chrome 36 and Chrome 37 beta natively render at 1600x900 there is less than 3% difference in battery life. Two tests of each browser were performed and the results averaged. The variation between runs was only 1%. Looking at our previous numbers of Chome 36 and 37 beta on the HiDPI setting of 3200x1800 and 200% scaling, the situation is entirely different.

I've added an asterisk here (and clarified the same text on the original article) to indicate Chrome 36 isn't actually rendering at 3200x1800, but rather at 1600x900 and relying on Windows DPI Virtualization to scale up to 3200x1800.

Looking at the numbers, there's some good news and some bad news. The good news is that Chrome 37's new features likely won't hurt the battery life of current users. If you are using Chrome now, you are probably not using a HiDPI display due to the existing blurry rendering. For these users, the pending Chrome 37 upgrade has no significant impact on battery life. The bad news is that if you have been avoiding Chrome due to its HiDPI rending issues, Chrome 37 resolves those issues but also appears to provide worse battery efficiency compared to Internet Explorer. On our XPS 15 that equated to about an hour less of mobility.

Given that this is the first version of Chrome to properly support HiDPI, it's entirely possible – even likely – that there are many opportunities to further optimize the algorithms and hopefully return battery life at least close to Chome 36 levels. A slight dip in battery life is expected as it takes more work to render a 3200x1800 image compared to a 1600x900 image, but a 20% drop seems rather extreme. We'll have to see what future updates bring, but hopefully by noting the discrepancy it will encourage developers to better tune performance.

Not without a complete recreation of the test. As explained when asked in the comments of the first article, this test includes things like manipulating the scrollbar and restarting the browser that can't be scripted from within the browser; and playing back recorded win32 keyboard/mouse events won't work in other OSes. (And even if they could, would need modification for things like close buttons on the other side of the window, etc.)Reply

Ah, restating the browser. Well, on Linux you could use dogtail for that, then the js test kits for the rest. On Mac, as someone else said, automator is what you want.PS:I didn't see those comments on the other thread, so thanks for the info.Reply

Thanks for the quick update and response to user feedback. It's quite interesting to see that the difference is primarily down to resolution. Perhaps a lot of the rendering is still occurring in software and thus missing out on the efficiency benefits of GPU rendering.Reply

If that was the case, wouldn't there be a noticeable difference between 36 and 37 at 1600 x 900? I suspect it's taking advantage of hardware rendering in all cases. The issue is that Chrome 36 is always rendering at low resolution. However, I'm sure with some optimization they can close the gap a lot more.