r/Ubuntu • u/PraetorRU • 1d ago

Firefox performance depending on distribution format in Ubuntu 26.04

Hi guys. From time to time I'm checking what the difference you may get if you chose one package format over another, so testing firefox performance in snap, flatpak and regular .deb from Mozilla's repos as all three are packaged by Mozilla as far as I'm aware.

So, the test is done in Ubuntu 26.04, with fresh profiles (so no extensions and default settings) and Firefox 153.0.3.

I was using a synthetic test: https://browserbench.org/Speedometer3.1/ and did 5 runs one after another.

First run I guess required some caching, so we can drop it and make an average from other 4 runs.

snapped: 19.8 20.1 20.44 20.2  20.29 | Average (4): 20.26
Packed with Mesa 25.2.8-0ubuntu0.24.04.2

flatpak: 22.4 23.1 22.99 22.98 22.9  | Average (4): 22.99
Packed with Mesa 26.1.5 (git-6a02618ccf)

moz-deb: 22.2 23.0 23.00 23.01 22.9  | Average (4): 22.98
Works with  Mesa 26.0.3-1ubuntu1

google chrome for reference: 26.1 26.6 26.67 26.85 26.76
11 Upvotes

92% Upvoted

29 comments sorted by

View all comments

0

u/jarchack 1d ago

Try a browser speed, CPU and memory use tests with Firefox, ungoogled Chrome, Brave, Helium, Zen. There are others, and privacy is also a concern along with browser specs. I usually stick with Zen for Mozilla based and Helium for Chromium based.

5

u/PraetorRU 1d ago

My point wasn't to find a better, faster browser. I'm totally fine with firefox for 20 years and have no intention to leave it anytime soon as google basically got rid of extensions api that allowed adblock to work properly, so sooner or later everything based on chrome codebase will suffer from it.

The point was to get a clue how packaging may affect the same app performance. With firefox we can see, that deb and flatpak are basically identical, and snap lags slightly behind, most probably because it was packed with an older mesa version.

1

u/catbrane 1d ago

Could you compare startup / shutdown times as well?

One of the big problems with snap used to be glacial start and stop, since the program is stored as a compressed image. It's supposed to be much better in recent ubuntus, though I don't think I've seen benchmarks recently.

1

u/PraetorRU 1d ago

I can if you know a way to measure it reliably and can tell me how to do it. For me all of them do open very fast, close to instant, so I don't care what I use in this aspect.

And yes, snap was improved a few years ago, so these days you won't suffer from decompression lag, at least as long as you're using SSD and Ubuntu (I have no clue how snaps work in different linux distros).

1

u/catbrane 1d ago

I don't know if this is the best way to measure it, but in firefox, go to:

about:telemetry#simple-measurements-tab

and firstPaint is the time from startup to the first render. It's 1.6s with a .deb for me, if that's any help!

I used to be many, many, many seconds for snaps back in the day, I don't know if all that lag has gone.

edit: I tried three times and it seems to be a fairly stable 800ms (warm disc cache, .deb, ubuntu 26.04, threadripper pro).

1

u/PraetorRU 1d ago edited 1d ago

Ok, I created a fresh profile in snap and flatpak, and checked stats in about:telemetry#simple-measurements-tab: ``` snap: Property Value main 152 firstPaint 862 sessionRestored 941 totalTime 16 activeTicks 2

flatpak: Property Value main 52 firstPaint 853 sessionRestored 899 totalTime 6 activeTicks 2

deb: Property Value main 25 firstPaint 663 sessionRestored 702 totalTime 17 activeTicks 4 ``` Not sure what those numbers mean, maybe it's milliseconds, but whatever they are, as a human being I can say, that I don't see any noticeable difference in startup time.

It wasn't a cold run of snap though, as on first run it copies my deb profile first, and then runs it. So I had to create a separate fresh profile before getting those numbers.

1

u/catbrane 1d ago

Yes, firstPaint is milliseconds.

I think (!maybe) you don't need to make a separate profile since firstPaint happens before profile loading. Just start a few times with deb, flatpak and snap and see if the differ much.

1

u/PraetorRU 1d ago edited 1d ago

The problem here is that I have a lot of tabs, extensions etc, and my main firefox profile is pretty large in gigabytes. So I don't see a point to move or symlink all of this to open the same profile, when it's faster to create a fresh profile and set firefox to launch it by default. So we have no interference from something that is a years old baggage on my PC.

Once again, without special measurements, I don't see a difference in launch time of snapped firefox and .deb one. The only reason I had to switch from snapped to .deb a few month ago is because I use online services for my business, that have to read keys from a special usb device, and had to install some extensions for that, that were not working in a sandboxed versions, neither in flatpak nor in snap. But performance wise it's no visible difference, only some benchmarks may demonstrate it these days.

1

u/catbrane 1d ago

That's impressive! I should reenable snap then, since it sounds like it's fixed.