JavaScript Performance Test

This page runs a small, fixed set of JavaScript workloads and times them on your machine. It is not a general speed score and it does not compare you with anyone else. Its purpose is to show how quickly this browser executes five very different kinds of work, and how repeatable that result is when you run it again a minute later.

Everything is measured with performance.now(), which gives a high-resolution timestamp in milliseconds. For each workload the first pass is discarded as a warm-up, then five passes are timed. The bar chart shows throughput relative to the fastest workload in the run, and the row list gives the median, best and worst pass with the percentage spread between the extremes.

Each workload exercises a different pressure point, so a device that is strong in one may be ordinary in another.

• Integer maths. 1,500,000 iterations mixing numbers with Math.imul, xor and a right shift. This leans on raw arithmetic throughput and the optimising compiler.
• String building. 15,000 concatenations into one growing string. This stresses string allocation and the way the engine handles ropes or flat strings.
• Array sort. 150 sorts of a 1,000-number array using a comparator. This mixes comparison count with memory movement.
• JSON round-trip. 2,500 stringify and parse cycles on a small nested object, which is allocation-heavy and common in real code.
• DOM create and append. 1,500 elements built into an off-screen fragment. Nothing is attached to the page, so the layout is untouched, but node creation is still browser work.

Each workload reports operations per second, derived from its fixed iteration count, so you can compare two runs of this same page honestly.

A single timed pass would mostly measure the JavaScript engine warming up. Modern engines start by interpreting code, then compile hot functions to faster machine code once they have been called enough times. The first pass through a loop therefore runs in a slow tier, and it is thrown away.

The remaining passes are a compromise. Five is enough to see a median and some spread, and short enough that the whole run finishes in a few seconds. Between passes the code yields with a zero-delay timer so the page can repaint and show progress. You can run the benchmark as many times as you like; the numbers are not stored and each run replaces the last.

The headline figures are the median pass and the widest spread, which is the gap between the fastest and slowest pass as a percentage of the fastest. A spread in the low single digits means the run was steady. A spread of twenty or thirty per cent usually means something else was happening on the machine, or that a garbage collection pause landed inside one of the passes.

Because there is no baseline of other machines, the page never prints a score, a grade or a percentile. Any figure claiming to rank your device against the world would need real measurements from a large population, and this tool has none. Comparing the five passes against each other is the only comparison it can make honestly, and it is the one that actually tells you how much to trust the numbers above it.

Microbenchmarks are narrow by design. These five loops do not touch the GPU, the disk, the network or the audio stack, and they say nothing about how a large web application will behave, where scheduling, parsing and memory pressure dominate. A phone that wins here may still feel slower in a heavy editor.

A few practical notes. Laptop power settings and thermal throttling can change results mid-run, so a machine on battery may score lower than the same machine plugged in. Timers are also less precise than they look, and browsers coarsen performance.now() in some configurations for security. For the hardware behind the numbers, pair this with the device and hardware test and the graphics card test, and use the latency test when the question is the network rather than the CPU.