Our Testing Methodology
A transparent breakdown of how we measure polling rate, click speed, and reaction time — including the browser APIs we use, our calibration process, and validation against vendor software.
Why Methodology Transparency Matters
Many polling rate test sites display a Hz number without explaining how it was calculated. We believe gamers deserve to understand the measurement so they can interpret results and identify when something looks wrong. This document explains the exact algorithms behind every tool on PollingRateTestC.
Mouse Polling Rate Measurement
Browser APIs Used
The mouse polling rate test uses three core browser APIs:
pointermoveevents from the Pointer Events API — captures every cursor position update.event.getCoalescedEvents()— critical for detecting polling rates above 1000Hz. Modern browsers batch multiple high-frequency events into a singlepointermovedispatch. This method returns all batched events with their original timestamps.performance.now()— high-precision monotonic clock with sub-millisecond accuracy across all major browsers.
Algorithm
- Listen for
pointermoveevents on the test area. - For each event, call
getCoalescedEvents()to unpack high-frequency samples. - Store the
timeStampof every individual event in a rolling buffer (last 200 events). - Calculate inter-event intervals:
interval[i] = timestamp[i] - timestamp[i-1]. - Compute the average interval over the last 30 events.
- Convert to Hz:
Hz = 1000 / avgInterval. - Discard outliers (events with intervals < 0.1ms or > 50ms) to avoid timer noise.
Single events can be skewed by browser event loop jitter. Averaging 30 events smooths random noise without lagging real polling rate changes more than ~30ms behind reality.
Accuracy Limits
| Polling Rate | Expected Reading | Typical Variance |
|---|---|---|
| 125 Hz | 118 – 132 Hz | ±5% |
| 250 Hz | 238 – 263 Hz | ±5% |
| 500 Hz | 475 – 525 Hz | ±5% |
| 1000 Hz | 950 – 1050 Hz | ±5% |
| 2000 Hz | 1850 – 2100 Hz | ±7% |
| 4000 Hz | 3600 – 4200 Hz | ±10% |
| 8000 Hz | 6800 – 8200 Hz | ±15% |
Higher polling rates show wider variance because browser event coalescing becomes more aggressive — sometimes hundreds of mouse samples are bundled into a single dispatch. getCoalescedEvents() recovers most of these but not all in extreme cases.
Keyboard Polling Rate Measurement
Browser APIs Used
keydownandkeyupevents withevent.repeatfilteringperformance.now()for timing
Algorithm
Unlike mouse movement, keyboards don’t produce continuous events. We measure the interval between keydown events as the user rapidly presses keys (typically A, S, D, F in sequence). The maximum theoretical polling rate is detectable only when keys are pressed faster than the polling interval.
Steps:
- User types rapidly for 5–10 seconds in the test area.
- Record timestamp of every non-repeating
keydownevent. - Calculate minimum interval observed (this approximates polling rate).
- Display both peak (1 / min interval) and sustained (1 / median interval) Hz.
Browser keydown events have higher OS-level latency than mouse events. The maximum reliably detected keyboard polling rate is around 4000Hz, even on 8000Hz hardware. For absolute precision, use the manufacturer’s software.
Controller Polling Rate Measurement
Browser APIs Used
- The Gamepad API —
navigator.getGamepads() requestAnimationFramefor polling at display refresh rateperformance.now()for timing
Algorithm
The Gamepad API doesn’t push events — it requires manual polling. We sample at the highest rate available (typically 60–144 times per second matching display refresh rate) and detect input value changes.
- Poll
navigator.getGamepads()on every animation frame. - Detect axis or button state changes since the previous poll.
- Record timestamps of changes.
- Calculate input event rate from the change frequency.
Most controllers (Xbox, PlayStation, generic XInput) report at 125Hz internally over USB. Some premium controllers (Razer Wolverine V3 Pro, Scuf Reflex Pro) report at up to 1000Hz. Wireless controllers (Bluetooth) typically cap at 125Hz due to BT polling intervals.
CPS Test Methodology
Algorithm
- User selects a duration (1, 5, 10, 30, 60, or 100 seconds).
- First click starts the timer using
performance.now(). - Every subsequent click is timestamped.
- Timer ends at
startTime + duration. - CPS = total clicks / duration in seconds.
- CPM = CPS × 60.
Anti-Autoclicker Detection
While we can’t perfectly detect autoclickers (they exist in software space), our tool flags suspicious patterns:
- Clicks with intervals that vary by less than 1ms across the entire test (humans cannot maintain that precision)
- Click rates above 25 CPS sustained for more than 5 seconds (physically improbable)
- Perfectly mathematical intervals (10ms, 20ms, etc.)
Suspicious sessions still display a result, but they’re marked as “unverified” in our internal logs.
Reaction Time Methodology
Algorithm
- User clicks to start. State transitions to “waiting”.
- A random delay between 1500ms and 5000ms is set with
setTimeout. - When the delay completes, state transitions to “ready” — background flashes green. Timestamp captured.
- User clicks. Reaction time =
performance.now() - readyTimestamp. - Process repeats for 5 attempts. Final score is the average.
Sources of Measured Latency
Your displayed reaction time is not purely neurological — it includes:
| Source | Typical Delay | Note |
|---|---|---|
| Human neural reaction | 120 – 180ms | The actual reflex |
| Monitor refresh (60Hz) | 0 – 16.7ms | 0 – 4ms on 240Hz |
| Monitor pixel response | 1 – 5ms | “1ms GtG” is best case |
| Browser event loop | 1 – 8ms | Higher when CPU is busy |
| Mouse polling delay | 1 – 8ms | 1ms at 1000Hz, 8ms at 125Hz |
| USB controller scan | 0 – 1ms | Negligible on USB 3 |
So a 200ms measured reaction time typically reflects 170–180ms pure neurological reaction with 20–30ms of hardware/software stack latency.
Scroll Rate Methodology
Browser APIs Used
wheelevent withpassive: falseto prevent default scrolling- The
deltaYanddeltaXproperties for direction and magnitude
Algorithm
- Capture every
wheelevent timestamp. - Calculate events per second using a 1-second sliding window.
- Track peak, average, direction balance, and average delta value.
- Render a live chart of scroll rate over time.
Validation Against Vendor Software
Our measurements are validated against authoritative vendor sources:
- Razer Synapse 4 — polling rate readout, on-board memory inspection
- Logitech G HUB — report rate display, firmware-level setting verification
- Corsair iCUE — polling rate slider, hardware diagnostic mode
- SteelSeries GG — engine polling rate settings
- Wooting Wootility — for rapid trigger and analog keyboards
- HID Macros / Mouse Tester (third-party) — independent cross-check tools
Update History
- January 2026 — Added
getCoalescedEvents()support for accurate 4000–8000Hz measurement. - November 2025 — Improved keyboard test to filter
event.repeatphantom events. - September 2025 — Added controller test using Gamepad API with frame-locked polling.
- August 2025 — Initial launch with mouse polling rate test.
Questions or Corrections?
If you spot a methodology error or have suggestions for improving accuracy, please contact us. We respond to all technical feedback within 48 hours and credit contributors on this page.