Serious Discussion Chrome vs. Chromium: Differences in Benchmarks

[Sampei.Nihira]

@Miravi

Try measuring DOMContentLoaded on Fedora as well.

It’s not difficult: just open your browsers, go to a "New Tab, then open the browser’s developer tools (Network tab), open a website like "malwaretips.com", and check the time in seconds for DOMContentLoaded.
Close the browser and clear all cookies and cache..............etc......... if you want to repeat the measurement.

Spoiler: Chrome

Spoiler: Firefox

 

[Miravi]

I've been comparing the domContentLoaded and full page load measurements between browsers. Firefox's results are extremely impressive, which doesn't surprise me seeing how snappy it feels.

Firefox's Quantum architecture really excels on Linux, which is kind of its own turf. The core components redone in Rust (and C++ with parallel processing enhancement in Rust) absolutely breeze through reading the HTML and loading up the DOM tree. Despite its sophistication, Chromium does this kind of processing in a serial way—"one by one," so to speak. Firefox's multithreading within processes works tremendously well, which has many advantages over Chromium's need to generate multiple processes (for strict process isolation) and require them to communicate with each other. Chromium's design is much more expensive in this regard on Linux.

Efficient parallel processing aside, Firefox is overall way more native on Linux than Chromium. It uses the system’s own libraries, while Chromium insists on a custom graphics layer called Aura. Firefox's sandbox is also perfectly tailored to the native Linux sandbox design at this point, which means this critical feature is much lighter weight. Then it's worth mentioning how mature Firefox's memory management has become.

When you compare Firefox and Chromium side-by-side today, it's obvious that Firefox has grown into the image of ideal software for Linux. That says a lot considering the complexity of a modern browser.

 

[Miravi]

I'm happy to share that, as of the release of Fedora 44, the official (vanilla) Chromium builds are now optimized with PGO (Profile-Guided Optimization)!

Red Hat and the Fedora Project made some major upgrades to their build server infrastructure. In the past, compiling Chromium with PGO was one of the few tasks pushing the Koji build system to its absolute limits. In a major engineering milestone, they overhauled their process to be able to handle this three-stage intensive compilation.

Koji now handles these steps:

1. Instrumented Build: Compile a version of Chromium that records which code paths are used.
2. Training Run: Run that browser through a suite of benchmarks (the "profile" phase).
3. Final Optimized Build: Re-compile the entire browser using the recorded data to optimize the most-used functions.

Before the 2025-2026 upgrades, Koji lacked both the disk space and the ability to maintain the internal data and environment across these three distinct phases without timing out. This kind of Chromium build easily requires 200 GB of temporary disk space. A traditional build system (like Koji was) is stateless, so for every task, the system always uses a pristine environment to run a build and then destroys everything. That makes Chromium PGO impossible.

Red Hat engineers implemented Persistent Build Roots to handle these scenarios, so now the build daemon can:

1. Freeze the Environment: After the first pass, it pauses the environment instead of wiping it.
2. Mount the Profile Volume: It attaches a high-speed scratch space where the profile data is stored.
3. Hot-Reload: The compiler is restarted within that same environment, seeing the profile data as a local resource.

It's not totally on par with Google's proprietary PGO, but this is a major win for day-to-day performance. This new infrastructure should be used to boost performance for other software on Fedora Linux, too.

We should all appreciate the painstaking efforts behind good software.