keyboard
Keyboard latency test
Every keystroke is timestamped by the browser, then again when our handler runs, then again on the next painted frame. The difference is how long your key took to become a pixel.
display ≈ measuring…
dispatch median 0.00 ms
paint median 0.00 ms
samples
0
median
0.00ms
mean
0.00ms
min
0.00ms
p95
0.00ms
max
0.00ms
jitter (σ)
0.00ms
distribution
no samples yet
live event log
| # | input | dispatch | paint | total |
|---|---|---|---|---|
| waiting for input… | ||||
Numbers look odd? The interpretation guide explains what each metric covers and what the browser simply cannot see.
What this tool measures
This keyboard latency test measures the portion of input delay that the browser can observe. For every keystroke it records two timings:
Dispatch delay
Time from the browser's event timestamp to when our handler runs — pure main-thread queueing.
Paint delay
Time from the handler finishing to the next frame actually appearing on screen.
Total response
Dispatch + paint: the in-browser event-to-pixel round trip.
Jitter (σ)
Standard deviation of samples — how consistent the timing is.
The reaction-time mode adds a visual-cue test that measures your total reaction time, which includes your biology plus the system.
How to use it
- 01Click the panel to arm the test, then press any keys.
- 02Collect at least 40 presses for a stable median.
- 03Read the median total response — it's the most meaningful single number.
- 04Watch the histogram and jitter: consistency matters more than one fast press.
How the result is calculated
Each sample's total is dispatch + paint. We report the median (the middle value, robust to outliers), the mean, the p95, the min/max and the standard deviation as jitter. The median total response is the number worth comparing between runs.
What can affect the result
- 01Browser engine — Chromium, Firefox and Safari stamp events at different pipeline stages.
- 02Display refresh rate — paint delay is bounded by your frame time (e.g. ~8 ms at 120 Hz).
- 03Main-thread load — other tabs, extensions, screen recording and thermal throttling add jitter.
- 04Timer quantization — browsers blur performance.now() to mitigate side-channel attacks.
Tips for improving your result
- 01Close other tabs and pause downloads, calls and screen recorders.
- 02Plug in a laptop — power saving caps CPU and refresh rate.
- 03Repeat the run and compare medians; differences under ~2 ms are not real.
- 04Change one variable at a time: browser, cable, polling rate, display mode.
Frequently asked questions
Does this test measure my keyboard's true hardware latency?+
No. It measures the part of the input chain the browser can see: event queueing delay and the delay until the next painted frame. Switch actuation, USB polling and the OS input stack all happen before the browser and cannot be measured from JavaScript.
Why does the same keyboard give different numbers in another browser?+
Chromium, Firefox and Safari stamp keyboard events at different points in their input pipelines and quantise timers differently. Compare results within one browser, not across them.
How many key presses do I need for a stable result?+
Collect at least 40 samples. Medians from fewer presses are noise. Differences under about 2 ms between two runs are not meaningful.
Is a lower number always better?+
Consistency (low jitter) often matters more than a single fast sample. A steady 12 ms usually feels better than a range of 3–40 ms.