How accurate is a browser benchmark, really?

A browser benchmark measures relative behaviour reliably and absolute hardware capability poorly. It is good for comparing a machine against itself and directional for comparing machines.

• Browsers expose no API for temperature, power draw, fan speed, VRAM size, core clocks, or native FLOPS. No browser tool can report those values, and any that claims to is estimating from a device string.
• Timer resolution is deliberately coarsened in browsers to mitigate side-channel attacks, so microbenchmarks below roughly a millisecond are not trustworthy; SystemCheck works in sustained intervals for this reason.
• The same machine can differ by 10-20% across browsers because JIT behaviour, GPU backend, and driver paths differ. Cross-browser comparison is not a hardware comparison.
• What a browser measures genuinely well is behaviour over time on one machine: sustained throughput, decay under load, consistency, and the effect of a change you made.

The honest summary, first

A browser benchmark is a real measurement of a real workload, but the workload is JavaScript and WebGL2 or WebGPU running inside a sandbox, mediated by a JIT compiler, a browser compositor, an operating system scheduler, and a graphics driver. Every one of those layers is between the benchmark and the silicon, and every one of them adds variance the benchmark cannot see or subtract.

That makes it excellent at one thing and mediocre at another. It is excellent at measuring how a single machine behaves over time and how that behaviour changes when you change something, because all those intervening layers stay constant while your variable moves. It is mediocre at telling you the absolute capability of a piece of hardware, because the layers differ between machines by more than the hardware sometimes does.

If you want the shortest version: use a browser benchmark to answer "did my change help" and "is my machine slowing down under load". Use a native tool to answer "how fast is this chip".

What a browser cannot measure, at all

This is not a limitation of SystemCheck's implementation. These are capabilities the web platform does not expose to any page, by design, and mostly for good privacy and security reasons.

• Temperature: there is no thermal sensor API. Not for the CPU, not for the GPU, not for the battery in any useful form. Any browser tool showing you a temperature is fabricating it.
• Power draw and fan RPM: no API exists. Package power, board power, and fan speed are all invisible.
• VRAM capacity: WebGPU and WebGL2 report feature limits, not physical memory size. A page cannot tell an 8GB card from a 24GB card.
• Core clocks and boost frequency: unavailable. SystemCheck can observe that throughput fell; it cannot see that the clock dropped from 4.8 to 3.9 GHz.
• Native FLOPS: a browser measures JavaScript and shader throughput, which is a fraction of theoretical peak and varies with how well the JIT and shader compiler handled that particular code.
• Reliable hardware identification: navigator.hardwareConcurrency reports logical processors and can be capped or spoofed; the GPU renderer string is increasingly masked for fingerprinting reasons.

The precision problem

After Spectre and Meltdown, browsers deliberately reduced timer resolution to make timing side-channel attacks harder. performance.now() is quantised, and the quantum varies by browser and by whether the page is cross-origin isolated. In practice you cannot trust sub-millisecond timing from a web page, and you should not try.

The consequence for benchmark design is that microbenchmarks are out. You cannot reliably time a single operation, a single frame, or a tight loop. What you can do is run a workload long enough that the accumulated work dwarfs the timer's granularity and measure throughput across intervals, which is precisely why SystemCheck's stages run for tens of seconds each rather than sampling briefly.

This is a real constraint honestly acknowledged, and it also happens to point the design toward the more useful measurement. Sustained throughput is both what the platform can measure well and what actually predicts long workloads.

Sources of variance you cannot remove

Even on one machine, a browser benchmark carries noise from layers below it.

The JIT compiler has warm-up behaviour: the first iterations of a hot loop run interpreted or lightly optimised before tiering up. Deoptimisation can fire mid-run if the compiler's assumptions break. Different JavaScript engines (V8, SpiderMonkey, JavaScriptCore) make different choices, which is a large part of why the same machine scores differently across browsers.

The GPU path is worse. WebGL2 and WebGPU are different backends with different driver paths and different overhead; the same machine can differ by double-digit percentages depending on which one is used, and browsers pick differently across versions and platforms. Driver updates move results. So do compositor decisions, browser window size, display refresh rate, and whether the page is in a background tab.

The operating system contributes its own: scheduler placement across performance and efficiency cores, other processes, memory pressure, and power management state. SystemCheck reports consistency partly so that runs polluted by this kind of interference are visible rather than silently averaged in.

What it measures well, and why that is worth having

Hold the machine, the browser, and the conditions constant, and every one of the confounds above becomes a constant too. What remains varying is the thing you changed, or the thing the hardware did on its own. That is a legitimate and useful measurement.

Sustained throughput under a genuinely saturating multi-core load is measured directly and reliably. Decay across a sustained run is measured directly and reliably. Consistency of delivery is measured directly and reliably. The relative effect of cleaning a heatsink, changing a fan curve, applying an undervolt, or closing a background process is measured directly and reliably.

And it is available with no installation, no elevated privileges, and no trust decision about running an unfamiliar binary on your machine. For a large number of people that is the difference between measuring and guessing, and a directionally correct measurement beats a spec sheet.

When to stop and use a native tool

There is a clear boundary and it is worth stating rather than blurring.

• You need actual temperatures, power draw, or fan RPM. Use HWiNFO64, HWMonitor, or your vendor's utility (Ryzen Master, Intel XTU, MSI Afterburner, AMD Adrenalin).
• You need stability validation for an overclock or undervolt. Use Prime95, OCCT, or y-cruncher, which push the chip far harder than any browser can and are designed to surface errors.
• You need memory bandwidth or latency figures. Use AIDA64 or the Intel Memory Latency Checker.
• You need a comparable score for cross-machine ranking. Use a native benchmark with a controlled harness, and understand that it has its own conditions problem.
• You need per-game frame-time capture. Use CapFrameX, PresentMon, or the overlay built into your GPU vendor's software.

How to use a browser benchmark well

Compare like with like: same machine, same browser, same power source, same thermal starting point. Run three times and treat differences under about 3% as noise. Record your conditions alongside the number, because a result without conditions is not evidence.

Read the component figures rather than only the composite grade. Sustained throughput, decay, and consistency each tell you something the grade folds away. And pair the run with a native sensor tool when you are chasing a thermal problem, so you have both the behaviour and the physical cause in front of you.

Used that way a browser benchmark is a sharp instrument. Used as a replacement for a native suite, or as an authority on absolute hardware capability, it will mislead you, and it is better to say so on the page than to let you find out afterwards.

Questions

Can a browser benchmark read my CPU temperature?

No. There is no thermal sensor API on the web platform, in any browser, with any permission. SystemCheck infers thermal behaviour from throughput decay under sustained load and says so explicitly. Any browser tool that displays a temperature in degrees is estimating or fabricating it.

Why do I get different scores in Chrome and Firefox?

Different JavaScript engines make different JIT decisions, and the browsers may select different GPU backends and driver paths. Double-digit percentage differences on the same hardware are normal. Cross-browser comparison is not a hardware comparison. Hold the browser constant when comparing machines.

Is a browser benchmark accurate enough to be useful?

For relative measurement on one machine, yes. Sustained throughput, decay, and consistency are measured directly and repeat reliably under controlled conditions. For absolute hardware capability or cross-machine ranking, treat the result as directional and use a native benchmark when precision matters.

Why not just build a native app instead?

Native tools already exist and are better at absolute measurement, and SystemCheck points to them where they are the right answer. What a browser adds is that it requires no download, no elevated privileges, and no trust decision about running an unfamiliar binary, which for many people is the difference between measuring and guessing.