🎮 Gamepad — Latency Test

This latency test is a browser-based estimate. It relies on the Gamepad API and the browser-provided gamepad.timestamp (when present) plus sampling logic to estimate the time between device-state updates and the page's processing. It does not measure absolute display/input latency (which requires external hardware such as photodiodes or high-speed cameras). Results will vary by controller, OS, browser, CPU load, USB vs Bluetooth, and power state. Use the results as comparative indicators (e.g., wired vs wireless, different browsers, or different controllers) rather than as an absolute hardware measurement.

Latency matters for competitive gaming and any interactive experience where control precision counts. This guide explains what latency is, what causes it, how this tool measures it, step-by-step testing methodologies, platform-specific advice, developer notes, and an extensive Pro Tips list. Each major section is boxed for readability.

Definition

Input latency (or input lag) is the delay between a user's physical input (pressing a button or moving a stick) and the time the system responds — typically expressed in milliseconds (ms). For a controller, latency includes the time for the controller to detect the press, transmit it to the host (via USB/Bluetooth), for the OS and browser to process it, and for the application to update visuals or behavior.

Why it matters

• Competitive gameplay: Lower latency improves reaction times and precision.
• Rhythm and timing games: Accurate input timing is critical for scoring.
• VR and motion-sensitive applications: Latency affects immersion and can cause discomfort.

Controller-side

• Sampling rate: How often the controller samples its own buttons / sensors.
• Wireless radios: Bluetooth introduces encoding/decoding and packetization delays.
• Power-saving modes: Wireless controllers reduce update frequency to save battery.

Transport & OS

• USB polling interval: HID over USB is polled at certain intervals; faster polling reduces latency.
• Bluetooth stack: OS Bluetooth stack may buffer or batch events.
• Driver layers: Device drivers and filtering can add small delays.

Browser & App

• Gamepad API polling: Browsers poll controllers at their own cadence; `gamepad.timestamp` often reflects when the browser updated the state.
• Event loop scheduling: JavaScript runs on the main thread; heavy CPU or rendering tasks can delay processing.
• Frame presentation: Visual update depends on requestAnimationFrame and display refresh rate (e.g., 60Hz → 16.67ms per frame).

gamepad.timestamp — browser-supplied time

When supported, gamepad.timestamp is updated by the browser/driver to indicate the moment the gamepad state changed. By computing performance.now() - gp.timestamp when detecting a pressed button, we estimate the time between the browser’s sample timestamp and the page processing time. This is a widely used method to estimate input-to-browser latency.

Polling cadence & jitter

Because the Gamepad API is polled, the tool also tracks the effective poll interval and jitter (variations in sampling timing). A slower or highly variable poll loop increases measurement noise — the tool shows poll interval to help interpret results.

Limitations

• If gp.timestamp is not implemented by the browser, the tool falls back to a heuristic that records the first detection time during the sample cycle — less accurate.
• The tool cannot measure display latency (screen response time) or the very first nanoseconds of hardware sensing inside the controller.
• Results are best used comparatively (compare modes, controllers, browsers), not as absolute ground truth.

Preparing

1. Prefer a wired USB connection for baseline testing (removes Bluetooth variability).
2. Close heavy background apps to reduce CPU contention and scheduling delays.
3. Use the sampleInterval value around 8–16ms for best results (16ms is typical for 60Hz polling).

Running the Test

1. Click Detect Controller and confirm your device is shown.
2. Select the button you want to test (A / Cross is common).
3. Click Start Test.
4. Press the chosen button at a comfortable cadence — don’t mash. Aim for 1–2 presses per second to get independent samples.
5. Collect at least 30–100 samples for meaningful statistics.
6. Click Stop Test and review Min/Avg/Max latency.

Interpreting the Numbers

• Sub-16ms: excellent; implies very low browser-side detection delay (often seen with USB + high poll rate).
• ~16–40ms: common for many setups with 60Hz polling and some buffer overhead.
• 40–100ms or higher: indicates Bluetooth delays, OS driver buffering, or heavy CPU load.

Windows

• Wired Xbox controllers usually give the best results in Chromium-based browsers.
• Disable USB power-saving on hubs if you see intermittent spikes.

macOS

• Gamepad support is improving but may show higher latency in some browsers; test multiple browsers.

Android

• Bluetooth latency varies by device and Android version; USB OTG typically reduces latency.

Linux

• Kernel input subsystems and udev rules affect behavior; Chromium-based browsers on modern kernels often give good results.

High Average Latency

1. Use wired USB and retest — if latency drops significantly, Bluetooth was the issue.
2. Close background apps (especially browsers with many tabs, virtualization, or recording software).
3. Try a different browser — Chrome/Edge are recommended for consistent Gamepad API behavior.

Large Jitter / Spikes

1. Increase sampleInterval slightly to stabilize readings (but note this reduces temporal resolution).
2. Check system power settings — CPU throttling can cause uneven scheduling.
3. Run the test multiple times and compare medians instead of raw averages to reduce outlier influence.

No Timestamp Support

If gp.timestamp is missing, the tool falls back to first-detection heuristics. In that case, compare different browsers or use wired mode to minimize unknowns. You can still get comparative results (e.g., Browser A vs Browser B) even without timestamps.