How to Test Keyboard Latency (Step by Step)

The two-minute version

If you only want a usable number right now, open the browser-based keyboard latency test and do this:

1. Close anything heavy: video calls, streams, builds, downloads, screen recorders.
2. Click the test stage so the page has keyboard focus, and leave the window alone.
3. Type at a natural pace for ten seconds, then reset. That was the warm-up.
4. Now collect at least 30 presses without switching windows.
5. Read the median and the consistency label. Ignore the single fastest sample entirely.

The rest of this guide explains why each step matters, and what it takes to measure the hardware stages a browser cannot see.

What you are testing

A web page receives keyboard events only after the operating system has handed them to the browser. This test measures the interval from the browser creating the key event to your handler running — the browser input pipeline and main-thread scheduling. That is real and reproducible, and it is not your keyboard's hardware timing. The stage-by-stage breakdown of the input chain shows which segment it is.

Step 1 — Quiet the machine

Almost everything that inflates a browser-side latency number is competition for the CPU and for the browser's main thread. Before a run you intend to keep:

• Close video calls, media playback, screen recording and streaming software.
• Let any compile, render, backup, sync or large download finish first.
• Close other browser tabs, especially ones with active timers or media.
• Use a private window if you can. An extension that injects a script into every page adds work to the same main thread you are timing.
• On a laptop, plug in the charger. Power saving lowers clock speeds and changes scheduling, which shows up directly in these numbers.

Step 2 — Focus, and keep it

Keyboard events go only to the focused window, and within it only to the focused element. If the page loses focus mid-run, the samples collected in that period measure nothing meaningful, which is why the test excludes them and tells you how many it excluded.

So click the test surface before you start, then leave the window alone: no alt-tabbing, no clicking into another window to check something. If the results panel reports focus interruptions, discard the run and repeat it.

Step 3 — Read your measurement environment first

Browsers deliberately coarsen their high-resolution clock as a security measure, by differing amounts. The measurement environment panel shows the resolution the page actually probed.

If it is 1 ms or worse, every sample is quantised to whole milliseconds: the median still means something, but fine-grained jitter is not resolvable. Write the resolution down — a run at 0.1 ms and a run at 1 ms are not comparable.

Step 4 — Warm up, then discard the warm-up

The first presses in a run are systematically slower, for reasons unrelated to your keyboard. The page may still be doing layout work, the JavaScript engine has not yet optimised the handler, caches are cold, and the CPU may still be at a low clock state.

The fix is trivial and most people skip it: type for five to ten seconds, reset, then start the run you intend to keep. If you cannot reset, check whether your first few samples sit visibly above the rest of the distribution.

Step 5 — Collect enough samples

How many you need depends on which statistic you care about. The median settles quickly; the tail does not.

The arithmetic is simple: with 30 samples only about three sit above the 90th percentile, so P90 rests on a handful of observations. Percentiles further out need proportionally more data, which is why this site prints no P99 below 20 samples rather than a number that looks precise and is not.

While collecting, press at a natural typing pace, vary the keys, and do not hold one down. Held keys generate operating-system auto-repeat events, which measure your OS repeat settings rather than press latency — that is what the repeat rate test is for. Bare modifiers are excluded too, and mashing as fast as possible just measures something other than normal use.

Step 6 — Read the median, not the best

Your fastest sample is the single luckiest scheduling outcome in the run. It sits at the extreme edge of the distribution, so it drops the longer you keep testing — a "best" figure describes how long you sat there pressing keys, not how your system behaves.

The median has half the samples above it and half below. It barely moves once you have enough data and it is immune to a single catastrophic outlier. Quote it with the sample count attached: "6.1 ms median over 42 samples" is a claim; "6.1 ms" alone is not.

Step 7 — Look at the spread, not just the centre

Two systems with identical medians can feel completely different. What separates them is consistency.

• P90 and P95 describe the bad tenth of your presses. That is the part you notice.
• Jitter, defined here as the mean absolute difference between consecutive samples, describes how much timing lurches from one press to the next.
• The consistency label comes from the coefficient of variation and is always shown beside the number that produced it.

A slightly higher median with a tight spread is usually the better-behaved system. A low median with a long tail means something is intermittently stealing the main thread.

Step 8 — Record the conditions

A latency number with no context cannot be compared to anything, including your own result from last month. Before you close the tab, write down or export the following.

Note roughly when you tested, too — thermal state drifts over a session. Runs saved here keep the environment details alongside the statistics, and the session comparison tool shows whether a difference between two of them exceeds the noise.

Step 9 — Change one thing at a time

The only comparison that supports a conclusion is one where a single variable moved. Run a baseline, change exactly one thing, then repeat with the same sample count, browser, power state and background applications.

Useful experiments: USB hub versus direct port, a wireless keyboard on Bluetooth versus its dongle, two onboard polling settings, or two keyboards on the same machine minutes apart. Comparing your result to a stranger's on different hardware and a different browser is not an experiment.

Methods that go beyond a browser

Everything above measures the browser-side segment. The stages before it need instruments, and none of them can run inside a web page.

High-speed video

Film the keycap and the screen in one frame at a known frame rate and count frames. Precision is 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. It captures the whole chain, display included, which is also why it cannot say which stage was responsible.

A microcontroller that presses the key

Replace the finger with electronics: a microcontroller closes the switch contact and timestamps that moment, while a second capture point observes when the report appears on the USB line. One clock records both ends, so it isolates the keyboard's own contribution far more precisely than a camera.

Instrumented firmware

On a keyboard with modifiable firmware, toggle a spare pin at chosen points in the scan and report path and watch those transitions on a scope. It is the only method that shows the internal breakdown: debounce versus scan interval versus waiting for the bus.

The trade-offs of each instrument, and the reason their numbers cannot be compared with each other, are covered in how keyboard latency is measured. Once you have a result, what counts as a good keyboard latency explains how to judge it without falling for an invented threshold.