How DeviceCheckOnline measures mouse polling rate
Polling rate is the number of times per second your mouse reports its position to the host. A 1000 Hz mouse reports every 1 ms; an 8000 Hz mouse reports every 0.125 ms. Measuring it correctly in a browser requires care — pointer events arrive batched, and the wrong timestamp source can hide jitter.
Open the tool →1. Capture every sample, including sub-frame events
Modern Chromium browsers receive raw mouse data at high frequency, but compose all motion that happened during a single rendering frame into one PointerEvent. To recover the individual samples we call `event.getCoalescedEvents()`, which returns the queue Chromium would otherwise have merged. Without this step a 4 kHz mouse looks like a 60 Hz mouse — you'd be measuring the display, not the device.
2. Use hardware timestamps, not handler-fire time
`event.timeStamp` is set when the OS delivered the event to the browser, before the JavaScript event loop introduced queueing latency. `performance.now()` inside the handler measures when our code finally ran — that includes scheduling jitter, ad scripts on other pages, and rAF backlog. We use `event.timeStamp` exclusively. The two can differ by 5–30 ms during page load.
3. Discard idle and tiny-motion samples
The browser delivers a small number of zero-motion events when the cursor stops moving but the OS continues to poll. These would dominate any naive average. We compute inter-arrival intervals only between samples whose Euclidean motion is ≥ 0.5 CSS pixels, then drop intervals greater than 200 ms (pauses).
4. Report the median, not the mean
Even with clean data, a few outliers can shift the mean dramatically. We report the median inter-arrival interval and invert it for Hz: `hz = 1000 / median`. We also surface p1 (the fastest 1% — your burst peak) and p99 (the slowest 1% — your sustained floor) so you can see jitter directly. CV (coefficient of variation) gives a single number for stability.
5. Honest disclosure of what we cannot measure
Browser coalescing is the ceiling. Chromium delivers up to ~8 kHz on Windows; Firefox typically caps at 1 kHz; mobile browsers don't expose pointer events at the same fidelity. Behind that, the OS itself may filter (Windows pointer enhancement, macOS pointer acceleration). What we see is the *effective* rate as the page receives it — the true wire rate is between the device and the kernel.
FAQ
Why does my 8000 Hz mouse only show 1000 Hz here?
You may be on Firefox, which historically does not coalesce events beyond ~1 kHz, or on Chrome without raw input. Try Chrome 120+ on Windows with no pointer acceleration.
Why is my reading slightly under the marketed rate?
Marketed rate is the wire rate. After OS + browser filtering, expect 5–10% loss. A 1000 Hz mouse usually reports 960–990 Hz median on a clean machine.
Does pointer acceleration affect the reading?
No — polling rate is the *count* of reports per second, which acceleration doesn't change. It can shift jitter slightly via OS scheduling but the median should hold.