What Is Latency? Network Latency Explained With Real Numbers

The short answer to what is latency: it is the delay between a sender emitting data and the receiver being able to use it, measured in milliseconds as one-way delay or round-trip time (RTT). Network latency has a physical floor. Light in optical fiber covers about 200 km per millisecond, so no request between New York and London can complete a round trip in less than about 56 ms. This guide gives the precise latency definition, a latency vs bandwidth vs throughput table, real numbers by distance and connection type, a reusable round-trip budget, and the failure modes behind bad p99 latency.

As of 2026, no protocol or hardware upgrade can push a New York to London round trip below about 56 ms, because light in fiber travels roughly 200,000 km per second over the 5,570 km great-circle path. Real cable routes are longer than the great circle, so measured RTT on that path typically lands between 70 and 80 ms.

Latency definition: one-way delay vs round-trip time

Network latency is the elapsed time between the first bit of a message leaving the sender and that message being usable at the receiver. One-way delay measures a single direction. Round-trip time measures the request out and the reply back, and it is the figure most tools report.

The IETF formalizes both: RFC 7679, which obsoletes RFC 2679, defines one-way delay, and RFC 2681 defines round-trip delay. One-way measurement needs synchronized clocks at both ends, because an NTP offset of a few milliseconds can swamp the value being measured. That is why dashboards, load balancers and TCP stacks work with RTT. Forward and return paths often differ, so RTT divided by two approximates one-way delay; it does not measure it.

How network latency works: four delays plus protocol round trips

Every packet accumulates four kinds of delay at every hop:

• Propagation: distance divided by signal speed, about 5 microseconds per km in fiber.
• Serialization: packet size divided by link rate. A 1,500 byte frame takes 1.2 ms at 10 Mb/s and 1.2 microseconds at 10 Gb/s.
• Queuing: time spent in buffers, near zero on an idle link and tens to hundreds of milliseconds on a saturated one.
• Processing: forwarding lookups, firewall inspection, TLS termination and application work.

On long-haul paths propagation dominates; on the last mile, queuing and contention usually do. Protocols then multiply whatever RTT the path has. A cold HTTPS request runs DNS resolution, a TCP handshake, a TLS handshake and the request itself in sequence, and each step costs at least one round trip.

Network latency vs bandwidth vs throughput

Bandwidth is the only metric in this table that does not improve when you shorten the path, which is why adding capacity rarely fixes a latency problem.

Latency vs. bandwidth: bandwidth is how wide the pipe is, latency is how long it is. A 10 Gb/s link from Frankfurt to Singapore still pays roughly 150 ms or more per round trip.

Latency vs. throughput: for loss-based congestion control, the Mathis approximation caps throughput near MSS divided by RTT times the square root of the loss rate. With a 1,460 byte MSS and 0.01 percent loss, that ceiling is about 14 Mb/s at 100 ms RTT and about 70 Mb/s at 20 ms. BBR behaves differently, but RTT still bounds how fast windows grow.

Typical latency numbers by distance

Minimum RTT in fiber is about 1 ms per 100 km of one-way distance. Measured values typically run 20 to 50 percent higher because cables follow coastlines and landing stations, not great circles. The ranges below are typical public traffic measurements, not guarantees.

On intercontinental paths distance sets most of the RTT, so moving the responding server closer to users is the only lever that removes it.

Last-mile latency by connection type

Access networks add their own RTT before traffic reaches the backbone. Typical ranges: fiber to the home 1 to 5 ms, cable 8 to 25 ms, DSL 10 to 30 ms, 4G LTE 30 to 60 ms, 5G 15 to 35 ms, LEO satellite 25 to 60 ms, and geostationary satellite 550 ms or more, since each round trip covers about 143,000 km. Busy Wi-Fi adds 20 ms or more on top.

The round-trip budget: a worked calculation

Count round trips, multiply by RTT, and you get the floor for a request regardless of server speed. Assume a cold HTTPS fetch of a 1 MB object over TLS 1.3, with a 20 ms DNS lookup and an initial congestion window of 10 segments (about 14 KB). Slow start delivers 14, 28, 56, 112, 224 and 448 KB per round trip, 882 KB after six, so 1 MB needs seven. Figures are our estimate.

Cutting RTT from 80 ms to 10 ms shrinks this request by roughly 7x, and none of that gain depends on link bandwidth.

The same arithmetic explains throughput ceilings. Filling 1 Gb/s at 80 ms RTT requires 10 MB in flight (1 Gb/s times 0.08 s). Socket buffers smaller than that bandwidth-delay product cap transfer speed no matter how large the link is.

Where latency matters: SaaS, streaming and realtime

• Enterprise SaaS and APIs: login redirects, token exchanges, GraphQL resolvers and microservice chains. Five sequential calls at 40 ms cross-region RTT spend 200 ms on the wire.
• Media and streaming: startup requires manifest, init segment and first media segments, each at least one round trip. Throughput sets sustained bitrate; latency sets startup, seek and ad insertion responsiveness.
• Realtime systems: ITU-T G.114 recommends keeping one-way voice delay under 150 ms. For VoIP, gaming and remote desktops, jitter and p99 matter more than the average.

What causes high latency

The usual causes are geographic distance, routing that hairpins through a distant exchange, congestion and bufferbloat, packet loss forcing retransmissions, firewalls and TLS inspection proxies, security gateways that backhaul traffic to one region, Wi-Fi contention, cross-region calls and chatty designs with serialized RPCs. Stable average RTT can hide poor p95 and p99 caused by origin compute or storage contention.

Latency failure modes: what breaks, how it shows up, how to confirm it

Bufferbloat

RTT climbs from 20 ms idle to 200 ms or more while a large upload runs, and calls glitch during backups. Confirm by measuring RTT on an idle link and again under saturation; a gap above 100 ms points to oversized buffers. Active queue management such as fq_codel or CAKE fixes it.

Tail retransmission timeouts

When the last packet of a response is lost, nothing follows it to trigger fast retransmit, so the sender waits for a timeout, at least 200 ms on Linux. It shows up as p99 TTFB clustered near 200 ms plus RTT while averages look clean. Correlate TCP retransmission counters with slow requests to confirm.

Ping looks fine, users see slow pages

ICMP is often rate-limited, and ping skips DNS, TLS and application work. Compare ICMP RTT with TCP connect time and TTFB from the same vantage point; the difference is where your latency lives.

Fan-out tail amplification

If a request calls 10 services and each has a 1 percent chance of a 100 ms stall, about 9.6 percent of requests hit at least one stall. Overall p99 rises while every service's own p99 looks unchanged. Distributed tracing of the critical path confirms it.

How to reduce latency for users

Measure DNS, connect, TLS, TTFB and transfer time separately, at p50, p95 and p99, by region and by network. Browser Resource Timing data and HTTP client timing breakdowns expose each phase. Then work the levers in order of milliseconds saved:

1. Cut distance: serve cacheable content from edge caches near users, with origin shield so misses take one warm hop.
2. Cut round trips: keep connections alive, multiplex on HTTP/2, use TLS 1.3 and session resumption. QUIC in HTTP/3 merges transport and crypto setup into one round trip.
3. Cut queuing: deploy active queue management and keep latency-sensitive paths out of overloaded inspection middleboxes.
4. Cut serial dependencies: batch RPCs, parallelize fan-out, colocate chatty services, hedge requests against tail latency.
5. Tune transport: size buffers to the bandwidth-delay product and evaluate BBR on long, lossy paths.

A CDN attacks both terms of the round-trip budget: it shortens the RTT every handshake pays and keeps warm connections to origin so misses avoid cold setup over the long path. For heavy static payloads such as video segments, installers and game patches, the BlazingCDN Anycast CDN for low-latency delivery serves cached objects from NVMe SSD servers, and measured June 2026 on a 100 MB HTTPS download it recorded 24 ms in North America, 27 ms in Europe and 47 ms in Asia.

FAQ: what is latency and how network latency is measured

How do you define latency in networking?

Define latency in networking as the time between data leaving a sender and becoming usable at the receiver, expressed in milliseconds. It is reported as one-way delay, which needs synchronized clocks at both ends, or as round-trip time, which a single host can measure. RFC 7679 and RFC 2681 formalize the two, and RTT is what most tools and TCP stacks expose.

What is a good network latency for web applications?

A good network latency for web traffic is an RTT below about 50 ms between the user and the server answering the first request. Same-metro paths reach 1 to 5 ms, intercontinental paths rarely beat 70 ms, and LTE adds 30 to 60 ms. Because a cold HTTPS request needs three or four round trips, users feel that RTT multiplied.

Does more bandwidth reduce network latency?

More bandwidth does not reduce network latency on an uncongested path, because propagation delay depends on distance, not link capacity. Extra capacity helps only when queuing on a saturated link causes the delay, or when serialization time matters on very slow links. Removing round trips or moving the server closer usually saves more milliseconds than a bandwidth upgrade.

What is the difference between latency and ping?

Ping is one tool for measuring latency, not latency itself. It sends ICMP echo packets and reports RTT, but routers often rate-limit ICMP, and ping skips DNS, TCP, TLS and application processing. A clean ping alongside slow pages usually means the delay sits in handshakes, server time or tail retransmissions, which connect time and TTFB measurements reveal.

Measure your round-trip budget this week

Pick three user regions and record DNS, connect, TLS, TTFB and transfer time for one cold and one warm request, against your origin and against your CDN hostname. Divide cold TTFB by the measured RTT: a result above four means protocol round trips, not distance, are your main cost, and connection reuse or TLS 1.3 will pay off before any infrastructure change. Track p99 alongside the median, since tail retransmissions and fan-out stalls never show up in averages.

BlazingCDN publishes its June 2026 latency and throughput measurements on its CDN performance metrics page with a public test file, which you can download from your own networks and compare against the numbers you just collected.