Keyboard Latency vs Reaction Time

This is the cleanest distinction on the site. Keyboard latency is time spent by equipment between a key closing and a result appearing. Reaction time is time spent by a person between noticing a signal and starting to move. One is engineering, the other is physiology, and the second is roughly a hundred times larger than the first.

What a reaction time test actually times

A reaction test records the moment it decides to show a signal, then the moment your keypress arrives. Everything in between is inside the measurement:

1. The browser renders the change and waits for the next frame — up to 16.7 ms on a 60 Hz display, 6.9 ms at 144 Hz, 4.2 ms at 240 Hz.
2. The display processes and lights the pixels.
3. Your eye and brain detect and recognise the change.
4. You decide to act, and a motor command reaches your finger.
5. The key travels far enough to actuate.
6. The keyboard, transport, operating system and browser deliver the event.

Steps 3 and 4 are the overwhelming majority of that total. The whole of the keyboard's contribution — steps 5 and 6 — is a small slice at the end, and the display's contribution at step 1 is often larger than the keyboard's. That is why the reaction test on this site is filed separately from the latency tools and labelled as a human measurement.

The arithmetic that buries the signal

Here is the concrete reason a reaction test cannot rank keyboards. Suppose two keyboards genuinely differ by 2 ms, and your own reaction times vary from trial to trial with a standard deviation of 30 ms — a plausible figure for an alert adult on a simple visual task, though it varies by person and condition.

Averaging helps, but slowly. The uncertainty in a mean shrinks with the square root of the number of trials, so ten times more trials buys about three times less noise. To separate two means that differ by δ when each has spread σ, the usual sample-size estimate is:

n per keyboard ≈ 2σ² × 7.85 ÷ δ²

The 7.85 is the standard factor for a conventional 5% significance level with 80% power — in plain terms, a test likely to find the difference if it is really there. With σ = 30 ms:

So a five-trial comparison — which is what most people actually do — can resolve differences of well over a hundred milliseconds and nothing smaller. Keyboards do not differ by that much.

And the sample size is the easy problem. The hard one is that you cannot hold yourself constant for six hours. Alertness drifts across a session by far more than 2 ms, and any drift between your keyboard-A block and your keyboard-B block lands in the result as though it were a hardware difference. No amount of extra trials fixes a confound; it only makes the wrong answer more precise.

Two clocks, two purposes

Both measurements are worth having. They just answer different questions.

• Reaction time answers "how am I doing today?" Because the same equipment sits on both sides of the comparison, changes in your score are mostly about you — sleep, fatigue, warm-up, time of day, familiarity with the task. That is a real and useful signal, and it is what the test is designed to show.
• Latency answers "how much delay is the system adding?" It is measured without a human in the loop, so it does not inherit human variance. Its remaining variation comes from scheduling, background load and display timing, which are things you can investigate and sometimes fix.

A reaction test also catches gross faults that a small-sample comparison can still see: if one setup is 80 ms slower, that is visible in a handful of trials, and it points at something badly wrong — a wireless link with aggressive power saving, a heavily loaded machine, or a display in a high-processing picture mode.

How to compare two keyboards properly

Take the human out of the timing path. The rigorous version is hardware: trigger the switch electrically, watch the screen with a photodiode, and time the two events with an instrument that is not the computer under test. That is how reviewers produce input-to-photon figures, and it is out of reach of any web page — for the full argument, see why browser tests cannot measure hardware latency.

The version you can do here is narrower but honest. Run the browser input latency test on each setup, collect enough samples for the quality indicator to read Good or better, then load both runs into the session comparison tool and look at medians, percentiles and jitter rather than single values. Interpret the result as a comparison of two whole browser-side setups on the day you tested them, not as a hardware verdict — the reasons results shift between systems are collected in why latency results vary.

Where the two numbers do meet

They add. If your reaction to a signal takes 250 ms and the equipment adds 20 ms of its own on the way in and out, then roughly 270 ms passes between the event happening and your action registering. Removing 2 ms of that is a genuine improvement of about 0.7% — worth taking if it is free, and not worth mistaking for the difference between a good and a bad day of sleep.

If you want the anatomy of the equipment side, what keyboard latency actually is walks the chain stage by stage, and the methodology page sets out exactly which segment of it this site can and cannot see.