Latency for Streaming and Cloud Gaming: What Matters

Quick answer: watching a recorded show or film and playing a game from the cloud are very different network workloads. On-demand streaming needs enough throughput to keep a buffer full, and tolerates high latency. Live streaming adds deliberate delay of seconds. Cloud gaming needs both enough throughput for a video stream and a low, steady round trip because every button press must travel to a remote machine and the resulting video must come back. As general guidance, aim for a round trip under about 40 ms to the cloud gaming data centre, a wired or 5 GHz connection, and no heavy uploads or downloads at the same time. Specific limits vary by service, so check your provider's current requirements.

Important: ping is not the same number as GlobeLatency's HTTPS latency. The ranges on this page describe round-trip time to the server you actually use (what ping, or a game's own ping display, shows). GlobeLatency times full HTTPS requests from the browser, which include DNS, TCP and TLS setup on a fresh connection (roughly three round trips) plus server and browser time, so its numbers are usually higher than ping to the same server, often 1.5 to 3 times on a cold connection. Judge GlobeLatency results by the colour and the comparison with the world average, and use these ranges for ping or in-game latency. See ping vs HTTPS latency.

Streaming video on demand: why latency matters less than throughput

When you press play on a recorded video, the player does not show data the instant it arrives. It downloads ahead into a buffer, commonly tens of seconds of video, and plays from that buffer. As long as the average download rate stays above the video's bitrate, the buffer stays full and the viewer never sees the network at all. A latency of 20 ms or 200 ms changes only how long the first frame takes and how quickly each new segment request is answered.

The two numbers that matter are the video bitrate and your sustained throughput. Bitrates differ by resolution, codec and service and change over time, so check your provider's guidance. For the general difference between latency and throughput, see latency vs bandwidth vs throughput.

How latency still has an effect

• Start-up time. Setting up a connection requires a few round trips (DNS, TCP, TLS, then a request). With a 150 ms round trip, five round trips cost 750 ms before the first byte of video.
• Throughput per connection. TCP throughput is limited by window size divided by round-trip time. Higher RTT can reduce the speed of a single connection, especially with packet loss, though streaming services typically use servers near viewers (see CDN and anycast) to keep this small.
• Seeking. Jumping to a new place needs fresh segments, so lag shows at that moment.

Adaptive bitrate (ABR) in practice

Most services use adaptive bitrate streaming (the common formats are HLS and MPEG-DASH). The video is encoded at several qualities, cut into short segments, typically a few seconds each, and described in a manifest. The player downloads a segment, measures how long it took, and picks the next segment's quality accordingly.

Condition	What the player does	What you see
Throughput well above bitrate	Steps up in quality, buffer grows	Sharp picture
Throughput falls briefly	Buffer drains; player may step down	Picture softens for a while
Throughput below the lowest bitrate	Buffer empties	Stall or spinning wheel
Evening congestion on the shared path	Lower quality for hours	Consistent blur at peak time

Worked example

Assume a video stream at a particular quality needs 8 Mbit/s. Your connection delivers 25 Mbit/s but another household member starts a large upload and your throughput to the streaming server drops to 6 Mbit/s. The buffer has 30 s of video. Each second of playback consumes 8 Mbit but only 6 arrive, so the buffer shrinks by 2 Mbit per second, which is 0.25 s of video per second. It would last 120 s before stalling, and the ABR logic will step down long before that. The viewer sees a lower resolution, not a latency problem.

Live streaming latency tiers

With live streams, the buffer cannot be large, because the video is being made now. Delay is measured "glass to glass": from the camera to the viewer's screen. Rough tiers, which vary by platform and settings:

Tier	Typical glass-to-glass delay	Used for
Standard segment-based live	roughly 15 to 45 seconds	Broadcasts, large audiences, maximum reliability
Low-latency segmented live	roughly 3 to 10 seconds	Sports, game streams with chat
Ultra-low-latency (real-time protocols)	roughly under 1 to 2 seconds	Auctions, betting, interactive shows
Interactive video calls	roughly 150 ms one way	Conversations; see latency for video calls and VoIP

Most of this delay comes from segmenting, encoding, CDN propagation and player buffering, not from the distance between you and the server. A faster connection or lower ping hardly changes it; the stream choice does. If you stream out (as a broadcaster) your upload bandwidth and stability matter: the encoder bitrate should stay comfortably below your real, measured upload rate, and spikes or bufferbloat make the stream drop frames.

Cloud gaming: the input latency budget

In cloud gaming the game runs on a remote machine in a data centre. Your device receives video and sends back controller or keyboard inputs. Total input latency (also called click-to-photon latency) is the time from pressing a button to seeing its effect on screen. It is the sum of many stages:

Stage	Typical range (general)	Notes
Controller or input device to your device	1 to 10 ms (wireless can be higher)	Bluetooth can add a few ms more than a cable
Network, upstream half	about half of RTT	The part you can measure
Server game simulation and rendering	one frame time, 8 to 17 ms for 120 to 60 fps	Frame time is 1000 ÷ fps
Video encode on server	roughly 2 to 15 ms	Hardware encoders are fast
Network, downstream half	about half of RTT	Plus transmission time for large frames
Jitter buffer and decode on your device	roughly 3 to 20 ms	Depends on device and buffer size
Display processing and refresh wait	roughly 5 to 30 ms	TVs in non-game mode can be much higher

Worked example

Suppose input device 5 ms, round trip 30 ms, server frame 16.7 ms (60 fps), encode 6 ms, decode and buffer 8 ms, display 15 ms. Total: 5 + 30 + 16.7 + 6 + 8 + 15 = about 81 ms. On a local console the same game might take around 40 to 60 ms from press to photon, so the cloud adds a noticeable but often acceptable margin. Raise the round trip to 80 ms with the same other values and the total goes to roughly 131 ms, which many players will find laggy in fast action games, while slower games still feel fine.

Because the stream is video, a lost packet means a missing piece of a frame. The service may conceal it, lower the bitrate, or request a new key frame, each producing a visible artefact or a pause. Low jitter is as important as low average latency.

Frame time and frame pacing

At 60 fps a new frame must arrive every 16.7 ms. If delivery is uneven, the player shows frames late and the game seems to stutter even when the average rate is 60. That is why cloud services want stable latency: jitter of 5 to 10 ms is hidden by a small buffer, while jitter of 50 ms or more causes either added delay or dropped frames.

Ranges to aim for

Round trip to the cloud gaming data centre	General expectation
Under about 20 ms	Excellent; feels close to local for most players
About 20 to 40 ms	Good for nearly all genres
About 40 to 60 ms	Fine for most games; competitive players may notice
About 60 to 80 ms	Noticeable in fast shooters and fighting games
Above about 80 to 100 ms	Often frustrating for action games; fine for slower titles

These are general guidelines, not specifications of any service. Providers publish their own recommended minimum bandwidth, maximum latency and loss, and these change; check the provider's current network requirements. The link to the data centre depends on where it is: see data centres, cloud regions and edge.

Why Wi-Fi band and Ethernet matter so much

Cloud gaming and live streaming send continuous high-rate data. Wi-Fi at 2.4 GHz is crowded and slower; 5 GHz and 6 GHz offer more channels and shorter range. The main problem is variability, not average delay: radio retransmissions and contention produce random 20 to 100 ms delays that a video stream shows as stutter. Practical guidance:

• Use Ethernet for the playing device when possible; it eliminates this source.
• On Wi-Fi, use 5 GHz or 6 GHz, in the same room or with line of sight to the access point.
• Stop other heavy use during sessions; the router queue creates bufferbloat.
• If a TV or handheld connects wirelessly, test from the same place with the same band.

See Wi-Fi, Ethernet, fibre, mobile and satellite latency for typical ranges per technology.

How to test your connection for streaming and cloud gaming

1. Run the GlobeLatency test from the device or the same network and band you will use. Choose destinations in or near the region of the service's data centres, plus a few nearby ones. Use 10 to 20 passes per destination.
2. Look at the average, best and worst pass. For cloud gaming the worst pass and p95 are more informative than the average. A destination flagged Unstable (worst pass more than three times the average) is a warning.
3. Open the monitor for 10 to 15 minutes while you do things that normally happen in your house (other people streaming, backups) and watch spikes on the sparkline and the no-reply percentage.
4. Repeat on Ethernet versus Wi-Fi, and at your normal play time. Compare using saved report links.

GlobeLatency measures HTTPS round trips from a browser to public servers. It cannot measure your provider's streaming data centre protocol or throughput (it is not a speed test), so use it for latency, stability and relative comparison, and use the service's built-in network test for its exact requirements. See accuracy and limitations.

Common mistakes and myths

• "My speed test is fast, so cloud gaming will be fine." Throughput does not guarantee low jitter or round trip.
• "Buffering means high ping." It nearly always means insufficient throughput or loss.
• Testing at 10 a.m. and playing at 8 p.m. Peak-time congestion differs.
• Confusing live stream delay with ping. Seconds of delay are by design.
• Ignoring the display. A TV with heavy processing can add more delay than the network. Use game mode.

What to do next

If your results are marginal, follow how to reduce latency. For gaming in general, read latency for gaming. If streams degrade only at certain hours, see troubleshoot high latency.