What Is a Good Keyboard Latency?
There is no universal millisecond threshold, because "keyboard latency" has no fixed start and stop. A good result is a stable one, measured the same way, compared against your own baseline.
Published 15 August 2026 · Last updated 15 August 2026
Why the question has no single answer
Ask five sources what a good keyboard latency is and you will get five numbers that differ by an order of magnitude. They are not contradicting each other. They are measuring different intervals with different instruments and calling the result by the same name.
The same key press can honestly be described as taking a fraction of a millisecond, or several milliseconds, or several tens of milliseconds, depending on where the stopwatch starts and stops. The stage-by-stage breakdown of the input chain lays out the eight stages involved and shows how little the various definitions overlap.
Three things decide what a number means, and none of them is usually stated:
- Which segment was clocked. Switch closure to HID report is a different quantity from finger to visible pixel, and the second contains the first plus five more stages.
- What instrument produced it. A 240 fps camera cannot resolve better than about 4.2 ms per frame; a browser is limited by the clock resolution it exposes; a logic analyser is far finer but sees only the bus.
- Which statistic it is. A median over 60 samples and somebody's single luckiest press are both "the result", and they are not the same number.
Why we will not publish a good-versus-bad millisecond table
This is a deliberate refusal, not an omission. A table of hardware latency bands would be the most shareable thing on this site and the most misleading.
- We do not measure hardware latency here. This site measures the browser side of the chain. Any hardware band we printed would sit on the same page as a browser number, and readers would inevitably compare the two. Those quantities are not comparable.
- A band without a boundary is meaningless. "Under 5 ms is good" only becomes a claim once you say from what to what, measured how. Without that, it is a number wearing a lab coat.
- There is no public, reproducible distribution to draw bands from. Producing one would require instrumenting a large, representative sample of keyboards under a single documented protocol. Nobody has published that. Inventing plausible-looking cut-offs would be fabricating a dataset.
- Thresholds outlive their caveats. A table gets screenshotted, quoted and repeated long after the paragraph explaining its limits is gone. A confidently wrong threshold does far more damage than no threshold at all.
What we can do — and do below — is publish the bands we compute ourselves, define them precisely, and be explicit about what they describe.
A framework that actually works
1. Compare yourself to yourself
Absolute browser-side numbers do not travel between machines, but differences on one machine do. Take a baseline, change exactly one variable, then repeat under identical conditions: same browser, same power state, same background applications, same sample count. A consistent shift between those two runs is a real signal even though neither absolute value is portable.
The step-by-step testing procedure covers the setup, and the session comparison tool puts two saved runs beside each other so you can see whether the gap exceeds the spread.
2. Judge consistency before you judge the number
People notice variation far more readily than a steady offset. A system that is reliably a little slow fades into the background; a system that is usually fast and occasionally stalls feels broken. If you have to pick one statistic to care about, pick the spread.
A long tail is also the more actionable finding. A high median on a quiet machine is a property of the setup; a low median with occasional large excursions almost always means something is intermittently taking the main thread away from the page.
3. Put a few milliseconds next to a frame
Scale matters. At 60 Hz a display presents a new frame every 16.7 ms, so a two millisecond improvement anywhere upstream leaves a large share of presses landing in exactly the same frame they would have landed in anyway. At 144 Hz a frame is 6.9 ms and at 240 Hz it is 4.2 ms, so the same two milliseconds becomes a much bigger share of what is left. The value of a millisaved depends entirely on the granularity of everything after it.
4. Check whether you can tell the difference at all
Before spending money on a change, have someone set it up without telling you which configuration is active, and see whether you can identify it. This is unglamorous and it settles more arguments than any measurement does.
What this site's consistency bands mean
These bands we will publish, because we define them, compute them transparently, and they describe our own measurement rather than your hardware. The coefficient of variation (CV) is the standard deviation divided by the mean, expressed as a percentage — a scale-free measure of how spread out your samples were relative to their own average.
| Coefficient of variation | Label | How to read it |
|---|---|---|
| Under 15% | Very consistent | Samples cluster tightly. The median is a good description of nearly every press. |
| 15% to 30% | Consistent | Normal for a browser on an ordinary desktop with light background activity. |
| 30% to 50% | Moderate variation | Something is periodically competing for the main thread. Worth a quieter retest. |
| 50% or more | High variation | The median is not describing your experience well. Look at the tail, not the centre. |
These labels are always displayed next to the value that produced them, as Consistent (CV 22%), never as a label on its own. A word without its number is exactly the kind of shorthand that turns into a false threshold.
One caveat that matters: if your browser reports a timer resolution of 1 ms, every sample is quantised to whole milliseconds and the computed CV is partly an artefact of that quantisation. Check the measurement environment panel before reading much into a consistency band.
What the test quality bands mean
Quality describes how much you should trust the run, not how good the hardware is. It combines the number of valid samples, the proportion excluded, whether focus was lost, and the timer resolution available.
| Band | Conditions |
|---|---|
| Excellent | 30 or more valid samples, under 10% excluded, no focus losses, timer resolution better than 1 ms. |
| Good | 20 or more valid samples, under 20% excluded, at most one focus loss. |
| Limited | 10 or more valid samples. Treat the median as indicative only. |
| Insufficient | Fewer than 10 valid samples. Collect more before drawing any conclusion. |
A run marked Limited with a beautiful median is worth less than a run marked Excellent with an ugly one. Quality first, then spread, then the median.
When a result is worth investigating
These are patterns to look into, not diagnoses. A browser test cannot tell you what is wrong with a physical keyboard, and it should never be read as declaring one faulty.
- Your median has moved well above your own earlier baseline on the same machine and browser. Something changed on the system; start by repeating the run with less running.
- High variation with a heavy tail. Consistent with intermittent main-thread contention. Try a private window with no extensions, and check what runs in the background.
- A large number of excluded samples for lost focus or a hidden tab. That is a comment on your test conditions, not your hardware. Redo the run.
- Duplicate events arriving unusually close together. A pattern the chatter test is designed to surface. It reports possible chatter and shows you the timings; interpreting them is still your call.
- Keys that never register at all. Not a latency question. Use the keyboard tester to see which keys the browser receives.
What a good browser result does not prove
A low, tight browser-side median means the browser input pipeline and main thread were behaving well while you tested. It says nothing about switch actuation, debounce, matrix scanning, USB or Bluetooth transmission, or your display. A keyboard with a slow transport can produce an excellent browser number, and a fast keyboard on a busy machine can produce a poor one.
So what should you aim for?
Aim for a run you can trust and repeat: an Excellent quality band, a tight consistency label, a low exclusion count, and a median that does not drift when you test again an hour later. That is achievable on almost any modern machine, and it is the only "good" a browser measurement can honestly certify.
Then, if you are chasing perceived responsiveness rather than a number, spend your effort on the end of the chain with the most milliseconds in it. Refresh rate, frame pacing and application render behaviour usually hold more available improvement than the transport stage. The latency calculator lets you enter your own component estimates and see how a total distributes, and the browser-based latency test gives you the one segment you can genuinely measure at home.
Related tests and guides
Frequently asked questions
Why won't this site publish a good-versus-bad latency table?
Because a millisecond band is only meaningful once you fix where the measurement starts, where it stops and what instrument produced it. A browser measures a different segment of the chain than a camera or a bus capture does, so a single table would be applied to numbers it was never derived from. A confidently wrong threshold does more damage than no threshold.
Is my browser result comparable to a reviewer's hardware figure?
No. A reviewer's figure usually covers a hardware segment measured with instruments, while a browser result covers the browser input pipeline and main-thread scheduling. The two intervals barely overlap, so comparing them tells you nothing even when both numbers are accurate.
Should I care more about the median or the consistency?
Look at consistency first. People notice variation more readily than a steady offset, so a slightly higher median with a tight spread usually feels better than a lower median with a long tail. A long tail also points at something intermittently competing for the main thread, which is actionable.
How much difference does a few milliseconds actually make?
It depends entirely on what comes after it. A 60 Hz display presents a new frame every 16.7 ms, so a two millisecond improvement often lands many presses in exactly the same frame as before. At 240 Hz, where a frame is 4.2 ms, the same two milliseconds is a much larger share of the remaining budget.