A mouse does not announce a click. The host asks, on a fixed schedule, and the mouse answers with the current state of its buttons. That schedule is the polling rate, and at 1000 Hz the question comes once every millisecond.
The honest size of the effect
A press that closes just after a poll waits up to one full millisecond before anyone hears about it. Averaged across many presses, polling contributes about 0.5 ms of latency and up to 1 ms of jitter.
Put that next to the rest of the chain:
| Stage | Contribution |
|---|---|
| Contact debounce | 1–8 ms |
| OS input queue | 1–4 ms |
| Browser dispatch | 1–3 ms |
| USB poll | 0–1 ms |
Polling rate is the smallest term. It is also the one that gets marketed hardest, because it is the easiest to print on a box.
What it does to a CPM reading
Almost nothing. At 300 CPM the gap between presses is 200 milliseconds; a one-millisecond uncertainty is half a per cent of that. At 900 CPM the gap is 67 milliseconds and the same uncertainty is 1.5 per cent — still inside the variation between two of your own runs.
Where polling genuinely matters is pointer motion, not clicking. A 125 Hz mouse updates its position eight times less often, and that is visible as stepped cursor movement in a way that no click test will ever show you.
Whether 8000 Hz is worth anything
For click rate, no. Going from 1 ms to 0.125 ms removes 0.4 ms of average latency from a chain that still contains a 1–8 ms debounce guard you cannot remove. Spend the attention on the switch instead.