Keyboard Latency Test: From Key Press to the Next Frame

What this test times

When a key goes down, the keyboard reports it at its next polling interval, the operating system passes it to the browser, and the browser gives the page a key event with a timestamp. The tester lights the key up and asks the browser to call it back before it draws the next frame (an animation-frame callback); the time from the event’s timestamp to that callback is one sample. Twenty presses give a steady median, and the jitter figure shows how much the samples vary.

The tester also counts the display’s frame time from 60 frames, because it dominates the result: on a 60 Hz screen a press waits up to 16.7 ms for the next frame, on a 144 Hz screen up to 6.9 ms.

What it can’t see

A web page only learns about a key once the browser has it, and only knows when it is about to draw a frame, not when the browser finishes it or when its light leaves the panel. So the switch travel and debounce, the USB polling wait (half an interval on average) and the display’s scan-out and pixel response are all outside this number. That makes it a good test of the computer side: a busy system, a heavy browser tab or a slow remote-desktop link shows up as a high median or a long tail in the histogram. It is not a measure of the keyboard’s own speed; for that, check the polling rate and the switch and debounce figures from reviews.

Getting a lower number

A higher refresh rate helps most, since waiting for the frame is the biggest share. After that: close background programs, keep the browser tab in the foreground, and turn off power-saving modes that park the processor. If single presses sit far to the right of the histogram, run the test again with nothing else open: a steady median with a short tail is what a healthy system looks like.

Where the time goes between a press and the screen

Typical figures for each stage of end-to-end input lag, and whether this test includes it.