"Laggy" gets used for four different problems with four different causes, which is why the advice you find is usually useless. Let us separate them.
One tick is 17 milliseconds
Haxball's host advances the simulation 60 times a second. One tick is therefore about 16.7 ms, and that gives us a ruler for translating network delay into game terms.
When you press a key, the input travels to the host, the host applies it on some tick, and the result travels back to you. Your round trip is how far in the past the world you are looking at actually is:
| Round trip | In ticks | What it feels like |
|---|---|---|
| 20 ms | ~1 tick | Immediate. The ball goes where you aimed; saves count. |
| 50 ms | ~3 ticks | Fine. You will not notice it in a pub game. |
| 80 ms | ~5 ticks | Playable, but the edge is gone. Tight passes get loose. |
| 120 ms | ~7 ticks | Rough. The ball teleports on correction, blocks arrive late. |
| 200 ms | ~12 ticks | You are playing a different game from the person next to the host. |
Seven ticks does not sound like much. But a Haxball shot is decided within a handful of ticks of the ball reaching your disc — so seven ticks is the difference between a clean strike and a scuffed one, every single time.
It is almost never your bandwidth
Haxball is one of the lightest multiplayer games in existence. It sends disc positions, not video. Upgrading your internet package will not make a distant room feel closer, because distance and routing set your delay, not throughput.
This is the single most common misdiagnosis. People buy faster connections, get identical lag, and conclude Haxball is broken. Haxball is fine — the room is just far away.
A quick test: join a room hosted near you and one hosted on another continent, back to back. Same computer, same connection, completely different game. That difference is entirely the host's location.
Jitter is worse than ping
Ping is how long the round trip takes. Jitter is how much that varies. They are not the same problem and jitter is the crueller one.
Humans are remarkably good at compensating for a constant delay. Give someone a steady 70 ms and within a few minutes they are leading their passes correctly without thinking about it. Give them a ping that swings between 30 and 120 ms and they can never calibrate, because the amount to compensate for changes faster than they can learn it.
This is why a stable 70 ms room often plays better than an unstable 45 ms one — and why a provider quoting only a best-case number is not telling you what you need to know. Ask for the median over a burst, not the fastest packet.
Packet loss: the teleporting ball
When updates go missing, your client keeps predicting from the last thing it knew. When the next real update arrives and disagrees, the world snaps to the truth. That snap is the ball teleporting — the specific complaint people describe as "rubber-banding".
Loss usually comes from congestion somewhere on the path: a saturated home upload, overloaded Wi-Fi, an ISP peering point at peak hour, or a route that goes somewhere silly. A wired connection fixes a surprising amount of it.
Which half is yours
| Symptom | Owner | What actually helps |
|---|---|---|
| Everyone in the room lags equally | The host | The room is badly located or the host machine is overloaded. Only the host can fix it. |
| Only you lag, everyone else is fine | You | Go wired, stop background uploads, close what is saturating your line, check whether anything else on the network is streaming. |
| Fine for an hour, then bad every evening | Your ISP | Peak-hour congestion on your route. Little you can do beyond raising it with them. |
| Smooth, but your inputs feel late | The host's distance | Nothing local. This is pure round-trip time — the room needs to be closer. |
| Ball jumps intermittently, ping looks fine | Loss or jitter | Wired connection first; then look at the path, not the average ping. |
Notice how many rows say "the host". If you run a community, most of your members' lag is a decision you made — where you put the room — and not something they can fix from their end.
Measure it properly
Three rules for getting a number that means something:
- Measure the transport the game uses. Haxball moves its data over WebRTC. An ICMP ping or an HTTP request can take a different route with different treatment, so it can be optimistic. Test the real path.
- Take the median of a burst, throw away the warm-ups. The first exchange pays for connection setup, and one unlucky packet should not define your result any more than one lucky one should.
- Measure from where your players are. If your community is Brazilian and you are in Lisbon, your own ping is the wrong number entirely. Get two or three members in different places to run it.
A ping test that follows those rules
Real WebRTC data channels to every HaxHost location, warm-ups discarded, median reported, and every location ranked for you — from your browser, in about three seconds.
Run the ping testIf you host: what you control
- Location, location, location. The single biggest lever, and the only one that helps every player at once. Put the room where the bulk of your community is, not where you are and not where the server is cheapest.
- Do not overload the host. The room has to advance the simulation 60 times a second. If it is sharing a machine with too much else, ticks arrive late and every player feels it as stutter — regardless of their ping.
- Keep your tick handlers cheap. A script doing heavy work inside a per-tick handler will make a perfectly located room feel broken. See room scripts and bots.
- Ignore the flag. The country shown next to a room is set by the host and verified by nobody — including us. Never pick a room or a provider on it.
Where to go next
- How to host a Haxball room — the full picture, from tokens to going live.
- The headless host — and why the room-list flag means nothing.
- The ping test — measure every location from your own connection.