Lag Compensation
Lag compensation is the technique servers use to fairly evaluate player actions despite network delay — rewinding game state to the moment a player fired, rather than judging their shot against where enemies are right now.
Without it, every player would need a perfect connection to have their inputs register correctly. With it, a player on 80ms latency can still land a shot they aimed accurately, because the server accounts for the time their packet spent in transit.
The problem it solves
Here is what happens without lag compensation. A player aims at an enemy and presses fire. That input travels from their machine to the server — say 50ms away. In those 50ms, the enemy has moved. The server receives the shot, checks current positions, and sees the shot missed. From the server’s perspective it did miss. From the shooter’s perspective, they hit.
This mismatch gets worse as latency increases. At 100ms, the enemy has moved two full server ticks (at 20-tick) or twelve ticks (at 128-tick) by the time the shot arrives. Without compensation, high-latency players are structurally disadvantaged through no fault of their own.
How it works
The server maintains a short history of game state — typically the last 1–2 seconds of positions for all entities. When a shot input arrives, the server looks at the timestamp on the packet and rewinds its world state to match what the shooter saw when they fired. It then evaluates the shot against that historical snapshot rather than the present state.
If the shot would have hit in that rewind, it registers as a hit. The server then returns to the current state and applies the damage.
The tradeoff: peeker’s advantage
Lag compensation creates a well-known asymmetry: the player who initiates an action (the “peeker”) benefits from it more than the player being peeked. When a player rounds a corner, their client shows them the enemy a fraction of a second before the enemy’s client shows them being peeked. The peeker fires first, the server validates the shot against the rewound state, and the hit registers — even though the defending player never saw the attack coming.
This is not a bug. It is an unavoidable consequence of giving high-latency players fair treatment. Games tune how far back they rewind, how much smoothing they apply, and how they present movement to minimise the feel of peeker’s advantage without eliminating lag compensation entirely.
Lag compensation and server infrastructure
The accuracy of lag compensation depends on tick rate and consistent server performance. A server running at 128 ticks stores positions every 7.8ms — small enough windows that rewind is precise. A server running at 20 ticks stores positions every 50ms — large enough that the interpolated rewind position may not match what the shooter actually saw.
Server hardware matters too. Lag compensation running on a machine under load — CPU-throttled, shared with other tenants — produces inconsistent tick timing and therefore inconsistent hit registration. That is why competitive games on dedicated bare-metal servers feel different from the same game running on overloaded shared infrastructure.
See also: Netcode · Tick Rate · Client-Side Prediction · Authoritative Server