Keyboard Latency vs Polling Rate

Polling rate describes how often the host computer asks your keyboard for its current state. Latency describes the total time between the switch closing and the result appearing. Polling is one term in that sum, and once you are at 1000 Hz it is a small term — about half a millisecond on average.

Here is the distinction in one table, then the arithmetic that supports it.

The arithmetic of a polling interval

The conversion is a single division:

interval (ms) = 1000 ÷ rate (Hz)

A key can be pressed at any moment, but it can only be reported at the next poll. If presses arrive at random relative to that fixed schedule, the average wait is half the interval and the worst case is the full interval. That "half the window on average" rule is the part people most often skip, and it halves every number below.

You can reproduce every row with the Hz-to-milliseconds polling rate calculator. None of it is a measurement — it is division, which is exactly why it is trustworthy.

Why 8000 Hz buys so much less than 1000 Hz did

Compare the two upgrades that people actually consider:

• 125 Hz to 1000 Hz removes 3.5 ms of average wait (4 ms down to 0.5 ms).
• 1000 Hz to 8000 Hz removes about 0.44 ms (0.5 ms down to roughly 0.06 ms).

Eight times the report rate delivers about one eighth of the improvement, because you cannot remove more time than the stage contained to begin with. Once a stage is down to half a millisecond, half a millisecond is the entire remaining prize.

Scale matters too. A 0.44 ms saving is about 2.6% of one frame on a 60 Hz display (16.7 ms per frame), and about 10% of a frame at 240 Hz (4.2 ms). Whether it is perceptible depends on whether everything else in the chain is already tight enough for a fraction of a millisecond to surface. Very high report rates also need a faster USB transport — high-speed USB divides each millisecond frame into eight 125 µs microframes, which is where the 8000 Hz figure comes from — and they can add measurable CPU interrupt overhead on some systems.

Scan rate: the term people forget

Before a keyboard can report anything, its own controller has to notice the key. Keys sit in a matrix of rows and columns; the controller energises each row in turn and reads which columns respond. One complete pass is a scan.

The same "half the window" arithmetic applies. If the matrix is scanned every S milliseconds, a press arriving at a random moment waits on average S/2 before the firmware even knows about it. A report handed to the host is only ever as fresh as the last scan.

On top of that sits debounce. Mechanical contacts bounce for a short time as they close, so firmware waits out a settling window before accepting a state change. Debounce windows are commonly in the low single-digit milliseconds, and the method varies: some firmware reports on the first edge and then ignores changes for the window, which costs almost nothing, while other firmware waits for the signal to be stable for the whole window, which costs the full window.

The consequence is blunt. A device polled at 8000 Hz but scanned every 2 ms with a conservative debounce can easily be slower than a 1000 Hz device with a fast scan. The polling number is printed on the box; the scan and debounce numbers rarely are.

Why a browser cannot measure your polling rate

This site is built in a browser, so it is worth being precise about what that rules out. There are four independent reasons, and each one alone is sufficient.

1. The browser is too far down the chain. A page receives keyboard events only after the operating system has processed and delivered them. A KeyboardEvent carries no field describing the USB transaction underneath it, because that information was discarded several layers earlier.
2. You cannot press keys fast enough to sample it. A very fast typist produces roughly 10–15 keystrokes per second, so events arrive 60–100 ms apart. Sampling a 1 ms process with 80 ms samples tells you nothing about the 1 ms process.
3. Holding a key does not help. Auto-repeat events are generated by the operating system from its own keyboard settings, not by the device. Held-key cadence reveals the OS key-repeat rate, which is typically a few dozen events per second at most.
4. The clock is too coarse. Browsers deliberately reduce timer precision as a security measure. Firefox clamps performance.now() to about 1 ms unless the page is cross-origin isolated, and Chrome clamps to around 100 µs. A 0.125 ms interval is below what the clock can even express.

That is why our cadence tool is careful about its own name: it reports browser-observed event cadence, not a USB polling rate. The longer version of this argument is in polling rate vs browser event cadence, and the general case is in why browser tests cannot measure hardware latency.

When polling rate genuinely matters

None of the above means polling rate is irrelevant. It matters in three situations:

• You are still at 125 Hz. That is a common default for office and general-purpose keyboards, and the move to 1000 Hz removes several milliseconds of average wait. This is the only polling upgrade that is large enough to stand out against everything else in the chain.
• You care about consistency, not just the average. A fixed polling schedule adds a wait that varies from zero to one full interval, press to press. A shorter interval narrows that band, which shows up as lower jitter rather than a lower median.
• Everything else is already fast. If your display and application are already tuned, sub-millisecond terms are the only ones left. That is a genuine reason to care — it is just the last step, not the first.

What to do instead of chasing Hz

Model the whole chain before optimising one link. The component-by-component latency calculator lets you put your own figures into every stage and see which one dominates; in most setups the display and the application, not the keyboard, hold the largest terms.

Then measure the part a web page can actually measure. The browser input latency test on the homepage reports the delay between the browser creating a keyboard event and your JavaScript handler running, with median, percentiles and jitter — see the methodology for the exact formulas and validation rules.