How We Measure Input Lag

Two reasons. First, that equipment costs $500+ and requires a physical setup on every controller — not feasible for a browser-based tool anyone can use in ten seconds. Second, hardware-instrumented tests measure a fundamentally different quantity (thumb-to-photon) that includes display latency, which varies by monitor. Our measurement isolates a component of the input chain — the polling-loop delta — that is comparable across sessions and controllers on the same host machine. Different tool, different job.

The 10-second window balances two competing needs. Long enough to gather 200-500 valid deltas on a controller being actively worked (dense input yields dense samples); short enough that users will actually complete the test without getting bored and stopping early. In testing, extending the window to 30 seconds changed the reported mean by less than 5% on stable controllers — the sample size is already large enough for statistical significance at 10 seconds.

Below 30 samples, the standard error of the mean is large enough that reporting a specific latency number would be misleading precision. If the tester ends the window with under 30 valid deltas, it silently discards the run and returns the user to a ready state — a signal to redo the test with more continuous input. This threshold matches the sampleCount < 30 check in scoreLatency() from the Controller Health Score scoring library.

The Gamepad API reports floating-point axis values that fluctuate slightly frame-to-frame even on a stationary stick. A threshold of 0 or 0.001 would generate hundreds of false events per second on any controller with even minor drift, producing an artificially low reported latency that measures noise instead of input. The 0.02 threshold is empirically tuned to filter out sensor jitter on all major controllers we've tested while remaining sensitive enough to catch deliberate stick movement.

A delta over 500ms almost always represents a pause in user input — someone stopped moving, then started again — rather than measurement latency. Including those in the average would push the reported number up dramatically based on how consistently the user provided input, not on how the controller performs. The 500ms cutoff is well above any realistic input lag on any controller (a Bluetooth controller with 100ms latency reports deltas around 100ms, not 500ms), so we're not cutting off real data.

First-party controller specs typically don't publish end-to-end latency numbers, and when they do (for example, DualSense Edge marketing on wired-mode latency), those numbers are measured with proprietary hardware setups that aren't directly comparable to our browser-based measurement. We recommend using our numbers to compare controllers against each other on the same host, not against manufacturer specs. A DualSense measuring 8ms here versus an Xbox controller measuring 6ms is a real relative difference; both being lower than a manufacturer-published 4ms wired spec doesn't mean either measurement is wrong.

Yes — this is the most important caveat. Chrome, Firefox, and Safari all throttle background tabs' requestAnimationFrame callbacks to 1fps or lower. Running the test in a background tab will produce meaningless results. The tester requires an active, foreground tab. We do not currently gate the test on document visibility, but adding that check is on the polish backlog. In the meantime, run the test on the active tab and don't switch tabs during the 10-second window.