Firefox Quantum, released last November, was a very important milestone for Firefox. Huge performance gains were achieved by replacing parts of the engine with bits of Servo, written in Rust.  But the technology shift did not stop at that: the developer tools –the inspector, the console, etc.– are being re-programmed using modern web technologies: JavaScript and React.

However, when the new developers tools were released with Firefox Quantum, some of you noticed that they were being slower and not as good as the old ones performance-wise. This was somewhat expected, as they were initial versions – and they have been getting better in the months following Quantum’s release.

The DevTools team has made performance a priority, they are working on it, and we –the web developers– can now start to reap some results.

What is faster now?

Improving the performance is a work in progress, and, as such, there have been some regressions, but some of the interactions that should feel faster and more responsive are:

• Viewing the CSS rules cascade in the Inspector, specially for big CSS files.
• Updating the  inspector when many DOM elements change at a time.
• Opening the Layout panel in the inspector (so you can debug your CSS Grid layouts!)
• Opening the Console with many logged messages.
• Expanding Objects with a lot of attributes in the Console.
• When updating the requests in the Network Monitor for a large page with hundreds of requests, the UI should feel much more responsive now.
• Stepping into a source-mapped file in the Debugger.
• Loading pages with hundreds of source maps or very large files in the Debugger.

Here are some short clips showcasing some of these.

The following video shows how long it takes for the CSS rules to be displayed in the sidebar of the Inspector, when dealing with a large stylesheet:

And this video shows how long it takes for the Console to load when a large amount of messages have been logged:

How do we know?

There is a public dashboard in which we can follow the evolution of the performance gains. It’s important to have in mind that sometimes we are speaking in the order of milliseconds, so shaving time off gets harder in some cases.

For instance, this is the evolution over the last three months of how long it takes for the Network Monitor panel to open:

While these charts and tests are useful in a day-to-day basis, they are not so good to have an overall, long term view. Why? You can see some  sharp changes in the chart above: this is because the tests used to measure performance are changing –or being replaced– over time as well. The reason this happens is because tests –as well as any other code base– need to be evolving to better reflect real examples or common scenarios. The hardware in which those tests are run is also changed from time to time, so that affects the measurements too.

But in order to do a fair, more scientific, comparison we would need a benchmark that uses the same tests. So that is what I did: run the tests of Firefox 60 (Nightly at the time) and compare them against the same Firefox 60 tests, but running on Firefox Quantum (57).

It wasn’t straightforward, because just copying the new tests over the old ones doesn’t work –for instance, some tests were relying on events that were not being dispatched on older versions. But luckily for me, Yulia Startsev, a DevTools engineer, not only helped me a lot, but she also created a patch for Firefox 57 so I could run the new tests on it.

After running the test suite –which, roughly, runs the tests multiple times and averages the time it took–, a JSON file is generated with the results. And with that, and a bit of JavaScript magic, we can compare the output  between Firefox 57 and 60.

And although it is satisfying seeing all the “green” in those tests, we have taken note of what needs to improve, including changes on the tests themselves to better reflect real use cases.

Remember that the new DevTools are being developed using web technologies (HTML, CSS, JavaScript and React), and you are more than welcome to collaborate. A good place to start is joining the Devtools Slack community, and taking a look at the list of open bugs tagged as “Good First Bug”. There is also the official documentation with a Getting Started section, along with another section dedicated to performance.