How Keyboard Latency Is Measured

Every method has two probe points

A latency measurement is an interval between two observations. Choose where you observe and you have chosen what the number means; everything outside those two points is excluded, however the result is later labelled.

The chain runs from switch actuation and firmware debounce through matrix scan, transmission, the operating system, the application and the render path to the display panel; the full stage-by-stage explanation covers what each contributes. Every method below brackets a different subset of it.

High-speed video

Point a camera at the keycap and the screen in a single frame, record at a known frame rate, then count frames from the press to the visible change.

What it sees: the whole chain, display included. It needs no access to the device, no drivers and no cooperation from the software, which makes it the only practical option for closed systems such as consoles.

Resolution: bounded by the frame interval — 1 ms per frame at 1000 fps, about 4.2 ms at 240 fps — with at least a frame of uncertainty at each end.

Blind spots: one aggregate number with no internal breakdown, so it can never say which stage was responsible. Deciding which frame counts as "the press" is a judgement call, because video shows keycap travel rather than the instant the contacts close. High frame rates also need a great deal of light.

Photodiode and LED rigs

A photodiode is a small sensor whose output changes with incident light. Aim one at a region of the screen, feed it to an oscilloscope or microcontroller, and you get a continuous trace of when that region changed brightness. Pair it with a trigger marking the press and both ends of the interval become electrical signals on one time base.

What it sees: the same whole chain a camera sees, sampled continuously rather than in discrete frames, so the time resolution is far better and does not depend on lighting.

Blind spots: still an aggregate with no per-stage attribution. Sensor position matters, because displays draw a frame progressively rather than all at once, so two spots on the same screen genuinely change at different times. The test application also has to produce a large, unambiguous luminance change.

Logic analysis of the USB line

Capture the signalling between keyboard and host — with a logic analyser that can decode USB, or a dedicated protocol analyser inserted inline — and timestamp the moment a keyboard report appears on the wire.

USB is a host-scheduled bus: the device never speaks unprompted. Keyboards use an interrupt endpoint and declare in their descriptors how often they would like to be serviced; the host polls within that budget. Full-speed devices are serviced on a 1 ms frame and high-speed devices on 125 microsecond microframes, which is why polling rates come in the values they do. Most keyboards also support the USB HID specification's boot protocol, a simplified fixed report format used before a full driver loads.

What it sees: with a known press trigger, switch closure through to the report leaving the device, at sub-microsecond timestamp precision. It uniquely separates "the device had the data ready" from "the host got around to asking".

Blind spots: nothing after the bus — driver, operating system, application, render and display are all invisible. For a wireless keyboard the capture point is the receiver's USB output, so the radio link is included but cannot be broken out.

Instrumented firmware

On a keyboard whose firmware you can build and flash, add code that toggles a spare output pin at chosen moments — the scan that detected the change, the end of debounce, the report queued, the report sent — and watch those transitions on a scope or logic analyser.

What it sees: the internal breakdown. It is the only method that answers "how much of this was debounce and how much was waiting for the bus?"

Blind spots: it needs firmware source and the ability to flash it, which rules out most commercial keyboards, and the instrumentation is itself a change to the code being measured. The result describes your build, not the stock firmware a buyer receives.

Operating-system input hooks

Software installed at driver or system-hook level timestamps input as it passes a given layer of the operating system. With an independent trigger, this brackets the host-side portion of the chain.

What it sees: the operating-system input stack, and how it differs between applications, with no hardware at all.

Blind spots: the timestamp is taken by software running on the same scheduler it is measuring, so the observation shares the delay it observes. It cannot see below the driver layer, and input may already have been batched by the time it arrives. Where a platform exposes a device-supplied timestamp, what moment that stamp represents varies by platform and driver, so it should not be assumed to mark the physical press.

Browser-side event timing

This is what this site does, so it is worth being precise. A keyboard event carries a timestamp recorded when the browser created it, shortly after the operating system handed the input to the browser process. JavaScript reads a high-resolution clock as the very first statement inside the handler and subtracts one from the other.

What it sees: browser event creation, queuing, main-thread availability and handler dispatch — precisely the delay a web application experiences. It needs no equipment, which makes large sample counts cheap and results easy to repeat.

Blind spots: the clock starts after the operating system has delivered the input, so switch, firmware, transport and OS scheduling are upstream and invisible. Browsers also coarsen their high-resolution clocks as a side-channel defence, by differing amounts across engines and configurations, which is why every test page here probes the resolution and shows it to you. Timestamps sometimes arrive on a different time base and must be normalised first.

Why the numbers are not interchangeable

Four independent reasons, any one of which is enough on its own.

• Different segments. A bus capture and a photodiode rig report intervals that only partially overlap. Treating one as a substitute silently swaps in a different quantity.
• Different definitions of the start. "The press" can mean the finger beginning to move, the keycap bottoming out, the contacts closing, or a sensor crossing a threshold — separated by real, variable amounts of time.
• Different statistics. One source quotes a minimum from a bench run, another a median under load. Both are honest; they are not the same number.
• Different conditions. An idle bench and a working machine do not produce the same distribution, and the gap is often larger than the hardware difference being investigated.

The rule follows directly: only compare numbers produced by the same method under the same protocol. And do not add figures from two methods hoping to build an end-to-end total — their intervals overlap in places and leave gaps in others, so the sum double-counts some stages and omits others. Build an end-to-end estimate deliberately from non-overlapping components instead, which is what the keyboard latency calculator is for. Its output is an estimate from values you supply, not a measurement.

What this site measures, specifically

Three channels, all browser-side, all defined openly:

1. Event latency — browser event creation to our handler running. The flagship number on the keyboard latency test.
2. Input to frame — the same event timestamp to the next animation frame callback, approximating how soon a visual response could appear.
3. Event interval — the gap between consecutive events, shown on the browser event cadence test. When a key is held this reflects your operating system's auto-repeat settings, not any hardware polling rate.

The formulas, validation rules, outlier handling and statistical definitions are published on the measurement methodology page. To see the raw event data instead of the statistics, use the keyboard event tester; to run a test properly, follow the step-by-step testing procedure.