This page follows the dedicated latency-page pattern from keyboard testing sites, while staying explicit that it observes browser-side latency and jitter rather than lab-grade hardware latency.
Average delay
-- ms
Jitter
-- ms
Minimum delay
0.0 ms
Maximum delay
0.0 ms
P95 delay
0.0 ms
Samples
0
Press any key
Suggested keys: Space / Enter / Shift
Each sample stores the key, the event queue delay, and the approximate next-frame response delay.
The chart shows the latest 100 samples. Lower and flatter usually means more consistent browser-side response.
Input latency usually means the time from a physical key press to a visible or usable response on screen. True end-to-end keyboard latency is normally measured with high-speed cameras, oscilloscopes, dedicated trigger rigs, or other physical test equipment. This page does not read the raw USB hardware path. Instead, it observes the system-and-browser side of the input chain after the event reaches the web page.
The core signal here is the gap between the keyboard event timestamp, browser-side event handling, and the next rendered frame. That makes it useful for checking whether the current system and browser environment is responding smoothly.
A normal web page cannot directly inspect switch closure timing, MCU scanning, USB transfer timing, or the monitor’s real physical pixel transition. Because of that, these numbers should not be treated as the absolute hardware latency advertised in device marketing.
A low average can still feel bad if the latency keeps jumping around. For fast games and rhythm-heavy input, steadiness is often more valuable than a single impressive minimum sample.
Keyboard latency is the result of several layers stacked together. This page mainly observes the later system / browser / rendering part, so it is better for environment checks than for proving the physical limit of a switch or controller.
Switch closure speed, Hall effect trigger settings, return behavior, and debounce all affect the earliest part of the input path, but the browser cannot read those raw physical timings directly.
Scan rate, firmware filtering, and wired or wireless transport quality all influence how quickly the event reaches the operating system.
This is the part the page mainly sees. Once the OS hands the event to the browser, main-thread load, tab state, frame cadence, and render timing start shaping the result.
If you want cleaner and steadier results on this page, start with system load, display behavior, and connection quality before chasing tiny number differences.
Heavy tabs, downloads, streaming, overlays, or recording tools can raise both the average and the spike rate. A lighter environment usually produces much cleaner samples.
Once the average looks decent, jitter is usually the next thing worth improving. Stable power settings, fewer context switches, and less interference often matter more than forcing one lucky low reading.
Wired mode or a stable 2.4G receiver setup usually behaves more consistently than a noisy Bluetooth environment. Comparing modes can reveal whether the environment is part of the problem.
If you need real end-to-end keyboard latency, advertised-spec validation, or hardware-level timing, you still need dedicated physical equipment. A browser page is best used for daily checks and relative comparisons.
These answers help separate browser-visible input response from true hardware-side latency, so different layers of the input path do not get mixed together.
Not exactly. A web page cannot directly read the full physical chain from switch actuation through USB transfer to real pixel response. This page is better understood as a browser-side processing and responsiveness reference.
On a modern desktop browser with a reasonably light workload, an average around 5 ms to 15 ms is often already quite good. If the page keeps living above 30 ms, or spikes are frequent, the input path is more likely to feel sluggish.
Because feel depends on consistency. One very low reading does not help much if the next few samples swing wildly. For muscle memory and timing-sensitive play, steadiness usually matters more than a single best-case number.
Try reducing background CPU load, avoiding aggressive power saving, preferring wired or stable 2.4G mode, and removing parts of the display chain that add extra waiting or frame pacing overhead.
Then you need physical measurement tools such as a high-speed camera, oscilloscope, external trigger rig, or a dedicated commercial input latency setup. A browser page cannot replace that kind of hardware test bench.
Only in a very rough, high-level sense. It cannot accurately identify the real hardware polling rate because the result also includes transport mode, OS scheduling, browser main-thread load, and refresh behavior. Theoretical intervals like 125Hz ≈ 8ms, 250Hz ≈ 4ms, 500Hz ≈ 2ms, and 1000Hz ≈ 1ms are easy to blur once browser-side noise is mixed in.