Skip to content

CPU Benchmark

Benchmark your processor with a real mixed workload — integer, floating point and memory access — on one thread and then on every core at once.

CPU Benchmark

Live

Runs a mixed integer, floating point and memory workload — first on one thread, then on every core at once.

Readings

Single core
0M ops/s
All cores
0M ops/s
Logical cores
0
Scaling
0

Test something else

How to use this test

  1. Close other applications. Background load is the single biggest source of inconsistent results. A browser with thirty tabs will score meaningfully lower.
  2. Run the benchmark. Single-core runs five passes and takes the median; the multi-core stage then saturates every logical core simultaneously.
  3. Compare single against multi. The ratio between them is often more revealing than either number alone.
  4. Re-run after changing something. Power plan, mains versus battery, background apps — this test is at its most useful as a before-and-after measurement.

What this benchmark actually does

It runs a workload that deliberately mixes three kinds of work: integer arithmetic via a xorshift generator, floating-point maths, and strided access into a buffer. That mixture is intentional.

A benchmark that loops one simple operation mostly measures how well the JavaScript engine optimises that specific loop, which tells you about the browser rather than the processor. Mixing operation types and adding non-sequential memory access defeats the easiest optimisations and produces a figure that tracks real processor capability more closely.

The single-core stage runs five separate passes and takes the median, discarding outliers caused by a background task briefly stealing time. The multi-core stage then launches one Web Worker per logical core and runs them concurrently, which is the only way to genuinely saturate a modern processor from a browser.

What this number is and is not. It measures performance as seen from JavaScript in this browser, on this machine, in its current power and thermal state. It is directly comparable between two runs on the same machine — which is what makes it useful for answering "did that change help?" — and only loosely comparable against a different machine or a native benchmark. We would rather say that than publish a score implying more precision than it has.

Reading the scaling figure

This is the part most benchmarks omit, and it is often more informative than the raw score.

Scaling is multi-core throughput divided by single-core throughput. Perfect scaling would equal your thread count, and no real machine achieves that. Here is why:

  • Clocks drop under all-core load. A processor that boosts one core to 5.2 GHz may sustain only 4.4 GHz across all of them, because power and thermal budgets are shared.
  • Hyper-threading is not two cores. Two logical threads on one physical core share execution units. The second thread typically adds 20 to 30 percent, not 100.
  • Memory bandwidth is finite. Every core competing for the same memory bus eventually hits a ceiling that more cores cannot raise.
ThreadsHealthy scalingWell below that suggests
42.5 – 3.5×Background load
84 – 6×Throttling or a power cap
167 – 11×Thermal limits or memory bandwidth

Why your machine might be slower than it should be

In rough order of how often it turns out to be the answer:

  1. Running on battery. Laptops cap sustained performance aggressively on battery. Plug in and re-run — the difference is frequently the entire explanation.
  2. Power plan. Windows balanced mode limits sustained boost. High performance mode changes the figure measurably.
  3. Background software. Sync clients, updaters, browser tabs and antivirus scans all take real time from the benchmark.
  4. Thermal throttling. Dust in fans and degraded thermal paste both reduce sustained clocks. If your single-core score is fine but multi-core scaling is poor, this is the most likely cause.
  5. The processor is simply older. Per-core performance has improved substantially over the last several generations, and no setting recovers that.

Related tests

The GPU benchmark detects thermal throttling directly by comparing early frames against late ones, which is a good cross-check if you suspect heat. The memory test measures bandwidth and latency, and system information explains what your browser can and cannot detect.

Frequently asked questions

Why can this not just show my CPU usage like Task Manager?

Because no browser exposes processor load — there is no API for it, deliberately, since it would be a fingerprinting and side-channel risk. What a browser can do is run real work and time it, which answers a more useful question anyway: not what your CPU is doing right now, but how fast it does things.

Why is my score lower than a native benchmark?

Because you are measuring JavaScript execution, which carries browser overhead that native code does not. That does not make the number meaningless — it makes it a measure of this machine in this browser, which is exactly what matters if you are comparing configurations on the same computer. Do not compare it against Cinebench or Geekbench figures; they measure something different.

What does the scaling number mean?

It is multi-core throughput divided by single-core throughput. On a healthy eight-thread machine you would expect roughly 4 to 6 times, not 8, because hyper-threaded logical cores share physical resources and clocks drop under all-core load. A ratio far below that usually means thermal throttling, a restrictive power plan, or other software competing for the cores.

Why is my laptop so much slower on battery?

Because it is designed to be. Battery power profiles reduce sustained clock speeds substantially — commonly by 30 to 50 percent, and sometimes far more. Running this test on battery and then on mains is one of the most informative comparisons available, and it explains a great deal of "my laptop feels slow sometimes".

My score varies between runs. Is that normal?

Some variation is expected. Larger swings usually mean background activity — an update downloading, a sync client, a browser tab doing work. The single-core stage runs five passes and takes the median specifically to reduce this, but nothing can compensate for a machine that is genuinely busy. Close things and re-run.

Does having more cores always make this faster?

For the multi-core figure, more cores help, but not linearly. Clocks drop as more cores become active, thermal limits bite sooner, and hyper-threaded pairs share execution units. For the single-core figure, core count is irrelevant — that number reflects per-core speed, which is what most everyday software actually depends on.