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:
- Russian, by HTR Mobile
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. ↩
We can even interrupt JavaScript to do this, thankfully! ↩
I suspect WebRender will eventually help with the raw rendering performance, but that’s still a little ways off from being shipped to users. ↩