Input Lag vs FPS — How Frame Rate Affects Latency

Frame Delivery Latency

Games sample input state at the beginning of each frame. If you click between two consecutive frame reads, your click isn't registered until the next sample — introducing a wait of 0 to one full frame period. This is called frame delivery latency or sampling latency.

This delay is random within [0, frame_period]. On average, you wait half a frame period. At 60 FPS, that's an average of 8.3 ms added purely from frame sampling. At 240 FPS, it drops to 2.1 ms average.

The Math

Frame period = 1000 ms ÷ FPS. Average sampling delay = frame_period ÷ 2.

What Frame Rate Doesn't Fix

Even at uncapped framerates, you still have: peripheral polling latency (0–8 ms at 125 Hz), OS scheduler delay (varies with timer resolution), GPU render queue depth (1–3 frames at default settings), and display processing delay (1–4 ms). A 400 FPS game with V-Sync enabled adds back the full frame-wait penalty anyway.

The most common mistake is targeting extreme framerates while leaving V-Sync on or GPU pre-rendered frames at 3. These settings undo the sampling latency gains entirely.

Diminishing Returns

The gains from increasing frame rate follow a curve of diminishing returns. 60→144 FPS is a large jump — 4 ms saved. 144→240 FPS is noticeable — 2 ms saved. 240→360 FPS is detectable in controlled tests but not perceptually significant for most players.

The more impactful optimization is removing latency from other parts of the chain — particularly OS-level settings and GPU driver configuration — before chasing the last few FPS.

Frequently Asked Questions