Rubberbanding
Rubberbanding is when a player’s character appears to snap back to a previous position mid-movement. It happens when the server’s authoritative state disagrees with what the client predicted, and the correction is large enough to be visible.
What causes rubberbanding
- High latency — The longer the round trip between client and server, the more the client has to predict. Larger predictions mean larger corrections when they’re wrong.
- Packet loss — Missing packets mean the server doesn’t receive the client’s inputs on time. The server simulates without them, diverging from the client’s prediction.
- Server tick rate drops — If the server can’t maintain its tick rate (e.g. dropping from 64 Hz to 20 Hz due to CPU contention), updates arrive less frequently and the client’s predictions drift further between corrections.
- Noisy neighbours — On shared cloud hardware, CPU contention from other tenants can cause the game server’s tick rate to stutter, producing intermittent rubberbanding that’s hard to diagnose.
Infrastructure’s role
Rubberbanding is often blamed on “bad netcode” but frequently the root cause is infrastructure: a server running on overloaded hardware, placed too far from players, or experiencing packet loss due to poor network routing. Consistent bare metal performance, low-latency placement, and game-aware DDoS protection eliminate the infrastructure-side causes.
The game code side — client-side prediction, reconciliation, and interpolation — is the developer’s responsibility. The infrastructure side — consistent tick timing, low latency, and reliable networking — is the platform’s.