Web Browser Performance Round-Up April 2021
We benchmarked Brave, Chromium, Firefox, MS Edge, Midori, Naver, Otter, Opera and SeaMonkey to see which web browser provides the best performance on modern machines running GNU/Linux distributions. The numbers reveal that there is little difference since most modern browsers are merely Chromium-skins using the same rendering engine. Firefox and SeaMonkey are different, yet they are in the same performance-ballpark in everything except graphics-intensive applications. They are really bad in that particular area.
written by 권유리 (Kwon Yu-ri) 2021-04-04 - last edited 2021-04-06. © CC BY
The Web Browsers[edit]
Web browsers: NAVER whale, SeaMonkey, Mozilla Firefox and the Brave Web Browser.
The following tests are pure performance tests judging how the browsers perform in everyday tasks involving both light and heavy JavaScript use. Graphical WebGL performance is also tested. We make no judgement on their interfaces or features; this is just a performance-roundup.
Many of the browsers we tested are, beneath the hood, so similar that they are almost identical - and the numbers reflect that.
Mozilla Firefox and SeaMonkey both use the same Quantum rendering engine. SeaMonkey 2.53.7 uses an older version from Firefox 60.8, so they are not identical, but they are mostly identical beneath the hood.
Brave, Microsoft Edge, Opera and NAVER whale are all based on the Chromium rendering engine. The versions we have tested are all using different versions of it, and the browser vendors apply their own tweaks to it, so there are some minor differences between them. This is why these browsers performance so similarly; they are essentially the same beneath the hood. Opera and Edge used to have their own unique rendering engines, but that's no longer the case. They have both been reduced to being simple Chromium-skins.
The "next generation" Midori browser is written in TypeScript using the Electron framework. Electron is essentially a Chromium wrapper, so Midoris performance falls into the same general ballpark the Chromium-based browsers are in. Midori used to be a completely different browser based on WebKitGTK and there is a fair chance that you will get the old Midori, not the new and completely different "next generation" Midori, if you install it from your distributions repositories.
GNOME Web, Suckless Surf and the Otter Browser are, to some degree, different from the Chromium-based browsers. GNOME Web and Suckless Surf use WebKitGTK for their rendering. It, in turn, uses WebKit2, not the modern "Blink" rendering engine Chromium-based browsers use. Yet there are similarities, they do share the same KHTML roots.
The Otter Browser uses QtWebKit, which can easily be confused with QtWebEngine. QtWebKit is, like WebKitGTK, based on WebKit. The more modern QtWebEngine, on the other hand, is basically a Chromium wrapper for Qt.
We did not include Dooble, Vivaldi, Dissenter, Surf or Falkon. We tried to include Surf but it couldn't complete any of the benchmarks. Doogle is interesting, but there are no packages for it in any distribution so we chose to omit it.
Out-Of-The-Box Performance[edit]
To our Windows and macOS readers: All our tests were done on machines running free software GNU/Linux distributions. The numbers may or may not apply to your proprietary operating systems.
Mozilla Firefox has a lot of hidden settings you can play around with if you type about:config into the address bar, and Chromium-based browsers have a different set of hidden settings you can toy with if you "visit" chrome://gpu. Most people run their browser as-is, stock performance is what will matter to most people and that is what we have tested.
The following benchmarks are done with clean new web browser profiles. No settings are changed, no web browser history or cache exists, all the browsers have brand new "out of the box" configurations. Benchmarks with "tweaked" settings are further down below. We used "official" versions of SeaMonkey and Firefox since ther are some pretty huge differences between the official binaries provided by Mozilla and the SeaMonkey project and those shipped with distributions. The versions Fedora ships are, as an example, significantly slower than the official builds.
The Firefox 88.0b7 (as in beta 7) results are worth paying attention to if you are a Firefox user. Firefox 88 will have their shiny new "WebRender" rendering engine enabled by default.
Basemark Web 3.0[edit]
The Chromium-based browsers are in a class of their own in the Basemark Web test. Plain Chromium 88 is slightly faster than the Chromium-wrappers based on it, but the differences between the Chromium-based are overall tiny compared to the difference between them and Firefox and SeaMonkey. Firefox and SeaMonkey are both far behind the rest of the pack.
GNOME Web and Otter were unable to complete the Basemark web 3.0 test. Their lower scores are therefore not a true reflection their performance; their scores are based on the score in the test their completed and zero in the ones they failed. It is interesting to note that Otter scored higher than Firefox and SeaMonkey even though it scored zero in the WebGL parts of the benchmark due to its failure to even run those part.
WebXPRT 3[edit]
WebXPRT 3 is an interesting benchmark for two reasons: 1) It does not include any graphical elements of WebGL rendering, and 2) Mozilla Firefox and SeaMonkey race ahead of Chromium-based web browsers by a decent margin in this particular benchmark. This shows that Mozilla Firefox and SeaMonkey can provide good performance as long as there's no graphics-intensive rendering involved.
Unity WebGL 2018[edit]
The Otter Browser does not appear to have any WebGL support. It couldn't even run this test, so it scores zero.
The Unity WebGL 2018 benchmark is one where Mozilla Firefox stands out as being far behind everything else - including SeaMonkey. It is a bit odd that there is such a huge difference between Firefox 87 and SeaMonkey 2.53.7 since SeaMonkey 2.53.7 is based on the older Firefox 60.8 ESR code-base.
Conclusions[edit]
There's really just two main web browser categories left: Those that are based on Chromium, or an earlier branch of the Chromium codebase (WebKit, etc), and those that are based on Firefox (Firefox & SeaMonkey).
It does not seem to matter which of those you use if you look at the results from the Basemark Web 3.0 and WebXPRT 3 benchmarks. Firefox and SeaMonkey have a clear advantage in WebXPRT 3 and a disadvantage in Basemark Web 3.0.
There is one particular area where it really does matter which web browser you use: graphics-heavy applications. If you play WebGL games in your browser, or use applications relying on WebGL, then you should avoid Firefox (and SeaMonkey) like it's the plague. It isn't very hard to verify that the benchmark numbers here do reflect reality. cryptowat.ch is a website where you can look at charts of all the major digital currencies and see if you should waste electricity and CPU cycles mining a digital currency like Monero (XMR) with XMRig. The difference is immediately noticable if you opening two windows with Firefox and Chromium side-by-side and open cryptowat.ch XMR/USDT chart in both. Just moving the pointer around in the Firefox window feels sluggish; that's just not the case in Chromium-based web browsers.
What web browser you should use comes down to what interface and feature-set you prefer, and you should choose according to those criteria since performance is basically equal in everything not graphics-intensive. You can always keep a Chromium-based browser around just for those sites if you really like Mozilla Firefox for some reason.
"Tweaked" Performance[edit]
Most web browsers have some settings you can tweak to make them in theory faster. Firefox can be made faster on GNU/Linux by enabling OpenGL rendering. Chromium, on the other hand, doesn't show any practical benefit if you try to make it faster by enabling Vulkan GPU rendering.
Mozilla Firefox (And SeaMonkey)[edit]
Firefox has two rendering options beyond the stock "Basic" rendering: OpenGL and "Webrender". Webrender will be the default on GNU/Linux when Firefox 88 is released. It doesn't improve performance on GNU/Linux. OpenGL rendering, which can be enabled by setting layers.acceleration.force-enabled to true in about:config, can make a difference but it depends on what machine you have. The results are slightly better or slightly worse on our test machine with a Intel CPU using integrated Intel graphics and notably better on our test machine with a AMD CPU and a AMD GPU. You can type about:support into the address bar to see what you are using. will say if OpenGL rendering is enabled.
Both test systems show a slight improvement in the Baemark Web 3.0 benchmark when OpenGL rendering is used.
There is no difference between basic and OpenGL rendering in the WebXPRT 3 benchmark. This is likely due to a lack of WebGL graphics in this particular benchmark.
The effect of enabling layers.acceleration.force-enabled in Firefox and SeaMonkey is greatest in graphical applications like the Unity WebGL 2018 benchmark. There is zero difference in the WebXPRT 3 benchmark since it does not have any WebGL graphics or other graphics-intensive tests.
The Unity WebGL 2018 score is much higher on the AMD test machine when OpenGL rendering is used, but that is not the case on the Intel machine. You should run the Unity WebGL 2018 benchmark with and without setting to see what effect it has in your setup if you are considering enabling this setting. It will likely greatly improve performance if you have a machine with a AMD graphics card but it may not help, and even slightly degrade performance, if you don't.
Chromium w/Vulkan Rendering[edit]
Newer Chromium-based browsers are typically tweaked to take advantage of the GPU by default. You can verify if that is the case by typing chrome://gpu into the address bar. They do have one interesting new tweak: Vulkan rendering. We tried enabling Vulkan rendering on Chromium 84 a while back and it was a complete disaster. Chromium would gradually fill all GPU VRAM and then proceed to fill all system memory, and all available swap, before crashing. We are not entirely sure if that was due to leaks in Chromium or the Mesa graphics stack or the Linux kernel itself. Enabling Vulkan rendering seems to work fine with Chromium 88 using Mesa 21.0.1 and Linux kernel 5.11.11. It may work fine on your machine, but it could also end up filling all your machines memory resources. Keep an eye on your GPUs memory use with something like radeontop if you enable it. The memory leaks were severe, so you will quickly see if there are or aren't massive memory leaks when Vulkan is enabled on your machine.
Enabling Vulkan GPU rendering in Chromium results in a small performance boost on the Intel machine and a small penalty on the AMD machine.
Vulkan rendering seems to hurt pure WenGL performance on both test systems. The difference isn't huge, but it is there and a lower score is a lower score.
We do not recommend enabling Vulkan rendering in Chromium at this time. This is not just because there is no real performance-benefit, the actual risk of doing so is a greater concern. Enabling Vulkan rendering is not problematic if you are using Chromium 88+ with Mesa 21.0.x+ and Linux 5.11.x. However, we have seen it result in Chromium filling all GPU memory, all system memory and all swap until there is nothing left to fill in the past. Your distribution may have Mesa/kernel combinations that won't work well with Vulkan. You can enable it if you are sure gigantic memory leaks won't be an issue, but it would be kind of pointless since there is no real performance benefit. We will test and see if that changes when new Chromium versions become available.
Enable comment auto-refresher
Pandakekok9
Permalink |
Anonymous (b8e5977be8)
Permalink |
Anonymous (f652baa090)