Keyboard Latency Test
Time the gap from a key event to the next animation frame, how long a tap stays down, and how soon the same key can be pressed again. Compare two keyboards. The clock starts after the browser already has the event.
Needs a physical keyboard. Tab and browser shortcuts keep working.
Browser queueis the time between the moment the browser stamped the key event and the moment this page's handler ran. To next frame adds the wait for the next animation frame, so it averages about half a frame (around 8 ms at 60 Hz, 2 ms at 240 Hz). Both start when the OS hands the event over, so the switch, scan, debounce and USB time is not included. A queue of 0 ms is left out of the queue average. A frame time of 0 ms or over 1000 ms is dropped.
A/B comparison
Run the tests with the first keyboard, save it as A, then switch keyboards, press Reset all, run the same tests again and save as B. Wired, 2.4 GHz and Bluetooth differ mostly before the browser sees the key, which these numbers do not include.
| Metric | A (empty) | B (empty) |
|---|---|---|
| Event to frame (avg) | -- | -- |
| Event to frame (SD) | -- | -- |
| Browser queue (avg) | -- | -- |
| Shortest tap | -- | -- |
| Median tap | -- | -- |
| Fastest re-press | -- | -- |
| Average re-press | -- | -- |
| 8 ms grid (125 Hz hint) | -- | -- |
Absolute latency: the camera method
A browser only sees a key once the OS delivers it, so the time inside the keyboard is invisible to any website. To measure the whole chain, tick the flash box above, then film the keyboard and screen together in slow motion (240 fps gives 4.17 ms per frame). Press a key sharply and count the frames from the key bottoming out to the square turning white. Repeat 10 times and average.
The count includes your monitor's own lag. Keep the same screen when you compare keyboards. The input lag test does not report monitor lag by itself, so do not subtract its click-to-photon number from this one.
What makes a keyboard slow
Where keyboard latency comes from
A press passes through four stages before the PC sees it. The controller scans the switch matrix, often every 1 ms, sometimes slower. It then debounces the contact, waiting for the metal leaf to stop bouncing: 5 ms is a common default, and some boards wait longer. Next the key waits for the USB poll, up to 8 ms at 125 Hz or 1 ms at 1000 Hz. Wireless adds the radio link, small on a good 2.4 GHz dongle and often 7 to 15 ms or more over Bluetooth. Typical totals run from about 2 ms on the best boards to 30 ms or more on slow ones.
What "0.1 ms" on the box measures
Claims like 0.125 ms or 0.1 ms response usually describe one stage only, normally the 8000 Hz polling interval or the scan rate. They say nothing about debounce or the switch travel your finger needs before actuation. A keyboard sold as 0.1 ms can still take 5 ms or more end to end. Independent end-to-end tests with a camera or a sensor are the only numbers worth comparing.
Hall-effect and rapid trigger, honestly
Magnetic switches read the key position continuously, so they need no contact debounce and can trigger at a shallow point you choose. Rapid trigger resets the key as soon as it starts rising and fires again on the way down, which helps fast taps and counter-strafing in shooters. The gain is real but comes from shorter travel, not from faster electronics, and it only shows in the re-press test, not in event delivery.
Reading your results
Event to frame under one refresh interval is healthy; spikes point to background load or a busy browser tab. Close heavy apps and use a high refresh rate screen to cut it. A hard tap floor or an 8 ms grid points at the keyboard, so check the polling rate in its software and compare it with the keyboard polling rate test. Dongle distance is not in these numbers. Time that radio delay with the camera method above.
Related tools
Estimate the USB report rate with the keyboard polling rate test, check every key with the keyboard tester, measure your click-to-photon lag with the input lag test, and run the same checks on your mouse with the mouse latency test.
Frequently asked questions
What does this keyboard latency test measure?
Three things the browser can already see. Event delivery is the wait from the key event timestamp to the handler on this page, then on to the next animation frame. Tap hold time is how long the key stayed down. Rapid re-press is the gap between the key going up and the same key going down again. The clock does not start at the switch.
Is this the latency printed on the keyboard box?
No. The browser receives the key only after the controller scans the switch, waits out debounce, and the USB or wireless link delivers the report. That earlier time is not in the event timestamp. A box claim of 0.1 ms usually names the polling interval or the scan rate, not the full path from the finger to the pixels.
What is the event-to-frame number?
It is the time from the key event stamp until the next animation frame. At 60 Hz a frame is about 16.7 ms, so the average is often near half a frame. A busy tab makes it larger. It does not include monitor lag. Use a quiet browser window if you want a steady reading.
Why are some presses left out?
A frame time of 0 ms, a negative time, or a delay over 1000 ms is dropped. Zero means the two timestamps landed on the same instant, which is not a real delay. A huge number usually means the tab was in the background. A queue of 0 ms is left out of the queue average, but the frame time can still count. Tap times of 0 ms or over 300 ms are left out, and re-press gaps of 0 ms or over 400 ms are left out too.
How do I compare two keyboards?
Run the tests on the first keyboard and save slot A. Switch keyboards, press Reset all, run the same tests, and save slot B. Event to frame mostly follows the PC and the refresh rate, so it rarely separates two boards. The shortest tap and the fastest re-press are the numbers more likely to differ. Wired, 2.4 GHz and Bluetooth differ mostly before the browser sees the key, so this table will not show that gap.
How can I time the whole path, including the keyboard?
Use the camera method on this page. Turn on the white square, film the key and the screen together in slow motion, and count frames from the key bottoming out to the square turning white. At 240 frames per second each frame is about 4.17 ms. The count includes monitor lag. Keep the same screen for both keyboards. Do not subtract the input lag test click-to-photon number: that test includes a mouse as well, so it is not monitor lag alone.
Will rapid trigger show up in these numbers?
It can shorten the re-press gap, because a Hall-effect key with rapid trigger resets as soon as the key starts moving up. It does not change the event-to-frame number. Finger speed still sets most of the gap, so compare the same person on both boards rather than treating one gap as a hardware spec.