One other potential area of variability could come from browser extensions - I imagine that users who compare browser power performance are more technical than the median user, and are more likely to run browser extensions (e.g. ad blockers, etc).

Given Chrome has a larger and more extensive collection of extensions, perhaps users who see differences are running more browser extensions in their Chrome installation, which impacts on performance/power usage?

Certainly interesting to see these assumptions put to the test though, and get some data around them. While it looks like it may have fallen behind again a little, I noticed Firefox's browsing performance on Speedometer caught up for a while, contrary to what I had thought/assumed.

I think one big issue is that there are OS specific APIs on Windows and Mac that allow you to only redraw the pixels/layers of the web browser window that have changed, with the unchanged portion retained in memory and recomposited.

We've seen versions of Safari and Edge that leverage those sorts of APIs to deliver better battery life on their respective platforms, but if you are writing a cross platform browser you may not be willing to do extra work for each individual platform.

Several years ago, Firefox adopted the solution Chrome used of dividing the web browser window into large-ish sections, so you could at least skip redrawing sections that had not changed, but that still leaves you doing unnecessary work, just less of it.

Prior to that, the battery drain using Firefox vs Safari on newer machines with higher resolution displays was very noticeable.

https://bugzilla.mozilla.org/show_bug.cgi?id=1422090

What are these APIs? Why isn't this possible on standard cross platform graphics APIs?

Edit: I guess it's probably this sort of thing https://learn.microsoft.com/en-us/windows/win32/directcomp/a...

On the Mac, it's the Core Animation layers API.

All browser engines are cross-platform. Safari may be Mac-only (though there used to be a Safari for Windows), but the rendering is done by WebKit.

We're talking about using features exposed by the OS (the Core Animation layers API in this example) to avoid doing unnecessary work to save battery life.

Any browser could adopt each individual platform's proprietary graphics APIs, but using the same API everywhere (traditionally OpenGL) is less work.

Any browser engine is free to do the work to use per-platform APIs. If your argument is that cross-platform browser engines won't do the work to optimize with platform-specific APIs but that Safari will, WebKit is a cross-platform browser engine and so it adopting CoreAnimation on Apple platforms in addition to supporting other platforms is exactly the same amount of work that it would take for Blink or Gecko to do the same thing.

My argument is that they don't do the additional work, resulting in their energy efficiency deficit.

As pixels per inch and screen size increases, the cost of doing unnecessary rendering work becomes more noticeable.

For my use case, it's quite obvious what's draining the battery: addons. Every trick and feature meant to preserve privacy and to remove visual trash will significantly impact load times, responsiveness, and battery life.

It's all worth it to me, but there's no doubt a web without tracking and ads would easily double my battery life.

It seems obvious to me that uBlock Origin uses less battery than an autoplaying video in the corner of every website you visit. So on balance I don't think it's fair to say the addons are the cause.

With hardware video decoding, video playback is actually remarkably power efficient.

That said, it's been ages since I've last seen an autoplaying video. I only seem to encounter them on American news websites for some reason.

While there will be extensions which increase power consumption the opposite is true for the most used category, that being content blockers. A well-tuned uBlock Origin will cut down radically on the number of requests performed per page, the amount of CPU time wasted on non-essential Javascript, the amount of GPU render time wasted on presenting those horrid moving monstrosities called ads and the amount of energy wasted by the user while he waits for the damn page to stop loading.

Never, ever venture out on the web without a content blocker.

Those extensions usually improve performance, no?

When browsing a site full of JS-heavy ads, sure.

When running a browser performance benchmark, generally not - the ad block extension adds an overhead to the page. I saw this when experimenting with Orion Browser on Mac, which uses the Webkit engine, but adds support for many Firefox and Chrome web extension APIs.

In experimenting with that, I noticed that enabling extensions and using many extensions during benchmarks could easily impact on scores. Even just an ad blocker like uBO had a measurable impact on a benchmark, from my recollection.

Orion is using a web engine that was never really designed to support what they are trying to make it do. Obviously it's just code in the end but a lot of the changes will be made for convenience rather than in ways that make sense if you look at WebKit holistically, because the team is just too small to actually do that. So it is natural that performance suffers.

Depends on what sites you visit, but hooking every single HTTP call and HTML DOM isn't cheap. I often find websites with ads to be just as fast as websites without them, just more cluttered, unusable, and more of a privacy nightmare. The uBO overhead does seem to impact CPU usage, though.

I'll gladly pay the 15 minutes of battery power spent on filtering out that trash.