In an attempt to fill the shoes of Ehsan’s excellent Quantum Flow Newsletters¹, 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!

• Hiroyuki Ikezoe made it so that we use less CPU when out-of-view elements and visibility:hidden elements are animating in certain cases
• Mike Conley moved FormHistory database initialization and migration off of the main thread
• Bas Schouten made it so that we can get more detailed tracing information from Gecko when profiling using VTune (example, RefreshDriver ticks). This should help us debug performance issues on Windows.
• Ryan Hunt enabled experimental parallel painting for macOS. This will hopefully allow us to perform painting more quickly in the future.
• Florian Quèze made it so that we lazily instantiate the Search Service until the first search is started instead of when the first search input is focused, which should help reduce the potential for jank when the user begins inputting a search
• Gijs Kruitbosch reduced the size of the blocklist by ~50% by removing the deprecated blocked certificates list. This means less work for Firefox to do in parsing that list soon after start-up. He also made it so that only the blocked items that are relevant to the client application and platform are returned, which means even fewer things to process. This should impact most Firefox users across the board, as the change occurred server-side where the blocklist is produced.
• Marco Bonardo refactored PlacesDBUtils to not do main-thread IO when Telemetry data is gathered.

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

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.¹

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 layers² 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.³

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. ↩