A mouse may be configured for 125, 500, 1000, 4000 or 8000 Hz, but a webpage does not connect directly to the USB polling transaction. It receives pointer events after the device, firmware, operating system and browser have processed them. Browsers may combine movement into fewer events, schedule delivery with rendering or expose more detail only through specific APIs and environments.
That means an online polling test measures browser-observed event delivery. This is still useful for comparisons, but it is not a certificate of the device’s firmware rate.
Run a cleaner sample
Open the Mouse Polling Rate Test, close heavy background tasks and keep the tab visible. Start the five-second sample, then move continuously in smooth circles inside the area. Stopping movement creates real gaps and lowers the observed rate.
Run at least three samples. Keep the same movement area and speed as closely as possible. Compare the observed rate, median event interval, 95th-percentile interval and event count. A single highest reading can look impressive while hiding long gaps; the distribution describes stability better.
At an ideal 1000 Hz, the interval between reports would be about one millisecond, but browser delivery is not ideal or direct. Display refresh, CPU load and event coalescing can all reshape what the page sees.
Use median and percentiles
The average can be distorted by a few long pauses, especially if movement slows near the edge of the test area. Median represents the typical interval more robustly. The 95th percentile helps show whether a meaningful portion of intervals are much longer than usual.
Look for consistency across runs. A stable but lower browser-observed rate may reflect an environment cap. A broad distribution that changes with CPU load or power mode points toward scheduling and system conditions. Large isolated spikes may simply mark a pause in hand movement.
Compare conditions without overclaiming
If the result is unexpectedly low, repeat in another current browser. Connect the mouse directly instead of through an unpowered hub. On a laptop, compare battery and plugged-in power modes. For wireless devices, move the receiver closer and reduce interference. Keep the configured mouse rate unchanged while testing these variables.
Then change the configured rate and repeat. If a 500 Hz and 1000 Hz profile produce clearly different browser distributions under the same conditions, the test is showing a meaningful relative change—even if neither reported number equals the firmware setting exactly.
High-rate devices are especially difficult to verify in a normal webpage. Multiple hardware reports can be coalesced before the event handler runs, and JavaScript execution shares the main thread with rendering and other work.
Higher is not automatically better
Higher configured rates can reduce the maximum interval between hardware reports, but they also increase CPU and power demand. Practical benefit depends on the complete chain: device, USB controller, CPU, game engine, frame rate and display. An unstable high-rate configuration can be less useful than a stable lower rate.
Use the browser test to identify differences and obvious instability. Use specialized hardware or low-level tools if you need to certify USB report timing. Keymap Labs deliberately labels the result “observed rate” to preserve that boundary.
Report a reproducible issue
Record the mouse model, connection, configured rate, browser, operating system, power mode, three observed medians and whether the movement was continuous. If changing one port or browser changes all three runs, include that comparison.
A useful report describes the method. “My 1000 Hz mouse gets 742 Hz online” is incomplete; the gap may be the browser path. “Three continuous samples in browser A show a narrow 500 Hz distribution while browser B and a device utility show a different result” gives support or engineering a place to begin.