mouse
Mouse latency test
Click timing works exactly like the keyboard test. The sample-rate probe counts how many pointer events per second the browser actually hands over — usually far fewer than your mouse sends.
display ≈ measuring…
—ms
click anywhere in this panel
0 samples · aim for 40+
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… | ||||
Pointer rates far below your mouse's advertised polling rate are normal — the guide explains coalescing and the rest of the caveats.
What this tool measures
The mouse test measures the browser-visible part of mouse input across three modes. Click timing is identical to the keyboard test; the sample-rate probe counts how often the browser actually delivers pointermove events.
Click latency
Click event → next painted frame: the in-browser click-to-pixel delay.
Sample rate
Pointermove events per second the browser hands to JavaScript.
Coalesced events
Hardware events merged into a single delivered event by the browser.
Reaction time
Visual-cue response time, including your biology plus the system.
How to use it
- 01Click timing: click the panel, then click as the flash appears — collect 40+ clicks.
- 02Sample rate: move the pointer steadily across the probe for a few seconds.
- 03Reaction time: wait for the green signal, then click as fast as you can.
- 04Read medians; compare within one browser.
How the result is calculated
Click timing uses the same method as the keyboard test: each click's total is dispatch + paint, reported as median, mean, p95 and jitter. The sample-rate probe counts pointermove events over a window and converts to events per second (Hz). Coalesced events are reported when the browser exposes them.
What can affect the result
- 01Event coalescing — browsers merge pointer events, so the delivered rate often matches the refresh rate, not the sensor's polling rate.
- 02Display refresh rate — paint delay and delivered event rate are both bounded by frame time.
- 03Pointer acceleration and sensitivity — change target acquisition, not click timing.
- 04Main-thread load — heavy tabs and extensions add dispatch delay and jitter.
Tips for improving your result
- 01Close other tabs and background apps before measuring.
- 02Use a wired connection and disable power saving on a laptop.
- 03For sample rate, keep the pointer moving at a steady, moderate speed.
- 04Repeat runs; medians of 40+ samples are the only stable comparison.
Frequently asked questions
Why does my 1000 Hz mouse show a lower sample rate in the test?+
Browsers coalesce pointermove events, so the rate JavaScript receives is often the display refresh rate, not the sensor polling rate. 1000 Hz of hardware input can still reduce latency even when the reported event rate is lower.
What is click latency measuring here?+
The browser-visible portion: time from the click event timestamp to the next painted frame. USB polling, button debounce and the OS stack are before the browser and not included.
Do pointer acceleration and sensitivity affect click latency?+
They affect where the cursor lands and target acquisition, not the timing of a click. They mainly matter for the aim trainer, not for click latency itself.
Is a higher sample-rate number always better?+
More delivered events can mean tighter cursor tracking, but once the rate matches your refresh rate, higher sensor polling mainly helps latency, not the reported number.