The Delay You Feel Is a Chain, Not a Number

Total system latency is the time between your physical input and the resulting photons hitting your eyes — often called click-to-photon. Your network ping is one link in that chain, and frequently not the largest one. A mouse click passes through polling, USB transport, the OS, the game engine, the render queue, the GPU, the display's own processing, and finally the panel's refresh interval. At 60 Hz a single frame is about 16.7 ms, so two or three frames of buffering can cost more than a decent ping to a nearby server.

The Full Chain, Link by Link

Each stage below adds delay independently. The magnitudes are typical ranges drawn from how the hardware and software work, not measurements of your specific setup — treat them as an ordering guide rather than a spec sheet.

Stage	What happens	Typical magnitude band	What you control
Input device polling	The mouse or controller samples its sensor and waits for its next report slot	Well under 1 ms at 1000 Hz, up to roughly 8 ms at 125 Hz	Polling rate setting, device choice
Transport to the PC	USB or wireless link carries the report	Sub-millisecond wired; low but variable on wireless, worse on Bluetooth than on a dedicated 2.4 GHz dongle	Wired versus dongle versus Bluetooth
OS input handling	Driver and OS deliver the event to the game process	Typically low single-digit milliseconds	Background load, driver quality
Game simulation	The engine reads input at the start of a frame and updates the world	One frame time — 16.7 ms at 60 fps, 6.9 ms at 144 fps, 4.2 ms at 240 fps	Frame rate, settings, CPU
Render queue	Frames wait in a queue before the GPU starts on them	Zero to several frame times, depending on queue depth and GPU load	Low-latency modes, frame cap, avoiding a GPU-bound state
GPU render and present	The GPU draws the frame and hands it to the compositor or scanout	Roughly one frame time when GPU-bound	Graphics settings, resolution, upscaling
Display transport and processing	The panel receives the frame and applies its internal processing	Near zero on a good monitor in game mode; tens of milliseconds on a TV with post-processing enabled	Game mode, disabling motion smoothing
Refresh interval and pixel response	The panel waits for its next refresh and the pixels physically change	Half a refresh interval on average, plus panel response time	Refresh rate, panel technology
Network round trip	Your action reaches the server and the result comes back	Whatever your ping is — often 10 to 60 ms to a nearby region	Route, connection type, server choice
Server tick	The server processes your input on its next simulation step	Up to one tick interval; roughly 50 ms on a 20-tick server, about 8 ms at 128 tick	Nothing, beyond choosing games and servers

Add the local links together and even a well-configured 144 Hz system carries a meaningful local budget before the network is involved at all. On a 60 Hz console setup connected to a TV with processing enabled, the local chain can dwarf a 30 ms ping.

Why Frame Rate Cuts Latency Even at a Fixed Refresh Rate

This is the part most guides get wrong. People assume that if your monitor refreshes 60 times per second, rendering more than 60 frames per second is wasted. For image smoothness, largely true. For latency, false.

The game samples your input at the start of each simulation step. At 60 fps, an input that arrives just after a step begins waits nearly 16.7 ms before the engine even notices it. At 200 fps the same input waits at most 5 ms. The frame that finally gets displayed is also fresher — it was rendered from a world state captured closer to the moment of scanout. So on a 60 Hz panel, running at 200 fps still reduces click-to-photon latency, even though you only see 60 of those frames. That is precisely why competitive players uncap frame rates on modest monitors.

The trade-off is the render queue. When the GPU is saturated, frames pile up waiting for it, and each queued frame is a frame of added age. That is the mechanism behind the classic advice to avoid being fully GPU-bound: a system pinned at 99% GPU usage often feels less responsive than the same system capped slightly below its maximum.

What Low-Latency and Anti-Lag Modes Actually Do

The driver-level features from both major GPU vendors, and the equivalent options exposed in some engines, share one core mechanism: they limit how many frames the CPU is allowed to run ahead of the GPU. Instead of the CPU queuing several frames of work in advance, it is paced to submit a frame just in time for the GPU to start on it.

They help most when you are GPU-bound. If the GPU is the bottleneck, the queue is where your latency is hiding, and draining it is a direct win.
They help little when you are CPU-bound. With the GPU idle waiting for work, there is no queue to trim.
They are not a substitute for frame rate. Trimming the queue removes buffered frames; it does not shorten the frame time itself.
A well-chosen frame cap does something similar. Capping a few frames below your maximum keeps the GPU from saturating and stops the queue from filling, which is why a cap can feel snappier than uncapped play in GPU-heavy titles.

V-Sync is the opposite case. Traditional V-Sync holds finished frames until the next refresh boundary and can allow multiple frames of buffering, adding a substantial and very noticeable delay. Variable refresh rate — G-Sync or FreeSync — avoids most of that by moving the refresh boundary to the frame instead, which is why VRR with a cap slightly under the panel maximum is the standard low-latency recommendation.

Where to Spend Your Effort First

Ranked by typical payoff per unit of effort and money:

Turn off display post-processing. If you play on a TV, enabling game mode and disabling motion smoothing can remove more delay than every network optimisation in this article combined. This is free and takes a minute.
Raise your frame rate, then stabilise it. Lower a couple of expensive settings until you are comfortably above your refresh rate. Consistent frame time matters as much as the average — a game that averages 120 fps but stutters to 40 feels worse than a locked 90.
Fix an unstable connection before chasing a lower one. Variance costs more than a slightly higher average. A steady 45 ms beats 25 ms that swings to 120, for the same reason detailed in our comparison of jitter versus ping.
Get your input path wired and fast. Use a 1000 Hz polling rate, prefer a cable or a dedicated wireless dongle over Bluetooth, and keep background CPU load low so input events are not delayed by contention.
Then reduce ping. Once the local chain is clean, network improvements become the visible remainder — pick the nearest region, get on a cable, and work through the steps in our guide to lowering ping.

Why the Server Matters as Much as Your Machine

The chain does not end at your router. The server runs its own simulation at a fixed tick rate, and your input waits for the next tick before it is processed. A 20-tick server adds up to 50 ms of pure waiting that no hardware upgrade touches; a 128-tick server adds about 8 ms. This is why identical ping figures feel different across games, a topic we unpack in server tick rate explained.

Netcode design then decides how much of the total chain you actually perceive. Client-side prediction hides your own movement latency by simulating locally and correcting later. Lag compensation rewinds the server's view of the world to what you saw when you fired. Interpolation smooths other players' motion between updates at the cost of showing them slightly in the past. Good implementations mask a lot; none of them eliminate the underlying delay.

How to Reason About Your Own Setup

Start by separating the local chain from the network chain. Play offline or in a practice range and pay attention to how the crosshair tracks your hand. If aiming feels heavy and smeared with no server involved, the delay is local — display, frame rate, or input path — and no amount of routing work will change it. If offline feels crisp and online feels mushy, the network and server side own the difference.

From there, measure what you can. Frame time is visible in any overlay. Network latency you can check in seconds with a browser latency test, keeping in mind that it measures warm HTTPS round trips to nearby cloud endpoints — a real-world proxy rather than in-game packets, but consistent enough for before-and-after comparison. Then judge the result against realistic goals rather than perfection: our breakdown of what counts as good ping for gaming sets the thresholds that actually matter per genre. Below about 20 ms of network latency, further network work returns almost nothing, and every remaining millisecond you can win lives in the local chain.