JS CPU Benchmark
A browser speed score, with an honest account of what it does and does not measure.
How this benchmark works
A mixed workload of integer arithmetic, floating-point maths and string handling runs for four seconds, and the rate is converted to an index against a reference machine. Two details keep the number from being meaningless. The workload is deliberately awkward to optimise away and its accumulator is consumed at the end, because a modern JavaScript engine removes any loop whose result is never used — and a benchmark measuring dead-code elimination produces enormous figures that mean nothing. And the run yields to the browser between batches instead of blocking in one long loop, since a single blocking task measures how long the browser will let one task run before intervening, which is a different question. What comes out is this browser, executing this JavaScript, on this machine, right now: the engine, the tab's scheduling priority, the current thermal state and whatever else is running are all inside the number.
What the results mean
- Relative index
- The rate expressed against a reference machine, where 100 is that machine. It exists so the result has a readable scale. It is not an industry standard and means nothing away from this page.
- Operations per second
- The raw rate of completed work units. Useful for comparing two runs on the same machine, which is the only comparison this benchmark fully supports.
- Logical processors
- What the browser is willing to report about core count, which browsers round or cap for fingerprinting reasons. It is not a reading of the physical chip, and this benchmark uses one thread regardless.
- Checksum
- The final accumulator value, printed so the work cannot be optimised away. Without something consuming it, the engine would be free to skip the loop entirely.
Common problems and fixes
- The score is much lower than another machine you tried
- Compare the same browser on both, with nothing else running. Different browsers produce different numbers on identical hardware, and a background download or a video call is easily worth a third of the score.
- The score drops on repeated runs
- That is a thermal or power effect rather than randomness, and it is worth pursuing. The stress test is built for exactly that pattern and will show whether performance falls away and stays down.
- The result does not match the processor's advertised speed
- It never will. Advertised clock speeds describe a chip under ideal conditions, while this measures a JavaScript engine in a browser tab. There is no conversion between the two, and treating one as evidence about the other is the mistake this page exists to avoid.
- You want to know whether the processor is failing
- This cannot tell you. Processors rarely degrade gradually — they work or they crash. What does change is sustained performance under heat, which the stress test measures, and a native monitoring tool is the right instrument for anything below the browser.
Frequently asked questions
Why is my score different in another browser on the same computer?
Because you are measuring the browser as much as the machine. JavaScript engines differ in how they compile and optimise this kind of loop, and a thirty per cent gap between engines on identical hardware is ordinary. This is exactly why no comparison across browsers or devices is offered here.
Can I compare this against a native benchmark score?
No. Native benchmarks run compiled code with direct access to the hardware, while this runs inside a sandboxed tab under a scheduler that is free to deprioritise it. The two numbers are not on the same scale and no conversion exists.
What is this benchmark actually good for?
Comparing a machine against itself. Run it before and after a change — a browser update, a driver change, disabling an extension, closing background software — and the difference is real and attributable. That is a narrower claim than most benchmark pages make, and it is the one this can support.
Why does it not use all my cores?
Because a single-threaded number is easier to interpret and harder to get wrong. Multi-core scaling in a browser depends on how many workers the browser will let you run and how it schedules them, which measures browser policy more than hardware. The catalogue has a separate multi-core tool for that question, and it will carry its own caveats.
More in Device
- CPU Stress / Throttle TestWatch whether your machine slows down under a minute of sustained load — and stays down.
- WebGL GPU BenchmarkA graphics score that admits when the display, not the GPU, was the limit.
- Audio Dropout MonitorCatch the moments your audio thread starves — the cause of most crackles and gaps.