How to Measure Input Latency in Your Game

Players complain that your game “feels floaty” or “inputs feel delayed,” and you cannot see it in the profiler. Input latency is invisible to traditional CPU and GPU measurements because it is the sum of many small delays across many systems. It is also the one metric that most directly affects how a game feels. Here is how to measure it without expensive hardware.

What Latency Is Made Of

End-to-end input latency is the time from “player physically presses a button” to “player sees the result on screen.” It includes:

• Hardware input delay: controller polling rate, USB polling (1–8 ms).
• OS input buffering: driver queues (0–16 ms).
• Game loop delay: input is sampled once per frame, so up to one frame of wait (16 ms at 60 fps).
• Simulation and render: the game processes the input and produces a new frame (1–33 ms).
• Presentation delay: triple buffering, v-sync, driver queueing (16–50 ms).
• Display response: LCD pixel transition (3–20 ms).

Total: 50 ms on a fast PC gaming setup, 100–150 ms on a console, 200+ ms on a poorly-tuned system. 40 ms is the threshold below which most players cannot perceive differences. Above that, every 20 ms is a clearly noticeable step.

Method 1: High-Speed Camera

Modern phones shoot 240 fps slow motion. At 240 fps, each frame is 4.17 ms. Film yourself pressing a button clearly in frame, with the screen also in frame, and count frames between the press and the response.

Setup:

1. Put your phone on a tripod at a 45-degree angle so both your hand and the screen are visible.
2. Open the slow motion camera mode and set to 240 fps.
3. Bring up the game in a state where pressing a button has an obvious visual response (jumping character, flash effect, crosshair move).
4. Start recording. Press the button. Stop recording.
5. Scrub through the video frame by frame in a video editor or a tool like ffmpeg -vf showframes.

Count the frame where your finger is visibly depressing the button, and the frame where the response first appears. Subtract and multiply by 4.17 ms. Repeat 5–10 times and average.

Accuracy: ±8 ms (two frame edges). Good enough for meaningful comparisons between builds.

Method 2: Software Loop Test

A software test is less accurate end-to-end (it does not include display response) but useful for CI because it runs unattended.

public class LatencyTest : MonoBehaviour
{
    private float _pressedAt;
    private float _respondedAt;
    private bool _pressPending;

    void Update()
    {
        if (_pressPending && _respondedAt == 0f)
        {
            // Measure when our virtual input produces a response
            if (player.transform.position.y > _initialY + 0.1f)
            {
                _respondedAt = Time.realtimeSinceStartup;
                float latencyMs = (_respondedAt - _pressedAt) * 1000f;
                Debug.Log($"Latency: {latencyMs:F2} ms");
                _pressPending = false;
            }
        }
    }

    public void SimulatePress()
    {
        _pressedAt = Time.realtimeSinceStartup;
        _pressPending = true;
        InputSim.InjectKeyDown(KeyCode.Space);
    }
}

Run this in CI on a fixed hardware profile. Record the result as a metric. Fail the build if it regresses by more than 20% compared to the last green build.

Method 3: LDAT and Specialized Hardware

For professional-grade measurement, NVIDIA’s LDAT device (or the similar hardware sold by retail sites) physically triggers a mouse click and measures when a specific pixel region changes color. Accuracy is sub-millisecond. Overkill for most indie games but invaluable for competitive shooter studios.

An LDAT-equivalent setup can be built with an Arduino, a photoresistor, and a USB HID emulator for under $50. The fiddliness of wiring it is usually not worth it unless you are testing latency as a core feature.

Common Latency Bugs

Once you can measure latency, you can fix it. Common causes of excessive latency:

• Double buffering and triple buffering. Each extra buffer adds one frame of delay. Use the minimum that avoids tearing for your target platform.
• Vertical sync. V-sync caps latency at one frame’s worth of wait. Disable for competitive games, or use fast sync / variable refresh.
• Input sampled at the wrong place in the frame. Sampling at the start of Update means input can be up to one frame stale by render. Sample as late as possible, ideally just before simulation.
• Frame pacing at the driver. NVIDIA Reflex and AMD Anti-Lag reduce driver queue latency — expose them as settings.
• Lock-step animations. An animation that queues up and plays for five frames before showing movement adds five frames of latency.
• Netcode prediction disabled. Multiplayer games without client-side prediction see full round-trip time before the local action is visible.

Setting a Latency Budget

Decide what latency is acceptable for your game and hold to it.

• Competitive shooter, fighting game: < 40 ms end-to-end. Target 25 ms.
• Action game, platformer: 50–70 ms.
• Strategy, simulation, turn-based: 100 ms+ is fine.

Measure every release. Any drift is a regression.

“Players cannot tell you why your game feels bad — they just feel it. Input latency is the most common reason a game feels sluggish, and the cheapest to fix once you can measure it.”

Related Resources

For input lag in action games specifically, see debugging input lag in action games. For frame rate profiling, see how to profile frame rate drops in Unity. For controller latency differences, see how to test controller rumble and haptics across platforms.

A 240 fps phone camera is the cheapest real latency test available. Every indie studio should have one on a tripod pointed at a monitor during QA week.