Why Browser Mouse Polling Rate Tests Read Low

This site's mouse test estimates the rate of browser-visible movement samples. It cannot read USB transactions, discover the manufacturer's active polling setting, or verify that every device report reached the page. Even a plausible-looking result needs that context.

When tools disagree, identify their measurement layer first. A native application using Windows Raw Input and a browser using Pointer Events observe different interfaces. Agreement between two websites is useful for comparison, but it does not independently validate USB-level accuracy.

Some movement-event delivery is aligned with rendering. Chrome's explanation of aligned input events describes delaying continuous events until just before animation-frame callbacks to reduce repeated work. That is a documented delivery strategy, not a universal cap on all browser-visible movement samples.

A simple callback counter could therefore show a rate near the page's frame cadence. If each callback exposes several historical samples, an estimator can count those samples instead. Display refresh rate, callback rate and sample rate must be kept separate.

A result near 120Hz on a 120Hz screen is a clue, not proof of frame locking. A real low-rate device can be numerically close to the display cadence. Our estimator also looks at dispatch intervals and their phase relative to observed frames before marking suspected frame alignment.

Changing an in-game VSync setting does not automatically change how a separate webpage receives input. To compare browser behavior, record the browser version, display refresh rate, event path and measurement status.

Pointer Events Level 3 says browsers should dispatch pointerrawupdate as soon as possible and as frequently as JavaScript can handle it. It also allows raw updates to be coalesced while a preceding update is waiting for dispatch. API support therefore does not guarantee a complete hardware report stream.

getCoalescedEvents() exposes the movement samples merged into an event when the browser supports that interface. A measurement should process that list when it is nonempty, and otherwise process the parent event. Adding both would count the same movement twice.

This site prefers raw updates, falls back to pointermove if needed, and counts only the selected stream. A run retries the preferred path. It expands available coalesced samples and keeps their timestamps separately from callback arrival times.

These APIs require a supporting browser and a secure context. A missing or silent raw API activates the fallback; if that fallback exposes only parent movement events, the page withholds quality metrics. Changing browser may expose a more useful stream, but cannot certify that every upstream report survived.

The nominal 8000Hz period is 0.125ms. That makes individual interval statistics sensitive to clock precision. The High Resolution Time specification permits timestamp coarsening and jitter for privacy. Its non-isolated baseline is 100 microseconds, or a coarser implementation-defined value; cross-origin isolation permits a finer baseline but still does not guarantee it.

Several real updates can share the same exposed timestamp. Calculating 1000 / 0 would give an unusable infinite rate. Very short rounded intervals can also produce misleading peaks. Collecting a longer run adds samples, but does not improve timestamp resolution.

Our estimator counts samples over elapsed time for Average and complete arrival windows for Stability. It can therefore retain those results while hiding Peak and interval Jitter when the timestamp checks fail. A timing-limited result is an explanation of available evidence, not an automatic hardware failure.

The estimator's clock probe and browser-family floors are conservative estimates. They cannot establish the true resolution of every event timestamp or reconstruct movement samples that the browser never exposed.

1. Confirm the hardware setting. Check the active profile, connection and supported receiver using the polling-rate setup guide.
2. Keep the page focused. Stay in the foreground through the run. Losing focus or hiding the tab interrupts capture on this site.
3. Move continuously. Use comfortable, brisk movement. At high rates, try wider movement or higher DPI and record that change. Pauses after the first movement stay in Average and Stability.
4. Read the status before judging Hz. Collect at least 3 seconds and 100 samples. A browser-limited or timing-limited result needs its corresponding explanation.
5. Repeat controlled comparisons. Keep DPI, motion and display settings comparable. Try another browser and record its version. Close unnecessary workloads for a separate comparison.
6. Escalate to the appropriate measurement layer. A native input tool can help inspect OS-visible delivery. A USB-level claim needs a suitable USB-level reference; a game-performance claim needs game measurements.

OS scheduling and main-thread work can delay callback delivery. The webpage cannot reliably distinguish all such causes from device or connection behavior. A low reading can also reflect a setting that was not applied, limited movement, or upstream delivery changes. The controlled comparisons narrow the possibilities without assigning blame prematurely.

“Samples sufficient” and interval availability are separate. Neither status certifies the mouse's hardware rate. For the formulas behind the values, continue with the Stability and Jitter guide.

Frequently asked questions