Why the Same Device Scores Differently in Each Browser: How to Compare Chrome, Safari, Edge and Firefox

You ran the same benchmark on the same laptop, on the same power, a few minutes apart. Chrome scored higher than Safari, or the other way around. Before you blame the machine or the test, know that this is normal. A web benchmark does not measure bare hardware. It measures how well your hardware performs through a browser, and every browser sits between the code and the chip in a slightly different way. This guide explains why scores differ across Chrome, Safari, Edge and Firefox, and how to compare browsers fairly on one device with the Browser Battle feature in Web Bench.

A native benchmark can run close to the operating system and push hardware near its limits. A web benchmark can only reach the device through browser APIs such as JavaScript, WebAssembly, Canvas and WebGPU. On the way from the code to the CPU, the browser's engine, its graphics layer and its security policies all get a say. So the same hardware can produce different numbers depending on which browser opens the page, and that is expected rather than a bug.

That is not purely a drawback. Document editors, video calls, design tools and games have moved into the browser, so performance inside the browser is close to what you actually experience. "How fast is my device?" and "How well does my browser run on my device?" are different questions, and a web benchmark answers the second one.

This is why a score should always be read together with the browser that produced it. Web Bench shows a line such as "Quick test · 12 tests · WebGPU · Chrome 142" on each result, covering the test mode, the number of tests, the graphics path and the browser family with its major version. It reads only the family and the major version. The raw user agent string is never stored or sent anywhere.

Reason one: the JavaScript engine

Every browser ships a JavaScript engine. As is widely known, Chrome and Edge use V8, Safari uses JavaScriptCore, and Firefox uses SpiderMonkey. All three start by interpreting code lightly and then compile frequently used parts into faster machine code in stages, but each engine decides differently what to optimize, when, and how aggressively.

As a result, the winner can change with the kind of work. String handling, JSON parsing, sorting, numeric loops and code that creates lots of objects each expose different strengths. Garbage collection, the way memory is cleaned up, also differs, which can widen the gap in memory-heavy tasks. This is exactly why no browser is always the fastest. Engines change with every release, so a pattern you saw last year may not hold this year.

The operating system matters as well. On iPhone and iPad, browsers have long been built on the same WebKit-based engine as Safari, so tapping the Chrome icon on iOS does not give you the same engine as Chrome on a PC. Policies can vary by region and OS version, so rely on the browser name and engine details shown on your result card rather than on assumptions.

Reason two: WebGPU, WebGL and the graphics backend

GPU scores are where browser differences often show up most. Web Bench tries WebGPU first and, for graphics tests only, falls back to WebGL2 when WebGPU is unavailable. WebGPU support keeps changing with the browser, the operating system and the driver. If one browser ran through WebGPU and the other through WebGL2, the two scores should not sit on the same line as a ranking.

Browsers also sit on top of the operating system's graphics APIs, and the backend they pick can depend on the environment. Even with the same GPU, a different driver and backend changes how shaders are compiled and how fast they run. Compute tests need WebGPU, and the f16 matrix multiply only runs when the shader-f16 feature is supported. So two browsers on one GPU can end up running a different number of tests.

• Unsupported tests are treated as excluded, not as errors, and the result screen explains why.
• If the graphics paths differ (WebGPU versus WebGL2), treat the GPU scores as a rough guide only.
• If hardware acceleration is turned off, GPU scores can drop sharply, so check that setting first.
• If your browser supports WebGPU but it is switched off, look in its settings to see whether you can enable it.

Reason three: security policy, isolation and timers

To defend against CPU speculative execution attacks such as the Spectre family, browsers have limited precise timing and memory sharing. Two measures are widely known. One is deliberately lowering timer resolution. The other is allowing features like SharedArrayBuffer, where several Workers share memory, only on pages that are cross-origin isolated.

Implementations and defaults differ between browsers. A coarse timer makes short tasks harder to time accurately, which increases measurement noise. Without isolation, the way Workers coordinate in a multi-core test can change. This is also why Web Bench warns that its CPU multi-core result depends on the number of Workers the browser uses and how they synchronize, so you should not convert it directly into a physical core count.

For that reason, the environment comparison in Browser Battle includes cross-origin isolation and the synchronization method, the number of Workers used, and the smallest timer interval it measured, in microseconds. When two numbers differ, these rows help you tell whether one browser is really slower or whether the two simply measure time at different resolutions.

Extensions, tabs and power state

Just as common as engines and policies is how you use each browser. The browser you use every day probably has an ad blocker, a translator and a password manager installed, plus dozens of tabs open. The one you rarely touch is clean. If you compare them as they are, you are measuring the difference between extensions and tabs, not between engines.

• Extensions: ones that inject scripts into every page or use the CPU in the background lower scores and increase variance. A private window usually disables extensions by default, which makes it a useful baseline, although some features such as storage can be limited there.
• Open tabs and background work: video playback, downloads and syncing in other tabs share the CPU and memory with the test. Close them before you start, and do not hide the test tab while it runs. Hiding it discards the round in progress and measures it again when you return.
• Power and heat: a laptop's performance ceiling depends on whether it is plugged in and on its power mode. If the first browser left the machine hot, the second browser will score lower.
• Browser settings: hardware acceleration, efficiency or battery-saver modes and privacy settings can all change results.

How to use Browser Battle in Web Bench

Web Bench has a Browser Battle feature that compares two browsers side by side using only a share link, with no server involved. Here is the order to follow.

1. Finish a test in the first browser and create a share link. The share panel tells you that opening the link in another browser and running a test lets you compare them side by side.
2. Open that link in a different browser on the same device. The link carries the first result, so no account or server storage is needed.
3. On the shared result page, press the button to measure with this browser and compare. A banner such as "Comparing with: Chrome · ____ points" appears above the test screen, and the test mode is locked to match. Changing it triggers a warning.
4. When the test finishes, the Browser Battle card appears. It shows overall and category scores in two columns, the difference in percent, the winner of each category, and a one-line overall summary.
5. Scroll to the detailed comparison table for per-test values, and to the browser environment table for the engine, graphics path, isolation and timer details.

The two column titles show both the role and the browser, for example "Shared result · Chrome 155" and "This browser · Safari 18". If both browsers have the same name, they are labeled "This browser" and "Shared result" instead. You can share a battle result too, and that link carries the other result along with it. If the link would become too long, the per-test details are dropped, only category scores are kept, and you are told so.

Reading the result: margin of error before winner

The battle card shows which side is higher in each category, but the first thing to check is how big the gap is. Web Bench treats a difference within plus or minus 3 percent as "about the same". In that case the summary does not declare a winner, and the mascot shows a thoughtful face. A big laugh for a win and tears for a loss are reserved for gaps that are large enough not to flip on the next run.

The detailed table is stricter. Each test uses the median of three runs and records the spread between them, calculated as the maximum divided by the minimum, minus one. A difference that falls inside the combined spread of both browsers, with a floor of plus or minus 3 percent, is shown in gray as "no difference (within margin of error)". Metrics where lower is better, such as latency, are interpreted in the opposite direction. The summary sentence tallies the category winners, for instance noting which browser leads in JavaScript and data processing and which in graphics and storage, and it also tells you how many items fell within the margin of error.

Do not ignore the warnings either. If the cleaned-up device name (chip or GPU) or the core count differs, you will see a warning that the results may come from different devices and the comparison is not fair. If the official versions differ, you get guidance instead of a numeric comparison. In those cases, do not use the result to judge a browser.

Setting up a fair comparison

Comparing browsers means leaving exactly one variable: the browser. Everything else must match. This checklist makes your results far more trustworthy.

1. Test on the same device and the same operating system account. Check that the battle card does not warn about a different device name or core count.
2. Update both browsers to the latest stable release. A large version gap can change results through engine improvements alone.
3. Use the same test mode, such as quick or standard. Battle mode locks this for you.
4. Turn extensions off or use a private window, and treat both browsers the same way.
5. Close other apps and tabs, and pause downloads, video and cloud sync.
6. On a laptop, plug in the charger and keep the same power mode. After testing one browser, let the machine cool down before you start the next.
7. Run the pair again in reverse order if you can, since order can affect results.
8. Repeat each browser two or three times and look at the range.

Check the graphics path too. If one browser ran WebGPU and the other WebGL2, avoid comparing GPU items directly and explain the gap using the graphics path row in the environment table. If you included AI inference, both runs should use the same path, WebGPU or WASM, to count as the same conditions.

Choosing a browser for how you actually work

Once you have a result, ask which category matches your daily work before asking which browser won. The browser with the top score is not necessarily the best one for you.

• If you mostly edit documents, chat and shop online, single-core CPU and browser results matter most. If those gaps sit within the margin of error, choose on other grounds such as sync, extension support and privacy settings rather than speed.
• If you do heavy work such as web-based image or video editing or data processing, watch multi-core CPU, memory and storage results.
• If you use 3D maps, web games, effect-heavy sites or in-browser AI features, GPU graphics, GPU compute and WebGPU support matter most.
• If battery life is your priority, remember that power draw matters as much as scores. Web Bench does not show power efficiency directly, so check real-world battery time separately.
• If your school or workplace officially supports only one browser for a service you need, that browser comes first regardless of scores.

Finally, differences between browsers shift with updates. Rather than deciding today based on a result from months ago, run the battle again after a major browser update or when you change devices. Every score is a reference value that depends on the environment, and none of this should be used to conclude that one particular browser is always better.

Start a test in Web Bench

Note: this guide describes the current Web Bench features. Scores are reference values that vary by device, browser and conditions. Results are not sent to a server and travel inside the share link.