Start with the target, not a universal pass mark
For a fast online game, a lower and steadier round-trip time to that game's server is generally preferable. The ranges below are editorial rules of thumb for comparing gaming results, not an official standard or a guarantee for a particular game.
| Reported round-trip time | Practical interpretation |
|---|---|
| Below 50 ms | A useful low-delay target for fast interactive play. |
| 50–100 ms | May be playable; check the game and the consistency of the result. |
| 100–150 ms | Delay may be more noticeable in fast games. |
| Above 150 ms | Often less responsive for fast play, but not proof of a broken connection. |
Do not apply this table as a universal video-call or streaming requirement. Calls also depend on jitter, loss and application buffering; buffered video depends heavily on available throughput and stability. A single browser result cannot certify either experience.
Ping, latency and stability
The conventional ping command measures replies to ICMP echo requests. Round-trip time (RTT) includes the journey out and back. One-way delay cannot reliably be calculated by halving RTT: the two directions can have different paths and queues. Bandwidth in Mbps describes capacity, not the same quantity as delay in ms.
A changing delay is often described as jitter. Packet loss is a separate network metric. Keep the measurement method and destination with any number you record; different tools need not calculate the same statistic.
What the IPdidi browser test actually measures
The ping test makes two warm-up requests, then 40 HTTP measurements to /ping.txt on the Cloudflare edge serving this site. It does not send ICMP packets and does not measure your game server.
The implementation normally uses the interval from requestStart to responseStart, an HTTP request-to-response-start measurement that can include server processing. If that timing is unavailable, it uses elapsed fetch time, including reading the response. These are useful observations, not a pure network RTT guarantee.
The displayed jitter is the mean absolute change between adjacent successful samples. A timeout or failed HTTP request is counted as a failed sample; that count is not a measurement of IP packet-loss percentage. The page's use-case ratings are local heuristics, not an app provider's certification. This explanation comes from source inspection, not a claimed live connection test.
Make a comparison you can use
- Record the target, tool, time, Wi-Fi or Ethernet, VPN state, average, variation and failures.
- Repeat while the connection is idle, then during an ordinary download or upload. Keep the target and method unchanged.
- Compare Ethernet with Wi-Fi if available. This helps isolate wireless effects; it does not guarantee a lower number.
- Check the game's own network display or the call app's diagnostics. A good result to one edge does not rule out a local, route, server or application problem elsewhere.
For an ICMP comparison, use ping example.com in a terminal and stop with Ctrl+C if it continues. A destination that filters echo requests may not reply; this alone does not prove the service is down.
Change one thing, then measure again
- Pause bulk downloads and backups to check whether queueing under load is involved.
- On Wi-Fi, compare position and a less congested band or channel; 5 GHz is not automatically better through walls or at long range.
- Compare a suitable game region and VPN on/off using the same activity. Neither a VPN nor a faster plan guarantees better latency.
- If your router supports queue management, consult its official instructions. It can help with queueing delay, but cannot remove propagation distance.
- If problems persist, give support the target, times and idle-versus-loaded results rather than only the best number.
Use the same test before and after each change. Do not diagnose the cause from two different destinations alone.
Common questions
Is 100 ms always bad?
No. The task, endpoint, protocol and stability matter. Treat it as a measurement to investigate, not a universal pass or fail.
Are HTTP failures the same as packet loss?
No. A failed request can have several causes. This browser test does not establish a network packet-loss rate.
Why does the game show a different number?
Its endpoint, traffic and processing differ. Compare its own diagnostics rather than subtracting two unrelated measurements.
Sources and scope
This guide explains measurements and a comparison workflow. It does not claim to identify a fault in your connection or to have tested a particular device.
Sources checked: 2026-11-05.