Categories: Resource Use

Our Year in Review: How we’ve made Firefox Faster in 2020

This year was unlike anything any of us has experienced before. The global pandemic affected how we learn, connect with others, work, play, shop, and more. It affected directly or indirectly every aspect of how we live. Consequently, a universally open and accessible Internet became more important to our daily lives. For some Firefox users, access to the Internet is not just important, it is essential.

As the Firefox team adjusted to focus on features and improvements to help our users live a more Internet-based life, the performance program redoubled our efforts to deliver on the vision of “performance for every experience.” We hoped that by speeding up key parts of Firefox and Gecko like page load, JavaScript responsiveness, and startup, and by ensuring new features performed their best, that we could make the new normal a little less painful and a little more… well, normal.

With that in mind, we’d like to share the work that we’re most proud of this year and highlight how we make each version of Firefox faster than the last. Since we’ve accomplished a lot this year, we’ve broken the accomplishments into a few sections related to how we think about our work:

  • “Performance for every experience” details all the changes to Firefox itself.
  • “Culture of Performance” includes all the work to develop tests, metrics, processes, and the other pieces to ensure that performance is central to everything that Firefox builds.
  • Finally, “Browsing at the Speed of Right” covers the work to improve performance for the Web beyond the borders of the Mozilla ecosystem.

Performance for Every Experience

We believe that interactions with the browser and web pages should be quick and smooth. Pages load quickly. The web is responsive. And resources are used thoughtfully. This is the baseline performance we expect for all Mozilla products. In 2020, we improved all of these areas.

Page load

  • Firefox 75 included support for the lazy image loading standard. This feature can improve page load performance and reduce data by loading images when needed rather than on the critical path for the initial page load.
  • Firefox 80 added an optimization for Flexbox reflows. This improves page load performance by more than 20% in some cases and reduces layout shift during page load.
  • Firefox 82 features speculative JavaScript parsing that allows the browser to parse external JavaScript scripts as soon as they are fetched, even if never executed. This change generally improves page load by 3-4%, but for some sites can improve page load by more than 67%.
  • Firefox 83 introduces the new Warp feature in the SpiderMonkey JavaScript engine.
  • Firefox 84 adds support for link preloading, which gives developers more control over resource loading and can improve page load by more than 10 percent.
  • The new Firefox for Android that launched in August loads pages 20 percent faster than at the start of the year making it the fastest Firefox browser ever on Android.

Responsiveness

  • Firefox 72 included a change to how Firefox manages the addon blocklist which resulted in up to a 7 percent improvement to startup and session restore times.
  • Completed the first two of three planned phases for the Fast Shutdown project resulting in Firefox shutting down three times more quickly.
  • Firefox 85 Nightly for Windows includes a new skeleton UI for startup that means the first sign that Firefox is starting occurs in 10 percent of the time as before. This improvement to perceived performance of Firefox is especially helpful for users on slower machines. We hope to ship this new experience by default in early 2021.
  • Implemented a cache for the about:home page at startup that improved the time to when Top Sites render during startup by just over 20%.
  • Lazily loading parts of the Firefox UI when they’re needed, instead of automatically, results in browser windows opening more quickly. Between Firefox 77 and Firefox 80, the time to open new windows once Firefox decreased by about 10% on Windows.
  • Firefox 81 includes better playback quality for 60fps VP9 videos on macOS when WebRender is enabled.
  • WebRender also includes optimizations for shaders compilation that improved startup and session restore time by more than 10 percent.
  • The new Firefox for Android that launched in August opens links from other apps 25 percent faster. On some devices this means it is 60 percent faster than the old Firefox for Android.
  • General startup didn’t improve much when compared to the MVP that launched in June 2019. While holding ground isn’t normally a reason to celebrate, being able to do so while features were added to develop the browser from a MVP to the flagship Firefox browser on Android is a considerable accomplishment.
  • Firefox for Android also shipped with a number of improvements to the responsiveness of key parts of the user interface including accuracy and control for touch scrolling, reduced panning jitter, how quickly the keyboard is shown, text appears when typing, and menus respond to user input.

Resource Usage

  • Firefox 83 included WebRender support of macOS and further improvements to power use, especially when scrolling or watching videos. This work builds off improvements that were released in late 2019 and reduced Firefox power use on macOS by 300 percent.

Culture of Performance

We believe everyone contributing to Mozilla products owns a share of performance. In order for everyone to share ownership, the Performance Program must build a foundation of validated tests, tools, metrics, and other resources (e.g., dashboards, documentation) that empower everyone to understand and impact the performance of the browser. In 2020, we improved our test infrastructure and enhanced our performance tools to measure improvements and diagnose performance regressions.

Maintain Table Stakes Performance

  • Improved the performance dashboard https://arewefastyet.com by adding categories for memory, network, both cold and warm page loads, and live page loads. Also added results for WebRender and Fission variants.
  • Introduced and refined sheriffing efficiency metrics for measuring the time taken for sheriffs to triage and raise regression bugs. These metrics were the focus of the performance sheriffing newsletter in September.
  • Introduced dynamic test documentation with PerfDocs.
  • Introduced mach perftest notebook for analysing and sharing performance test results.
  • Added support for running performance tests in a batch mode over several builds in a single CI job, resulting in a more efficient use of machine time without compromising coverage.
  • Several improvements to Perfherder to include support for ingesting results from tests running in batch-mode, the ability to sort results in the compare view, and improved bug templates.

Measure What Matters

  • Introduced visual metrics for page load tests in the continuous integration (CI) pipelines for Android, Linux, and macOS, with Windows expected by the end of the year. This effort replaces our proprietary page load engine with the popular open source browsertime tool.
  • Completed the first version of a new visual completeness-based test for Firefox startup to provide a more user representative view of how quickly Firefox starts.
  • Introduced mach perftest, a modern framework for performance testing with the goal of simplifying running and writing tests. All new tests will use this framework, and the existing tests will be migrated to it over time. Several teams have already taken advantage of this new test framework, including QUIC and Fenix.
  • Enhanced mach perftest to support network throttling, and used this for our first user journey tests to compare http/2 and http/3.
  • Combined cold and warm page loads into a single CI job, reducing the total execution time whilst increasing the test coverage.

Help Feature Teams

  • Replaced the Gecko Profiler add-on with Firefox’s new Profiler toolbar, unifying recording flows for both desktop and remote mobile profiling  (and eventually for both Firefox engineers and web developers).
  • Setting up the Profiler got easier as well. As soon as the Profiler icon is in the toolbar, the start/capture shortcuts will just work. Enabling it via “Tools -> Web Developer – Enable Profiler Menu Button” is no longer needed.
  • The Profiler’s sidebar is handy to summarize the currently selected stack/leaf. We saw it delighted our users, so we made it more prominent by switching it default-on in the Call Tree.
  • Right-click on markers in the Profiler timeline now provides the same context menu as the marker table and graph; letting you select to/from timings and copy data.
  • The media team added the first custom preset to the Profiler, giving contributors quick access to recording media performance with all the necessary threads and settings.
  • In case of failed symbolication, the Profiler’s metadata dropdown now provides a handy button to re-trigger the process.
  • Dragging profile files to load them, which previously only worked on the homepage, now also works on a loaded profile
  • Profile storage backend migrated to an official Mozilla-owned storage space
  • The Firefox Profiler’s support for showing FileIO markers for main thread I/O has been extended to also show markers for off main thread I/O, and even for threads that are not being sampled.
  • The Firefox Profiler, used successfully by Firefox engineers to improve Firefox performance, has been made available for web developers. It replaces the legacy “Performance” devtools panel. Using the Firefox Profiler from Firefox devtools will show profiles with a new view focused on the current tab.
  • Markers 2.0 – Self-service profiler markers: in Gecko you tell how you want the marker to look, and it will appear in the Firefox Profiler front-end where you want it to, without needing to patch the front-end.
  • Added the ability to delete profiles to provide users with agency over stored profiles.

Learn From Our Users

  • Created a new dashboard to more easily identify performance-related user feedback from sources like Google Play Store reviews and support.mozilla.org forums.
  • Developed a proof of concept technique for observational analysis that correlates changes to performance metrics with user behavior metrics.
  • Ran experiments on desktop and mobile to inform ship decisions and guide performance optimizations related to startup, page load, link preloading, and Warp.
  • Started an audit and gap analysis of performance telemetry as part of a project to improve real user metrics.
  • Added new telemetry to better understand performance and user impact related to slow startups, long-running scripts and resulting browser hangs, mobile performance, page load performance when using link preloading, garbage collection and JavaScript execution time, and more fine-grained page load metrics.
  • Added annotations to the Background Hang Reporter to better understand hangs occurring in the Firefox UI and how they impact users.

Browsing at the Speed of Right

This means building the right performance for the web. There is no trade-off between performance (the “easy” choice) and purpose (the “right” choice). Mozilla is uniquely positioned to bring a balance between what is good for the users of the web and what is good for the builders of the web. This includes influencing web standards and finding ways to make the web faster for everyone (regardless of location, income, or even browser). Members of the performance program also actively participate in the W3C Web Performance Working Group.

This year, contributed to the discussions and feedback for Google’s Web Vitals proposal. This included in-house analysis of the Largest Contentful Paint (LCP) metric and how it compares to existing performance metrics—both visual metrics and standardized web performance APIs—that Mozilla uses internally to test performance on desktop and mobile. Our analysis found that while LCP is a promising improvement over some previous page load metrics, when the render time is not available, the value of the metric is significantly reduced. This work lays the groundwork for more complete implementations of Web Vitals in 2021, and closes the gap between measurement and performance analysis capabilities on desktop and mobile.

In 2020 we also made progress on the Firefox implementation of the PerformanceEventTiming API.

What’s Next

The end of 2020 isn’t the end of performance work for Firefox, but rather a milestone marking our progress. We still have a lot more that we want to accomplish.

For the next few months our focus will remain on improving the responsiveness of key areas of the browser like long-running scripts that cause hangs, intra-site navigation, and startup. We’re also laying the foundation for work later in 2021 related to how Firefox uses resources like CPU, battery, and network bandwidth. Work on improving page load will continue with some focus on performance cliffs that result in egregiously poor performance. Likewise, our work to develop the culture of performance across the Firefox org and influence performance of the broader web will continue as well.

We hope that our work in 2020 made the new normal a little less painful for you. Our goals for 2021 are ambitious, so we invite you to join us as we work to make normal, whatever it might look like, less and less painful. At least when it comes to browsing the web.


Have a question about performance? Find us on Matrix in the #perf room

Found a performance issue on Firefox? We’d love a bug report

No comments yet

Comments are closed, but trackbacks are open.