Keyboard Performance Test

What each of the five stages measures

The stages are deliberately different measurements, not five views of one number. Stage 1 times the gap between the browser creating a key event and this page's handler running — queueing plus main-thread scheduling. Stage 2 extends that to the next animation frame, folding in the wait for the browser's next rendering opportunity, so it is dominated by your refresh rate. Stage 3 checks that twelve specific physical keys reach the browser at all. Stage 4 looks for one key producing two keydown events within 15 ms. Stage 5 counts how many keys the browser reports as held at once.

Only stages 1 to 4 feed the score, because those are the four things the published weighting covers. Stage 5 is reported for context; adding it to the score would mean inventing a weight the specification does not define.

How the score is built, and why skipping matters

Each component produces a sub-score from 0 to 100 using the anchor table printed above. The sub-score is multiplied by its weight, the weighted values are added up, and the total is divided by the sum of the weights that actually contributed. Nothing is smoothed, capped or curved beyond what that table says.

Skipping removes weight rather than substituting a value. Skip the chatter stage and its 15 points leave both the numerator and the denominator, so the remaining 85 are re-normalised back to a 0–100 range. Scoring a skipped stage as zero would punish you for not running it; scoring it as full marks would flatter you for the same reason. The report instead names every stage that was skipped or never run, and states how many of the 100 weight points the number came from. The same rule applies when a stage runs but cannot produce a usable statistic: two samples are not enough for a coefficient of variation, so that component is excluded and labelled rather than guessed.

Why two computers cannot be compared

Browser input latency is mostly a story about scheduling. A busy main thread, a background tab decoding video, a power-saving CPU governor, a different OS input pipeline, or a browser that coarsens its clock for security will all move the numbers independently of the keyboard. Chrome clamps performance.now() to roughly 100 microseconds; Firefox clamps to 1 millisecond unless the page is cross-origin isolated. With a 1 ms clock every value is rounded to a whole millisecond before you see it, which mechanically inflates the measured coefficient of variation on fast systems.

That is why this page publishes no leaderboard, benchmark table or comparison against named keyboards. The honest use of the score is longitudinal: run it, change one thing — a different port, a different cable, wired instead of wireless, fewer tabs — and run it again on the same machine. The session comparison tool exists for exactly that, and why keyboard latency results vary between systems covers where the variation comes from.

Reading a low sub-score

A high median with a low coefficient of variation usually points at a steady, structural delay: a busy machine, a loaded browser, or an extension that installs its own key handlers ahead of the page. A low median with a high coefficient of variation points the other way — usually fast, but something intermittently blocks the main thread. Garbage-collection pauses, background downloads and screen-recording software all produce that signature.

A coverage miss in stage 3 has several possible explanations and the browser cannot distinguish between them: the key may not be registering, the operating system or a remapping utility may be intercepting it, or the browser may reserve it. A duplicate event in stage 4 is a possible chatter pattern that can equally come from a macro, an accessibility feature, or genuinely pressing one key twice very fast. Confirming either needs the dedicated chatter test or keyboard tester, ideally on a second computer.

Getting a result worth keeping

Keep the window focused and use your normal typing rhythm. Deliberately slow, evenly spaced presses produce a flattering consistency figure that does not describe how you actually type. Thirty valid samples is roughly where the median and percentile figures stop moving between runs; under ten, the quality indicator says Insufficient, and it means it. The guide on how to test keyboard latency walks through a good measurement run step by step.

Exclusions and test quality

Nothing is silently discarded. Every key event that fails a validation rule is counted, labelled with its reason and listed in the per-stage disclosure: key-repeat, window lost focus, tab not visible, synthetic event, unusable timestamp, clock anomaly, above the 250 ms cutoff, or a bare modifier key in the latency stage. A high exclusion ratio is itself information — usually that focus was moving around, or a key was held down.

The quality label combines four things: valid samples collected, the fraction of events excluded, how many times focus or tab visibility was lost, and whether the clock is fine-grained enough to resolve sub-millisecond differences. A profile labelled Excellent and one labelled Limited are not equally trustworthy, and the report says which you have.