HOWTO Make Mozilla Firefox Blazing Fast On Linux
The Firefox web browser is, by default, much, much slower than it can be on Linux. There is, luckily, several ways to make it a whole lot faster by changing one or more configuration options that are not so easy to find or understand. Newly released Firefox 88 made it easier, though you can make older Firefox versions and Firefox LTS versions faster with some trickery. Here's the options you have and the performance they provide.
Mozilla Firefox 88 showing a image search for WJSN on the Naver search engine.
Mozilla Firefox has never been particularly fast out of the box on GNU/Linux, and that is specially true if you use graphics-intensive applications. It is possible, and easy, to make it faster by tweaking the rendering engine it uses. There are actually a lot of different compositing and rendering combinations you can use.
Just how much faster you can make Firefox will depend on what machine you have and, importantly, what kind of GPU it has.
The Compositing And Rendering Options And Their Performance
Mozilla Firefox 88 showing a image search for "very fast" on the Duck Duck Go search engine.
Modern Firefox versions have two compositing engines: Gecko and Webrender.
Gecko is the older of the two. It has been around for decades. Gecko can be used with or without OpenGL compositing, and OpenGL compositing can be used with our without EGL rendering. Firefox versions prior to Firefox 88 defaulted to Gecko with "Basic" compositing.
Webrender, written in Rust as part of the Servo project, is completely different. It was ported to Firefox as part of something called "Project Quantum" in 2016. Linux users can use it with our without EGL rendering. It is quite slow without EGL rendering, which is what you get by default, and quite fast if EGL is enabled. Webrender replaced "Gecko Basic" as the default compositor when Firefox 88 was released late April, 2021.
|Webrender||Webrender||Default compositing mechanism in Firefox 88+.
Slow by default, though it can be faster than the old default "Gecko Basic" compositor previous Firefox versions defaulted to - depending on what hardware you have.
|Webrender with EGL||Webrender||Webrender with EGL is the best performing combination. It makes Firefox quite fast, almost as fast as Chromium-based web browsers.
It is easy to enable on Firefox 88 and newer, but it is hard and cumbersome to enable EGL on Firefox versions prior to 88.
|Basic||Gecko||The default compositing mechanism up to and including Firefox 87.|
Really slow. It is specially noticeable how utterly slow it is compared to the other options if you have a computer with a dedicated graphics card.
|Basic w/EGL||Gecko||Really slow, barely measurably faster than plain "Basic" rendering. EGL doesn't make much of a difference with the "Basic" compositor.|
|OpenGL||Gecko||OpenGL compositing is faster "Basic" in the Unity WebGL test and slower in the Basemark Web 3.0 test on our test-system with a dedicated AMD GPU. It is slightly faster than "Basic" in the Basemark Web 3.0 test and slightly slower in the Unity WebGL a Intel-powered laptop test machine.
OpenGL has never been enabled by default on Linux, and very few Linux users are aware of it. Mozilla is phasing Gecko out in favor of Webrender, so it will likely be removed sometime in the near future.
|OpenGL w/EGL||Gecko||Pretty fast regardless of what benchmark you run and what machine you run it on. EGL makes a huge difference for the Gecko OpenGL renderer, OpenGL+EGL is almost as fast as Webrender and it makes Firefox near-competitive with Chromium-based browsers.|
Unity WebGL 2018
The Unity WebGL 2018 benchmark is a purely graphical benchmark. Graphical web applications using WebGL are the ones that are most affected by what compositor and output rendering mechanism Firefox uses, this is where it makes the biggest difference.
There is one clear take-away from the purely graphical Unity WebGL 2018 benchmark: Using EGL to render the compositors output makes a huge difference on very graphics-heavy websites and that difference increases with how powerful the GPU performance is relative to the CPU performance.
The Intel i7-5500U is a weak dual-core (even though the name says i7) Broadwell Intel chip with a pathetic graphics chip. The out-of-the-box Webrender configuration Firefox 88 ships with provides 72% of the performance you get with Webrender+EGL on that machine.
The AMD Ryzen 2600 powered desktop machine with a RX 470 gets 74% of the performance Webrender+EGL provides with the Firefox 88 stock configuration. Webrender with stock settings is a huge improvement over the "Gecko Basic" compositor previous Firefox versions defaulted on this particular box, the difference is "Gecko Basic" and Webrender without EGL is much lager than it is on the other machines.
The desktop machine with an older Athlon 5350 APU gets only 28.3% of the graphical performance Webrender+EGL provides out of the box. That's a pretty big difference. The hardware on that particular box may explain why: The Athlon 5350 APU is a 2.05 GHz quad-core processor with dismal per-clock performance. The GPU part isn't all that bad in comparison to the CPU so anything that shifts load from the CPU to the GPU helps a lot. Note that there is no such huge performance difference in the more realworld-like Basemark Web test, there is a difference there too but it is much, much smaller.
Basemark Web 3.0
Webrender with EGL wins on the Basemark Web 3.0 test on both the AMD systems tested, but it does not win on the Intel laptop where Webrender seems to be the worst option. Enabling EGL helps, but the good old Gecko compositor beats it regardless of how it is configured on that machine. That's worth considering if you have an older Intel desktop or laptop without a dedicated GPU.
WebXPRT 3 is a mostly CPU-bound test. The differences between Gecko and Webrender with and EGL enabled is very small in this test.
The Athlon 5350 APU numbers are all identical in the WebXPRT 3 benchmark regardless of what Firefox settings are used. The results vary a little on the other machines, but the variation is small on those as well.
HOWTO enable EGL Rendering
EGL rendering makes a huge difference as long as you do not use the "Basic" Gecko compositor. It makes both the Quantum/Servo Webrender compositor and the Gecko OpenGL compositor a lot faster as you probably noticed in the benchmark results above.
Enabling EGL is very easy in Firefox 88 because it has a new configuration key previous versions did not have:
about:config into the address bar, search for
x11-egl and set
gfx.x11-egl.force-enabled and that's it. You will have to restart Firefox to make that setting take effect. You can re-start it by typing
about:restartRequired into the address bar.
You can visit the special
about:support page by typing that into the address bar to see what compositing and rendering options are used. Firefox 88+ will show a
X11_EGL field that should say
force_enabled by user: Force enabled by pref if EGL is enabled.
Enabling EGL in versions prior to Firefox 88 has a lot more cumbersome. It can only be enabled in earlier versions by setting the special environment variable
1. You can do this by launching Firefox in a terminal with
MOZ_X11_EGL=1 firefox or change the freedesktop-standard
.desktop file desktop environments use to determine how Firefox should be launched from desktop environment menus.
You can copy
$HOME/.local/share/applications/firefox.desktop and replace
Exec=firefox %u with
Exec=env MOZ_X11_EGL=1 firefox %u to make the variable be set if you launch Firefox in a desktop environment.
Firefox versions prior to 88 do not have any
X11_EGL status listed on the special
about:support page. You can tell if Firefox is aware that
MOZ_X11_EGL is set by checking if it is listed under "Environment Variables". It is probably used if it is, but you may want to run the Unity WebGL 2018 benchmark before and after enabling it to ensure you see a difference.
HOWTO Enable Webrender Compositing
Webrender with EGL is the by far best compositing option in recent Mozilla Firefox versions. You do not have to do anything to enable Webrender in Firefox 88+, was made the default compositor in Firefox 88. It is slow without EGL rendering, so make sure you enable that using the steps described above.
Firefox versions prior to Firefox 88 need to have the special setting
gfx.webrender.all changed to
true in a special configuration page that can be accessed by typing
about:config in the web address bar (and a special environment variable
MOZ_X11_EGL set to
1 to enable EGL for it).
There's also configuration key in
gfx.webrender.enabled that can also be used to enable Webrender in Firefox versions prior to 88.
gfx.webrender.all will override it, you can ignore
gfx.webrender.enabled if you use that (Webrender is enabled if you have
gfx.webrender.all set to
gfx.webrender.enabled set to
HOWTO Enable "Basic" Rendering
Enabling "Basic" rendering is easy in Firefox versions prior to 88: It is the default so you don't have to lift a finger. You can go back to basic in Firefox 88 by setting the
gfx.webrender.force-disabled key to
about:config. We see no good reason why you or anyone would want to do that.
HOWTO Enable "OpenGL" Rendering
Enabling "OpenGL" is a simple matter of setting
true in Firefox versions up to 87. You will also have to set
true to turn Webrender off in Firefox 88+. You can, additionally, enable Off Main Thread Painting (OMTP) by setting
layers.omtp.enabled to true to, in theory, make the "OpenGL" option slightly faster. OMTP is only relevant if you use Gecko with OpenGL rendering, it has no effect on the Webrender renderer.
EGL output has a significant performance boosting impact on OpenGL compositing, which may sound odd since you'd think that OpenGL would use OpenGL and not whatever slow method it uses if EGL isn't enabled. Make sure you enable EGL by setting
about:config in Firefox 88+ or by setting environment variable
MOZ_X11_EGL=1 in Firefox <=87 if you want maximum performance from the Gecko OpenGL compositor. It is kind of slow without EGL.
HOWTO Enable Hardware Video Decoding
Mozilla Firefox 88.0 beta 7 with EGL force-enabled and VAAPI hardware video decoding enabled.
You can enable VAAPI hardware video decoding by setting
about:config if you use Webrender or OpenGL with EGL rendering. It will not unless EGL is enabled.
You can run Firefox in a terminal with
MOZ_LOG="PlatformDecoderModule:5" firefox to see if hardware accelerated video playback is working. It will show nothing until you start playing a video. Firefox will spew out a steady stream of information in your terminal once you start playing a video if you started it with
MOZ_LOG="PlatformDecoderModule:5". That stream will either mention VAAPI over and over or not mention it at all. Look for:
[Child 4068926: MediaPDecoder #3]: D/PlatformDecoderModule DMABufSurfaceWrapper: VAAPI releasing dmabuf surface UID = 6 [Child 4068926: MediaPDecoder #3]: D/PlatformDecoderModule DMABUF/VA-API Got one frame output with pts=966667dts=1000000 duration=33333 opaque=-9223372036854775808 [Child 4068926: MediaPDecoder #3]: D/PlatformDecoderModule DMABufSurfaceWrapper: VAAPI releasing dmabuf surface UID = 6
VAAPI hardware video decoding is enabled if you see those messages in the debug stream.
Firefox does not have to be as utterly slow as it is about of the box on Linux. You can and should enable the magic EGL switch for a swift 30%+ performance-boost. Just how much of a performance uplift you get will depend on your machine, the real-world performance gap between the out-of-the-box settings and what you get if you enable EGL rendering is a lot wider on machines with a dedicated GPU. And pure graphical performance is much, much faster with EGL if you have a weak CPU and a decent AMD APU (or GPU).
You may also be interested in reading HOWTO Make Mozilla Firefox Stop Nagging You About Updates And Other Annoying Idiocy since Mozilla seems hell-bent on making fewer and fewer of the settings available in
about:config do what they are supposed to do. Using Enterprise policies is a still-working way to get around that which is worth looking into if you use Mozilla Firefox as your daily driver.
You can get the latest Firefox build from Mozilla from https://www.mozilla.org/en-US/firefox/new/. You probably shouldn't if your distribution has a Firefox version in it's repositories, distributions tend to have a lot of telemetry spyware and annoyances like and the annoying constant nagging about minor updates disabled in the packages they provide.