CPU Benchmark
Measure single-core and multi-core JavaScript performance right in your browser, using real Web Workers scaled to your processor's core count.
CPU benchmark suite
Seven real computational workloads plus a multi-core scaling test. Detected 4 logical cores.
—
Waiting
—
Waiting
—
Waiting
—
Waiting
—
Waiting
—
Waiting
—
Waiting
—
Waiting
Quick guide: how to use the CPU Benchmark
Takes under a minute- 1Plug in a laptop so power saving doesn't throttle the result.
- 2Click Run benchmark and leave the tab in the foreground.
- 3Each workload reports its own time and throughput.
- 4Use the overall score to compare machines, not as an absolute rating.
Overview
A CPU benchmark measures how quickly a processor can execute a defined set of instructions. This tool runs that idea entirely inside your browser using JavaScript, which means it measures the combination of your actual processor, your current power state, and how efficiently your browser's JavaScript engine compiles and runs code. That combination is exactly what determines how snappy your browser feels day to day, which makes it a more relevant number for most people than a synthetic native benchmark run in isolation.
The suite runs seven distinct single-threaded workloads one after another: a prime sieve, a 512x512 double-precision matrix multiply, a Mandelbrot fractal render, an 8-million-element array sort, SHA-256 hashing, LZ-style compression, and a 4-million-point FFT. Each reports its own wall-clock time plus a throughput figure in the unit that suits it, such as GFLOPS for matrix maths and MB/s for hashing. An eighth stage then spawns one Web Worker per logical core to measure real multi-core scaling, and the summary combines everything into a total time and an overall score.
Web Workers are a genuine browser feature for running JavaScript on separate threads, created here from an in-memory Blob URL rather than a separate file, so nothing is downloaded or installed. Each worker runs independently and reports its result back to the page, which then adds them together for the multi-core score.
How to read your results
The seven workload cards
Each card shows the time that workload took and a throughput figure in its natural unit: Mop/s for the prime sieve and Mandelbrot render, GFLOPS for the matrix multiply, Melem/s for the array sort, MB/s for SHA-256 and compression, and Gop/s for the FFT. Shorter times and higher rates are better. Compare these numbers to previous runs on the same machine rather than to another device's numbers directly, since JavaScript engine differences change the scale.
Multi-core scaling
The scaling card measures one Web Worker alone, then all of them at once, and reports the multiplier. A machine with 8 logical cores reaching 6x to 7x has healthy parallel headroom for tasks like video encoding or compiling code. A much lower multiplier suggests memory bandwidth limits, thermal throttling, or background load capping how much work your cores can actually do simultaneously.
Total time and overall score
Total time is the sum of the seven workloads, and the overall score normalizes each workload against a typical modern laptop, where roughly 300 points is mid-range. Above 500 is fast, and below 150 usually means throttled, older, or heavily loaded hardware.
What a low score means in practice
A single-core score well below what's typical for your CPU model, which you can look up online, often points to power-saving settings capping the clock speed, a thermal issue, or heavy background load rather than a hardware fault. Try plugging in a laptop, closing other applications, and running the test again before concluding anything about the hardware itself.
Troubleshooting
Score seems much lower than expected
Check whether your laptop is in a battery saver or "efficiency" power mode, since these modes commonly cap CPU frequency well below its rated maximum specifically to save power. Switching to "balanced" or "performance" power mode in your operating system's power settings before testing can make a large difference.
Multi-core test seems stuck or very slow
If your device has very limited memory, spawning many workers at once can cause the operating system to swap memory to disk, dramatically slowing everything down. Close other browser tabs and applications to free up memory, then run the test again.
Results vary a lot between runs
Some variance is expected due to background OS activity and thermal state, but swings larger than 20 to 30 percent usually mean something else, like a browser extension, antivirus scan, or automatic update, is competing for CPU time. Try running the test again after a minute of the system sitting idle.
Single-core versus multi-core: why both matter
Not all software can use multiple cores effectively. Tasks like loading a single web page, running most everyday applications, and many games are still dominated by single-core performance because much of the work happens in a sequential chain that can't easily be split up. Other tasks, like video rendering, code compilation, and running many browser tabs simultaneously, benefit enormously from additional cores.
This is why a CPU with fewer, faster cores can feel snappier for everyday browsing than one with many slower cores, even if the many-core chip wins decisively on a pure multi-core benchmark. When comparing two machines, look at both numbers together rather than picking whichever one favors the device you're considering.
Getting consistent, comparable results
- Plug laptops into power before testing, since battery mode throttles CPU speed on most systems.
- Close background tabs, especially ones playing video, syncing files, or running other web apps.
- Let the device sit idle for 20 to 30 seconds before starting, so any recent burst of activity settles down.
- Run the test two or three times and use the middle result rather than a single run.
- Test in the same browser each time if you're tracking changes over weeks or months.
Frequently asked questions
How accurate is a browser-based CPU benchmark?
It's accurate as a relative measure of JavaScript execution speed on your specific processor, browser, and current system load, but it isn't directly comparable to native benchmarks like Cinebench or Geekbench, which test raw instruction throughput without a JavaScript engine in between.
Why is my multi-core score not exactly equal to cores times single-core score?
Perfect linear scaling almost never happens because of memory bandwidth sharing, thermal throttling under sustained multi-core load, and operating system scheduling overhead. Seeing 60 to 90 percent of theoretical linear scaling is normal and healthy.
What does navigator.hardwareConcurrency actually report?
It reports the number of logical processors available to the browser, which includes hyperthreaded or simultaneous multithreading cores. A quad-core CPU with hyperthreading will typically report 8, even though there are only 4 physical cores doing the heavy lifting.
Why does the test use Web Workers instead of just running loops faster?
A single JavaScript thread can only use one CPU core at a time, no matter how the code is written. Web Workers spawn genuinely separate threads that the operating system can schedule onto different physical or logical cores, which is the only way to measure real multi-core throughput from inside a browser.
My laptop's score is lower than a much older desktop's. Why?
Laptops often run at a fraction of their rated clock speed to manage heat and battery life, especially under sustained load like this benchmark. A desktop CPU with better cooling can sustain higher clocks for longer, which shows up clearly in JavaScript benchmarks that run for close to a second per stage.
Does running other tabs or apps affect the score?
Yes, significantly. Background tabs, especially ones playing video or syncing files, compete for the same CPU cores. For a cleaner reading, close other tabs and let your system sit idle for a few seconds before running the benchmark.
What do the seven workloads measure?
Prime sieve tests memory-bound integer work, matrix multiply tests floating-point throughput, Mandelbrot tests tight arithmetic loops, array sort tests memory access and comparisons, SHA-256 tests bitwise and rotate-heavy code, LZ compression tests hashing plus branch-heavy matching, and FFT tests recursive butterfly maths on large arrays. Together they cover far more ground than any single loop.
Why does the benchmark take several seconds to complete?
Each sub-test needs to run long enough, generally under a second per stage, for JIT compilation warm-up effects to settle and for the measurement to be statistically meaningful. Very short bursts can be dominated by one-time compilation overhead rather than steady-state speed.
Can I use this to decide whether to upgrade my computer?
It's a reasonable data point but shouldn't be the only one. If your score is dramatically lower than a comparable modern CPU's published benchmarks, and your computer also feels slow during normal tasks, that's a good signal an upgrade would help. Pair this with the memory and storage tests for a fuller picture.
Why did my score change between two runs on the same computer?
JavaScript engines apply adaptive optimization, background processes vary run to run, and thermal state changes with usage, so a 5 to 15 percent variance between runs is completely normal. Consistent large swings usually indicate something else is consuming CPU in the background.
Does browser choice affect CPU benchmark results?
Yes. Different JavaScript engines, V8 in Chrome and Edge, SpiderMonkey in Firefox, and JavaScriptCore in Safari, optimize code differently. It's normal to see meaningfully different scores for the identical hardware depending on which browser you use.