Why I Split My Mouse Tester Into Its Own Site — And What "Low 5%" Actually Tells You About Your Mouse
After my last post about bypassing Chrome's event loop to measure polling rates, I got a question I couldn't stop thinking about:
"I have a 4000Hz Razer mouse. The test shows an average of 3,847Hz. Is that... good? Or is something wrong?"
The honest answer: the average doesn't tell you. And that gap between "what the spec says" and "what actually matters in-game" is exactly why I ended up building mousepollingratetest.com.
A quick backstory
My original hardware testing project lives at hardwaretest.org — a broader tool covering multiple peripherals. Mouse polling rate was just one feature among many there.
But after publishing those first posts, mouse polling rate questions kept coming: from competitive FPS players, from mechanical keyboard folks curious about crossover behavior, from people debugging USB dropouts. The topic was pulling more search traffic and user engagement than any other test on the site.
So I split it out. One domain, one job. And in the process of rebuilding it as a standalone tool, I had to confront a question I'd been sidestepping: what metrics actually matter?
The problem with average polling rate
Most browser-based polling rate testers show you one number: your average Hz. That number feels satisfying — you see "998 Hz" and think "close enough to 1000, we're good."
But imagine two mice:
- Mouse A: Every single report arrives at exactly 1ms intervals. Average: 1000Hz.
- Mouse B: Most reports arrive at 1ms, but every 20th report takes 3ms. Average: ~952Hz.
In a benchmark, Mouse B looks fine. In a fast-paced FPS, that 3ms dropout is the exact moment your crosshair skips. Your aim didn't fail — your hardware did.
This is why I built three additional metrics into mousepollingratetest.com that I think tell a more complete story.
The three metrics that actually matter
1. Low 5% (the "worst-case" rate)
Borrowed from storage benchmarking (where it's called P5 latency), Low 5% filters out your best 95% of samples and shows you the average of the slowest 5%.
In plain terms: it's what your mouse does when things go wrong. USB bus contention, CPU spikes, background processes — they all show up here.
Example from a real test session:
| Mouse | Average Hz | Low 5% Hz | Gap |
|---|---|---|---|
| Mouse A (1000Hz mode) | 987 | 961 | -26 |
| Mouse B (1000Hz mode) | 994 | 743 | -251 |
Mouse B looks better on average. Mouse B is the worse gaming mouse. The Low 5% exposed it.
2. Jitter (interval standard deviation)
Jitter measures how consistent your polling intervals are, expressed as the standard deviation of the time between events (in milliseconds).
A 1000Hz mouse should fire every 1.0ms. If your jitter is 0.08ms, your intervals are ranging roughly from 0.92ms to 1.08ms — tight, stable, good. If your jitter is 0.4ms, your mouse is swinging between 0.6ms and 1.4ms intervals — you'll feel that as cursor microstutter.
Stable mouse: [1.01, 0.99, 1.00, 1.02, 0.98] → jitter: 0.015ms ✅
Jittery mouse: [0.72, 1.31, 0.88, 1.45, 0.64] → jitter: 0.38ms ⚠️
Jitter under ~0.1ms is excellent. Above 0.3ms, you're likely to notice it in precision tasks.
3. Stability Score (and the Grade)
Stability is a composite percentage that combines sample count, jitter, and dropout rate into a single signal. The Grade (S / A / B / C) maps this to something easier to act on at a glance.
An "S" grade means your hardware + USB path + OS are all playing nicely together. A "C" means something is wrong — but the individual metrics above tell you what.
The Chrome Extension angle
One thing I hadn't anticipated: a lot of people want to check polling rate without navigating to a website mid-game. So I shipped a companion Chrome Extension — toolbar popup, zero permissions, 6-second test, same metrics.
It routes back to mousepollingratetest.com for the full histogram and Leaderboard, but the quick check is fully self-contained.
Zero-permission browser extensions are a nice constraint to build against: no storage, no network, everything computed and discarded in memory. The implementation is simpler than the main site in some ways, more limited in others (no IndexedDB for local result history, for example).
What 8000Hz actually looks like in a browser
For the 4000Hz/8000Hz crowd: browser tests will always underreport at extreme polling rates. Here's why.
When your mouse fires at 8000Hz, it's producing a report every 0.125ms. Chrome's pointermove event handler is bound by the browser's internal event processing loop — which, even with setPointerCapture and raw input hints, can't reliably resolve sub-0.5ms intervals without coalescing.
So if mousepollingratetest.com shows you 3,800Hz on an 8000Hz mouse, that's not a bug. That's the browser's effective delivery rate after OS scheduling and USB interrupt handling. For real-world comparison purposes (how does my mouse perform in Chrome?), that's actually the right number to care about.
Want the raw hardware number? You need a native app. Want to know how your mouse behaves in every browser-based game you play? You're already in the right place.
What I'd build next
If you've gotten this far, you might as well go test your mouse: mousepollingratetest.com
The Leaderboard is where things get interesting — seeing how different mice cluster by brand, polling mode, and USB configuration. A 2000Hz Logitech G Pro X Superlight 2 on a dedicated USB controller vs. a USB hub tells a very different stability story.
If you have a high-Hz mouse, I'd genuinely like to see your Low 5% numbers. Drop them in the comments.
Previously in this series: