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 can fluctuate slightly frame-to-frame even on a stationary stick. A very small threshold can cause sensor jitter or stick drift to be counted as repeated input changes, which can skew the observed interval downward. GPADLAB therefore uses 0.02 as an implementation threshold to reduce noise while remaining responsive to deliberate stick movement. It is a practical change-detection threshold, not a hardware calibration value.

In this inter-event method, a delta above 500ms usually reflects a long pause between user-generated state changes rather than a dense sequence of inputs suitable for the calculation. Including those pauses would make the average depend heavily on how continuously the user moved the sticks or pressed buttons. GPADLAB therefore excludes deltas above 500ms from this calculation; the cutoff is an input-sampling rule, not a claim about the maximum possible hardware latency of a controller.

First-party controller latency figures, when published, may be measured with hardware setups or definitions that are not directly comparable to this browser-based method. GPADLAB results are most useful as a comparative signal when the same host, browser, connection conditions, test procedure, and repeated runs are used. A difference between two single runs should not automatically be treated as a hardware-level latency difference because requestAnimationFrame cadence, browser scheduling, user input pattern, and system load can affect the observed values.

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.