Polling Rate vs Browser Event Cadence

Published 15 August 2026 · Last updated 15 August 2026

Measuring the time between two keyboard events in a browser does not reveal your keyboard's polling rate. The two numbers describe different systems: polling rate is a property of the link between the keyboard and the host, while event cadence is a property of how the browser scheduled and delivered events to your page. They are separated by an operating system, a browser process boundary, a task queue and a deliberately blunted clock.

This matters because "polling rate test" is what people search for, and several sites are happy to print a number in hertz next to it. The number is not wrong so much as it is about something else. Here is the distinction, with the arithmetic.

What polling rate actually is

On USB, the host asks the device for a report at a fixed interval; the device does not transmit whenever it likes. The polling rate is how many times per second the host asks, and the polling interval is the reciprocal:

interval_ms = 1000 / rate_hz

A key press that happens at a random moment between two polls waits, on average, half an interval before it can be reported, and a full interval in the worst case.

The polling rate calculator does this conversion in both directions. Note how quickly the gains shrink: moving from 125 Hz to 1000 Hz removes about 3.5 ms of average wait, while moving from 1000 Hz to 8000 Hz removes about 0.44 ms.

What browser event cadence is

Cadence is the difference between the timestamps of consecutive keyboard events as the browser stamped them:

interval = ev[i].timeStamp − ev[i−1].timeStamp

Both timestamps come from the browser, on the browser's clock, at the moment the browser created each event. That is several layers downstream of the poll. Four separate effects sit between the two quantities.

1. Auto-repeat is generated by the operating system

Hold a key down and events keep arriving. Those are not extra reports from your keyboard being polled faster. The keyboard reports that a key is held; the operating system's own repeat logic manufactures the stream, using your configured initial delay and repeat rate. Change the slider in your system settings and the cadence changes, with the keyboard doing nothing different.

This is why every repeat event carries event.repeat === true, and why our collector routes those events to a separate channel instead of treating them as presses.

2. Events are queued and scheduled, not streamed

An event's timestamp reflects when the browser built it, but the browser builds it when the input reaches the renderer — after the OS has processed and routed it, and after a process hop. If the machine is busy, that path stretches. Two events that left the keyboard exactly 1 ms apart can be stamped 0.8 ms or 3 ms apart depending on what else the system was doing.

3. The clock is coarsened

Browsers reduce timer precision as a security measure. Depending on the engine and whether the page is cross-origin isolated, the smallest expressible difference may be around a tenth of a millisecond, or a full millisecond. Our pages probe this and print the result in the measurement environment panel, because it caps what any interval figure can mean.

4. You are the slowest component

For deliberate key presses, the interval is dominated by when you decided to press. At a steady 60 words per minute — five characters per word, so five keystrokes per second — presses land roughly 200 ms apart. A brisk 100 WPM is around 120 ms apart. Both are two to three orders of magnitude larger than any polling interval in the table above.

The arithmetic that settles it

Take the two rates people most want to distinguish. A 1000 Hz link reports at 1 ms intervals; a 2000 Hz link at 0.5 ms. The difference to detect is 0.5 ms.

Now suppose your browser expresses time in 1 ms steps, which is the case in some engines unless the page is cross-origin isolated. Every measured interval is rounded to a whole millisecond. A true 1.0 ms gap and a true 0.5 ms gap both collapse onto the same grid — you would be trying to read a 0.5 ms difference through a 1 ms ruler.

Give yourself a 0.1 ms clock instead and the quantisation problem eases, but the noise does not. Scheduling variation in the OS and the browser routinely moves individual event timestamps by more than 0.5 ms, and that variation is not centred, not constant, and not separable from the signal. Distinguishing 4000 Hz from 8000 Hz means resolving a 0.125 ms difference underneath it, which is hopeless.

And all of that assumes the events even correspond to polls. For deliberate presses they do not: the ~200 ms gap you produce swamps everything. For auto-repeat they do not either, because the OS is generating the stream. There is no configuration in which the browser-observed interval is a reading of the polling rate.

What the cadence test is genuinely useful for

Plenty, once you stop asking it the wrong question. The event cadence test reports the interval distribution as the browser saw it, and that distribution answers several real questions.

• Your OS key repeat settings. Hold a key and the steady-state interval is your configured repeat period, and the first gap is your initial repeat delay. Typical configured periods land somewhere between roughly 30 ms and 500 ms depending on the slider. The repeat rate test separates those two numbers explicitly.
• Irregular delivery. Events arriving in bursts, with gaps and clumps rather than an even stream, indicate the input path is being serviced unevenly — background load, a throttled tab, a virtual machine, or a remote desktop session batching input over the network.
• Duplicate events. Two events for the same key a few milliseconds apart are not a fast poll; they are a possible chatter pattern. The chatter test is built around exactly this signature.
• Before-and-after comparisons. Same machine, same browser, one variable changed. Cadence spread is a decent proxy for how smoothly input is flowing.

If you really want to know your polling rate

There are three honest routes, and none of them is a web page:

1. Read it from the keyboard. Vendor configuration software, firmware settings, or the documented specification will state the report rate the device is configured for.
2. Ask the operating system. Descriptor and endpoint information for a connected USB device is visible to native tools, which can show the configured interval.
3. Capture the bus. A USB protocol analyser — hardware or a low-level capture driver — records actual transfers with timestamps taken outside the browser entirely.

Once you know the rate, the polling rate calculator converts it into an interval and the average and worst-case wait it implies, which is the part that actually affects how the keyboard feels. For the bigger picture of what a browser can and cannot see, read why browser tests can't measure hardware latency, and for how the timestamps themselves are produced, see browser keyboard event timing explained. You can also just run the keyboard latency test and read the interval channel alongside the latency figures.