Firefox snap performance Part 3: significant startup improvements

Welcome to the latest update in our Firefox snap performance series. This week, we cover two significant performance improvements that have just landed for all users.

First, let’s recap our mission:

The Firefox snap offers a number of benefits to daily users of Ubuntu, as well as a range of other Linux distributions. It improves security, delivers cross-release compatibility and shortens the time for improvements from Mozilla to get into the hands of end-users.

Currently, this approach has trade-offs when it comes to performance, most notably in Firefox’s first launch after a system reboot. This series tracks our progress in improving startup times to ensure we are delivering the best user experience possible.

Along the way, we’ll also be addressing specific use-case issues that have been identified with the help of the community.

You can catch up on the story so far in Part 1 and Part 2 of this series.

Where are we at?

Since the last update, we have made significant progress in Firefox startup performance. Our latest improvements look to deliver an average 50% reduction in start time after a fresh install compared to Firefox 101, consistent across a range of distributions and platforms.

These fixes are now available in the latest stable version of Firefox. Simply run the snap refresh command to ensure all your snaps are up to date.

What has changed?

There have been two major improvements since the last update. The first is a change from Mozilla regarding how Firefox handles language packs. The second is an update to the GNOME and GTK theme snaps that Firefox depends on.

Extension handling – language packs

Previously, Firefox copied all language packs on first start, a large and unnecessary overhead since most people run Firefox with only one user interface language, e.g.: English or French. 

Mozilla’s latest fix means that Firefox now only loads one locale at a time, based on the system setting.

This primarily affects the very first launch of Firefox after a fresh install and significantly reduces the initial setup time. Our testing shows an average reduction of about 6 seconds on modern systems with fast storage.

GNOME and GTK theme snap compression

Prior to the start of this series, we had already improved Firefox startup performance by using LZO compression for the Firefox snap.

What we hadn’t initially considered was that the Firefox snap depends on both the gnome-3-38-2004 and gtk-common-theme snaps, which were still being delivered compressed using the XZ algorithm. Since the Firefox snap loads libraries from these two snaps during launch, the decompression process can potentially create a bottleneck.

Switching the compression algorithm for these two snaps to LZO delivers (our second) significant improvement in the Firefox start-up times.

An additional benefit is that this change doesn’t just affect Firefox, but also affects the start times of all snaps that depend on the GNOME and GTK snaps, including Chromium and Thunderbird!

The results are consistent across different distributions, including other flavours of Ubuntu, Fedora 36 and openSUSE Leap 15.4 as we will demonstrate in the next section.

New benchmarks

Test machine: AMD Ryzen 5, 8GB RAM, Vega 8 graphics, NVMe PCIe 256GB drive

When running on Kubuntu 22.04, with the gnome-3-38-2004 and gtk-common-themes snaps compressed with the XZ algorithm, the cold launch times for the Firefox browser averaged about 15 s. With the LZO algorithm, the cold start has gone down to about 6 s. This is roughly a 60% improvement. Similarly, on openSUSE, the startup time has gone down from 13 s to 4 s, a 70% improvement.

The results are consistent for Thunderbird as well as the Chromium snap, where the startup time has improved from 12 s and 9 s to 7 s and 5 s, respectively. This represents improvements of roughly 42% and 29%.

On Fedora 36, the results are extra interesting, because Fedora uses a different kernel configuration for the Squashfs filesystem management (including decompression). On the sample system above, Firefox times were roughly 5 s. With the use of the LZO algorithm, the cold start time for Firefox, Thunderbird and Chromium are now 3 s, 4 s, and 2 s, comparable to the native ~2 s launch time for these applications.

Test machine: Raspberry Pi 400 with SD card

The Raspberry Pi represents our toughest test-case. Here, we’ve seen timings on a fresh install going down from 36 s to 17 s when using LZO and the language pack fix. Again, this is a respectable 50% reduction in start time. 

Looking ahead to Part 4

Whilst we’ve made significant progress in the last few weeks, we are by no means done when it comes to improving and optimising the snap startup performance. We have three ongoing avenues of investigation that will be the focus of our next push:

Multi-threaded CPU decompression

Currently, on Ubuntu-based distributions, Squashfs decompression is single-threaded regardless of the algorithm used. We are experimenting with multi-threaded CPU decompression with some promising early results.

Check out our tracking bug for more information.

Software Rendering

The Raspberry Pi has an outstanding issue where Firefox fails to detect the GPU (or fails to utilise hardware acceleration). As a result it falls back to software rendering which significantly impacts performance. This issue appears to be Firefox specific and occurs for both the deb and the snap.

This issue is currently with Mozilla and we will continue to work with them on identifying a fix.

Pre-caching

Pre-caching typically refers to the process by which software anticipates future user actions and preemptively downloads, installs, or unpacks the necessary files so that they’re ready to go as soon as they are called upon. It can also refer to the process of loading application data and libraries into memory ahead of their actual use by the application.

This is a widely used technique across various types of software; websites will pre-cache linked or related pages to the one the user is currently visiting, video games pre-cache shaders to prevent performance hitches during gameplay and, most relevantly, your operating system, as part of its design and normal operation, pre-caches system and desktop environment libraries during the boot sequence.

As a result, pre-caching means that software is more responsive whilst the user is interacting with it as the system needs less time to discover and load the necessary assets, but it comes at the expense of a longer (one-time) setup since it effectively front-loads the processing work.

The GNOME content snap, which is widely used by a range of applications, should be a good candidate for pre-caching since it would provide startup benefits to all desktop snaps that depend on it. We are currently experimenting with this possibility to look at the performance trade-offs of such an approach.

Share your benchmarks with us

We’d like to ask you to share your updated benchmarks with us so that we can validate these fixes in the wild across a broader spectrum of hardware and releases and establish a new baseline for continued improvement.

The easiest way to record your startup time is to use the GNOME extension, Applications Startup Time Measure and noting down times for the following three scenarios:

• Startup time after a completely fresh install of Firefox
• Startup time launching Firefox after a system reboot
• Startup time on subsequent Firefox launches

The best way to report them is by submitting your timings on the ‘Known issues with Firefox snap?’ Discourse topic with details of the release you’re running and the hardware specifications of your machine.

Thank you for your continued engagement with our journey!

We’ll be back with another update soon.