Mouse Polling Rate Test — Hz, Jitter & Click Speed

Three tests, one honest label

The polling-rate test asks you to circle your mouse inside a pad for a few seconds. It counts every pointermove event the browser delivers — average rate, busiest 100ms window, interval jitter, and a histogram bucketed around the standard rates (125 / 250 / 500 / 1000Hz). Where the browser exposes sub-frame samples, those get counted separately and labeled as such.

The click test is a CPS counter — pick 1, 5 or 10 seconds and click. Alongside raw speed it reports your dwell time (how long each press holds the button) and the event delivery delay — the in-browser share of click latency. The scroll test does the same for the wheel: delivered events per second, total delta, and the units your browser reports in.

The ceiling this page can’t see past

Browsers deliver pointer events on the frame loop: on a 60Hz display, the delivered rate can’t exceed ~60Hz even if the mouse polls at 8000Hz. Chrome/Edge recover sub-frame timestamps via getCoalescedEvents (up to roughly ~1kHz); Firefox and Safari hand over one timestamp per frame. So the number above is honestly reported as the browser-observed event rate — a real measurement of the event path, but not a wire measurement of the mouse.

If a result looks low: check your display’s refresh rate first, then read what polling rate actually is, whether 8000Hz is worth it, and — for the number no browser can produce — how to measure polling rate at the hardware level. Curious where the rest of your click latency goes? That’s the input lag chain.

Frequently asked questions

What does this test actually measure?

The browser-observed event rate: how often pointer events are delivered to this page per second. That is not the same as your mouse's USB polling rate — browsers deliver pointermove on the frame loop, so a 60Hz display caps the delivered rate near 60Hz whatever your hardware does. Chrome/Edge also expose sub-frame samples via getCoalescedEvents (roughly up to ~1kHz). The ceiling note stays under the tester permanently because this distinction is the whole point of the site.

Why does my 1000Hz gaming mouse only show ~60Hz?

Your display and the browser's frame loop are the ceiling, not your mouse. If your monitor refreshes at 60Hz, the page can only receive ~60 pointermove deliveries per second. The result you're seeing is honest — the page reports what it can observe, and nothing on the web can see past the frame loop. Run on a 120Hz+ display and the delivered rate rises with it; Chrome's sub-frame samples go further. To verify the hardware rate itself, use the methods in hardware-level measurement.

What are 'sub-frame samples' and why don't I have them?

Chrome and Edge implement PointerEvent.getCoalescedEvents(), which bundles the raw move samples the OS delivered between frames — often dozens per frame on a fast mouse. Firefox and Safari deliver one timestamp per frame only, so the tester reports 'not exposed' there. Either way, the delivered-event numbers are still valid for what they measure.

How do I check my mouse's true hardware polling rate?

Not in a browser. Real polling rate lives on the USB wire: use vendor software (Logitech G HUB, Razer Synapse show the configured rate), a raw-input desktop tool that bypasses the frame cap, or a USB protocol analyzer / Wireshark usbmon capture that counts actual HID reports per second. The hardware measurement guide covers each method.

What is a good polling rate for gaming?

500–1000Hz is the practical sweet spot for almost everyone — sub-millisecond report intervals with negligible CPU cost. 8000Hz mice exist and do reduce theoretical interval to 0.125ms, but the gain over 1000Hz is a fraction of a millisecond against real CPU/IRQ overhead and battery drain. The honest math is in 1000Hz vs 8000Hz.

Does the click test measure my click latency?

Not the latency you're thinking of. It measures clicks-per-second, your press duration (dwell time), and the time for the browser to deliver a click event to the page — usually under a few milliseconds. The hardware and OS share of click lag (switch, debounce, USB poll, compositor) is invisible to a web page; the input lag chain shows where those milliseconds actually live.

Is anything uploaded or tracked?

No. Every counter runs in this tab — event timestamps never leave the page, personal bests are stored in your browser's localStorage on this device only, and the site is static files with no endpoint that could receive test data. Details in the privacy policy.