Technical Documentation

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:

  • pointermove events 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 single pointermove dispatch. 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

  1. Listen for pointermove events on the test area.
  2. For each event, call getCoalescedEvents() to unpack high-frequency samples.
  3. Store the timeStamp of every individual event in a rolling buffer (last 200 events).
  4. Calculate inter-event intervals: interval[i] = timestamp[i] - timestamp[i-1].
  5. Compute the average interval over the last 30 events.
  6. Convert to Hz: Hz = 1000 / avgInterval.
  7. Discard outliers (events with intervals < 0.1ms or > 50ms) to avoid timer noise.
Why a rolling 30-event window?

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

  • keydown and keyup events with event.repeat filtering
  • performance.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:

  1. User types rapidly for 5–10 seconds in the test area.
  2. Record timestamp of every non-repeating keydown event.
  3. Calculate minimum interval observed (this approximates polling rate).
  4. Display both peak (1 / min interval) and sustained (1 / median interval) Hz.
Keyboard measurement limitations

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 APInavigator.getGamepads()
  • requestAnimationFrame for polling at display refresh rate
  • performance.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.

  1. Poll navigator.getGamepads() on every animation frame.
  2. Detect axis or button state changes since the previous poll.
  3. Record timestamps of changes.
  4. 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

  1. User selects a duration (1, 5, 10, 30, 60, or 100 seconds).
  2. First click starts the timer using performance.now().
  3. Every subsequent click is timestamped.
  4. Timer ends at startTime + duration.
  5. CPS = total clicks / duration in seconds.
  6. 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

  1. User clicks to start. State transitions to “waiting”.
  2. A random delay between 1500ms and 5000ms is set with setTimeout.
  3. When the delay completes, state transitions to “ready” — background flashes green. Timestamp captured.
  4. User clicks. Reaction time = performance.now() - readyTimestamp.
  5. 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

  • wheel event with passive: false to prevent default scrolling
  • The deltaY and deltaX properties for direction and magnitude

Algorithm

  1. Capture every wheel event timestamp.
  2. Calculate events per second using a 1-second sliding window.
  3. Track peak, average, direction balance, and average delta value.
  4. 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.repeat phantom 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.