WebSocket Lag and Why Your .io Game Sometimes Feels Off

Look, Slither Battle is my most-played game on this site (a hundred-plus hours and counting), and one thing that experienced .io players develop is a sixth sense for when the server is being slow. The game feels fine for ten minutes, then a worm seems to teleport through your body and you die without an obvious reason. The frustration is real. The cause is usually not what players assume. This post is the technical explanation of why that happens, because it took me embarrassingly long to understand it and I want to save other players the same confusion.

Im going to do this without getting too deep into networking jargon because I want it accessible to players, not just developers. The summary is that real-time multiplayer in browser uses WebSockets, that WebSockets have specific failure modes, and that those failure modes manifest as a few distinct kinds of weird gameplay moments. Understanding which weird moment youre seeing helps you stop blaming the game when its actually the connection.

What WebSocket actually is

WebSocket is the protocol that browsers use to maintain a persistent connection to a server. Unlike the standard HTTP request-response cycle (where the client asks and the server answers, one round-trip at a time), WebSocket keeps the connection open so the server can push messages to the client immediately when something happens. For real-time games this is essential: an Agar.io style arena has hundreds of position updates per second flowing between server and clients.

The protocol itself is fast in the abstract sense. Messages travel at the speed of the underlying internet connection. But fast doesnt mean instant. Each message takes physical time to travel from server to client, processing time at each end, and queue time when the network is busy. On a typical home broadband connection in 2026, a WebSocket round-trip is somewhere between 30 and 100 milliseconds for most regions. Thats the baseline.

Where the lag actually happens

Three categories of WebSocket delay matter for gameplay. First is network latency, the physical travel time of a message. This is mostly a function of geographic distance from you to the server, plus how congested the route is. Players in North America connecting to a server in Europe routinely see 120 to 180 milliseconds of latency. Players on the same continent as their server see 30 to 60.

Second is server processing time. The .io server has to receive your position update, compute the consequences (did your worm hit anyone, did you eat any food, what does everyone need to know), and send out the updated game state to everyone in the match. On a well-engineered server this is in the single-digit milliseconds. On a stressed server it can balloon to 50 milliseconds or more, which is enough to make individual movements feel sticky.

Third is client buffering. Your browser may buffer incoming WebSocket messages before delivering them to the games JavaScript code. This depends on browser, operating system, and how busy your machine is. Buffering tends to be small (a few milliseconds) but it accumulates with the other delays.

Total delay is the sum. On a good day with a nearby server and an idle network, you might be seeing 40 to 60 milliseconds of total round-trip delay. On a bad day with a distant server, congested home network, and a busy machine, you can see 200 milliseconds or more. The difference is the gap between the game feels responsive and the game feels broken.

How games hide lag from you

A well-designed .io game uses several techniques to make the lag less visible. Client-side prediction is the most important one. Your client doesnt wait for the server to confirm your movement; it shows your worm moving immediately, based on your input, and reconciles with the servers authoritative position when the response arrives. If the predictions match what the server says, you see smooth motion. If they dont match (because something happened on the server that the client didnt predict), the client snaps your position to the corrected location.

Interpolation between updates is the other key trick. The server sends position updates at maybe 20 times per second. Your screen redraws at 60 times per second. The client interpolates the missing frames smoothly so you see continuous motion rather than jerky updates. This works well as long as the updates arrive on time.

Reason you dont normally notice the lag is that these techniques mask it effectively. The reason you do notice when something goes wrong is that the masking breaks down when the underlying delays exceed what the algorithms can compensate for.

What the specific symptoms tell you

If a worm appears to suddenly teleport, thats a prediction reconciliation. Your client guessed wrong about where the other player would be, and when the truth arrived the client snapped them to the correct position. This usually happens when the other player accelerated or turned more than the client expected.

If your own worm seems to rubber-band (move forward, jump backward, move forward again), thats a server correction. The server overruled your clients predicted position because the actual game state didnt match. Common cause is packet loss between you and the server.

If the whole game seems to freeze for a fraction of a second, thats either a server hiccup or a network gap on your end. You cant usually tell which from inside the game, but if it happens repeatedly its worth checking your own connection before blaming the server.

If you die without seeing what hit you, the kill-state arrived before the visual update that would have shown the killer. This is a buffering-and-priority issue on the server side, and its the symptom most likely to feel unfair because there was no way to react.

What you can do about it

Honestly, most of the WebSocket delay is not under your control. Server choice, server load, and network conditions are mostly external. Three things you can do that help.

Pick a server in your geographic region if the game offers options. The best .io implementations show server ping when you load the lobby. A 40-millisecond ping plays meaningfully better than a 150-millisecond ping.

Close other tabs and applications that are using network bandwidth. Your home internet bandwidth is shared. A streaming-video tab in the background can cause noticeable game lag.

If your wifi is unreliable, try wired ethernet. Wifi adds 5 to 20 milliseconds of latency on a good day and much more on a bad one. Ethernet is the most consistent. I do my serious Slither Battle runs on ethernet for this reason.

The bigger picture

WebSocket protocol is good. Modern browser implementations are mature. The infrastructure is there. The reason real-time multiplayer games still feel weird sometimes is that the lag is a real physical phenomenon and the masking techniques can only do so much. When you notice lag, youre usually noticing the failure of the masking rather than the lag itself. Knowing this doesnt make the moment less frustrating but it does help you stop blaming the games design for what is actually a connection problem.

Best .io games on this site are decent at handling the masking when conditions are good. The ones that I rate highest (Slither Battle, Paper Territory, Hexa Wars) tend to fail more gracefully under bad conditions than the lower-rated ones. Thats worth knowing when youre picking which game to commit a half-hour to.