Firefox Performance Update #4

Another week, another slew of Firefox performance updates for you fine folks!

Firefox contributors have been hacking away to make Firefox faster in a bunch of different ways. Have you seen a bug land recently that improved Firefox performance? Let me know so I can include it in an upcoming post and give these contributors the recognition they deserve!

So let’s get to it – here’s what’s been happening lately:

Firefox Performance Update #3

Hi! I’ve got another slew of Firefox performance work to report today.

Special thanks to the folks who submitted things through this form to let me know about performance work that’s taken place recently! If you’ve seen something fixed lately that’ll likely have a positive impact on Firefox performance, let me know about it!

So, without further ado, here are some of the folks who have made some nice improvements to Firefox performance lately. Thanks for making Firefox faster and better!

Firefox Performance Update #2

So I’ve had my eyes out, watching for bugfixes that are landing in the Firefox code base that will speed it up for our users.

But I can’t do it alone. So I have a request: Have you seen a bugfix land recently that’ll likely impact Firefox’s performance in a positive way for our users? If so, I want to hear about it, and you should fill in this form to let me know!

Here’s that link again, just in case you missed it.

Anyhow, without further ado – here’s a small selection of interesting bugs that have been fixed recently that should improve Firefox performance!

Firefox Performance Update #1

In an attempt to fill the shoes of Ehsan’s excellent Quantum Flow Newsletters1, I’ve started to keep track of interesting performance bugs that have been tackled over the past little while.

I don’t expect I’ll be able to put together such excellent essays on performance issues in Firefox, but I can certainly try to help to raise the profile of folks helping to make Firefox faster.

Expect these to come out pretty regularly, especially as we continue to press our performance advantage over the competition. Maybe I’ll come up with a catchy title, too!

Anyhow, here’s the stuff that’s gone by recently that I’m pretty stoked about, performance-wise! To everybody in this list – thanks for making Firefox faster!

  1. Like this one! Check out Ehsan’s blog for the rest of the series. ↩

Making tab switching faster in Firefox with tab warming

Making tab operations fast

Since working on the Electrolysis team (and having transitioned to working on various performance initiatives), I’ve been working on making tab operations feel faster in Firefox. For example, I wrote a few months back about a technique we used to make tab closing faster.

Today, I’m writing to talk about how we’re trying to make tab switching feel faster in some cases.

What is “tab warming”?

When you switch a tab in multi-process Firefox, traditionally we’d send a message to the content process to tell it to paint its layers, and then we’d wait for the compositor to tell us that it had received those layers before finally doing the tab switch.

With the exception of some degenerate cases, this mechanism has worked pretty well since we introduced it, but I think we can do slightly better.

“Tab warming” is what we’re calling the process of pre-emptively rendering the layers for a tab, and pre-emptively uploading them to the compositor, when we’re pretty sure you’re likely to switch to that tab.1

Maybe this is my Canadian-ness showing, but I like to think of it almost like coming in from shoveling snow off of the driveway, and somebody inside has already made hot chocolate for you, because they knew you’d probably be cold.

For many cases, I don’t actually think tab warming will be very noticeable; in my experience, we’re able to render and upload the layers2 for most sites quickly enough for the difference to be negligible.

There are certain sites, however, that we can’t render and upload layers for as quickly. These are the sites that I think warming will help with.

Here’s an example of such a site

The above link is using SVGs and CSS to do an animation. Unfortunately, on my MBP, if I have this open in a background tab in Firefox right now, and switch to it, there’s an appreciable delay between clicking that tab and it finally being presented to me.3

With tab warming enabled, when you hover over the tab with your mouse cursor, the rendering of that sophisticated SVG will occur while your finger is still on its way to click on the mouse button to actually choose the tab. Those precious milliseconds are used to do the rendering and uploading, so that when the click event finally comes, the SVG is ready and waiting for you.

Assuming a sufficiently long delay between hover and click, the tab switch should be perceived as instantaneous. If the delay was non-zero but still not long enough, we will have nonetheless shaved that time off in eventually presenting the tab to you.

And in the event that we were wrong, and you weren’t interested in seeing the tab, we eventually throw the uploaded layers away.

On my own machine, this makes a significant difference in the perceived tab switch performance with the above site.

Trying it out in Nightly

Tab warming is currently controlled via this preference:

browser.tabs.remote.warmup.enabled

and is currently off by default while we test it and work out more kinks. If you’re interested in helping us test, flip that preference in Firefox Nightly, and file bugs if you see it introducing strange behaviour.

Hopefully we’ll be able to flip it on by default soon. Stay tuned!

Translations

Thanks to generous volunteers on the web, this article has been translated to the following languages:

  1. Russian, by HTR Mobile

  1. Right now, we simply detect whether you’re hovering a tab with a mouse to predict that you’re likely going to choose that, but there are certain more opportunities to introduce warming based on other user behaviours. ↩

  2. We can even interrupt JavaScript to do this, thankfully! ↩

  3. I suspect WebRender will eventually help with the raw rendering performance, but that’s still a little ways off from being shipped to users. ↩