Keyboard latency test (the honest one)
This keyboard latency test measures what a browser can truthfully measure: the wait from a keydown event to the next rendered frame, sampled over 20 presses, with the event's own dispatch delay reported separately rather than folded in. It will not pretend to read your keyboard's hardware latency, because no web page can.
What this test actually measures (read this first)
The main number is your browser's wait for the next frame: the time from a keydown event arriving in JavaScript to the next animation-frame callback, sampled with performance.now() and requestAnimationFrame. The timer starts after the browser has already delivered the event, so dispatch is not in that figure; it is measured separately from the event's own timestamp and reported in its own tile. It is NOT the keyboard's hardware latency. Switch actuation, debounce firmware and USB polling all happen before the browser ever sees the event and are invisible to any web page. Competitor sites claiming to measure keyboard latency in a browser are wrong; only external hardware (a high-speed camera or a latency rig like an LDAT) can measure end-to-end keyboard lag.
Press Start, then tap any key 20 times at a relaxed pace (single taps, not holds). Each press is timed from the keydown event to the next frame callback.
Audio path latency (reported by your browser)
Relevant if you use our keyboard sound simulator: this is the delay the browser reports between generating audio and it reaching your output device. It is self-reported by the audio stack, not measured with a microphone.
How this latency test works, and what it refuses to claim
When you tap a key, the tool records a performance.now() timestamp the moment the keydown event
reaches JavaScript, then schedules a requestAnimationFrame callback and measures the gap to it. That
gap is frame scheduling, not the whole pipeline: by the time the timer starts, the browser has already dispatched
the event. So the tool reads the delay that stage cost from the event's own timeStamp, which shares
performance.now()'s time origin, and reports it as a separate dispatch figure instead of quietly folding it in.
Twenty single taps are collected and summarized as median, minimum and maximum, because the median resists the
occasional garbage-collection or scheduling spike that would distort an average.
What happens before that timestamp is invisible to us and to every other website: the switch travels and actuates, the keyboard's firmware debounces the contact, the controller waits for its next USB poll, and the operating system routes the event. Those stages are where keyboards actually differ, and measuring them requires hardware outside the computer under test. Any browser tool quoting your "keyboard latency" as a single number is reporting the same pipeline we do while labeling it as something it is not.
Making sense of your numbers
Compare the frame-wait median to your display's frame time: 16.7 ms per frame at 60 Hz, 6.9 ms at 144 Hz. Your
press lands at a random point inside the current frame, so the median settles near half of that on any machine.
A faster computer does not move it much; a higher refresh rate does. What a busy system moves is the spread and
the dispatch figure. If the maximum towers over the median, or dispatch drifts above a millisecond or two,
something stalled during the run: a heavy tab, a background update, or power-saver throttling on a laptop. Rerun
after closing extra tabs and you will usually see both tighten. The audio-path section is separate and reports
the browser's own baseLatency and outputLatency figures, which matter when you play
switch sounds through our keyboard sound simulator.
Latency is only one piece of a keyboard health check. Verify every key registers with the keyboard tester, count simultaneous keys with the ghosting and NKRO test, and hunt double-firing switches with the key chatter test. If raw speed is why you are here, our switches for gaming guide explains where switches actually make a measurable difference, and where they do not.
Frequently asked questions
Can a website measure my keyboard’s hardware latency?
No. Switch actuation, debounce firmware and USB polling all happen before the browser ever receives an event, so they are invisible to any web page. A browser test can only time what happens after the keydown event arrives in JavaScript. Sites claiming to measure true keyboard latency in a browser are misrepresenting what the web platform can see; real end-to-end measurement needs external hardware such as a high-speed camera or a dedicated latency rig.
What does this latency test actually measure?
Two things, reported separately. The headline number is frame scheduling only: the time from a keydown event arriving in JavaScript to the next animation-frame callback, timed with performance.now() over 20 sampled presses. The event has already been dispatched when that timer starts, so dispatch delay is measured on its own from the event’s timestamp and shown in its own tile. Between them they cover the part of input lag a web page can honestly observe and the part you feel in browser games and web apps.
What is a normal result?
For the frame-wait figure, expect roughly half a frame time. Frames arrive on a fixed cadence, so where your press lands inside the current frame decides the wait, and the median settles near the middle: about 8 ms on a 60 Hz display where a frame lasts 16.7 ms, about 3.5 ms at 144 Hz. A fast machine does not push that number much below half a frame, so treat it as a refresh-rate reading rather than a speed score. The dispatch figure is the one that reflects load: it should sit near zero, and it climbs when the tab is busy, the machine is throttling, or the window is hidden.
What are baseLatency and outputLatency?
They are the audio stack’s self-reported delays exposed on AudioContext: baseLatency is the processing delay of the audio context itself, and outputLatency estimates the time for audio to travel from the browser to your speakers or headphones. They matter if you use keyboard sound simulators, and they are reported values from the browser, not microphone-verified measurements. Not every browser exposes both.
How do I actually reduce input lag on my keyboard?
The wins that matter: use a wired connection or a low-latency 2.4 GHz dongle instead of Bluetooth, raise the polling rate if your board supports it, enable your monitor’s game mode, close heavy background apps, and prefer a high-refresh display. Switch choice contributes fractions of a millisecond by comparison; connection type and display pipeline dominate.