Network Latency Explained: Where the Milliseconds Go

Network latency is the time a packet takes to reach its destination and come back, the round-trip time (RTT), in milliseconds. Four things make it up: the distance the signal travels, the route the networks choose, the queues it waits in, and the round trips the protocols on top add. Only the first one is set by physics. This guide takes each in turn, with real measurements from our servers in Falkenstein (Germany) and Gravelines (France) on 7 October 2026.

What a round trip is made of

Component	What it is	Typical size
Propagation	Light in optical fibre travels at about 200,000 km/s, two thirds of its speed in a vacuum: 1 ms of round trip per 100 km of cable	Under 1 ms in a city, 60 to 90 ms across the Atlantic, 160 ms or more to the other side of the world
Serialisation	Putting the bits of a packet on the wire: 1,500 bytes take 12 µs at 1 Gbit/s	Negligible, except on slow links: 1.2 ms per full packet at 10 Mbit/s
Queuing	Waiting in a router or modem buffer when a link is busy	Zero on an idle path, hundreds of milliseconds when a buffer fills
Processing	The router deciding where to send the packet	Microseconds on current hardware

A common belief is that "every hop adds a few milliseconds". It does not: forwarding takes microseconds. When the times in a traceroute grow from one hop to the next, it is distance, or a queue, or the router being slow to answer the probe while it forwards everything else at full speed.

Distance sets a floor

The shortest possible round trip is the great-circle distance at the speed of light in fibre. Real cables never follow the great circle, and real routes rarely take the shortest cable. Here is how far our measurements were from that floor (average of 60 to 100 probes per destination, with mtr):

From → to	Distance	Floor in fibre	Measured	Ratio
Gravelines → Cloudflare 1.1.1.1 (Paris)	237 km	2.4 ms	4.9 ms	2.0×
Falkenstein → Cloudflare 1.1.1.1 (Frankfurt)	265 km	2.6 ms	5.9 ms	2.3×
Gravelines → New Jersey	5,779 km	57.8 ms	71.7 ms	1.2×
Falkenstein → New Jersey	6,462 km	64.6 ms	86.4 ms	1.3×
Falkenstein → Singapore	9,994 km	99.9 ms	165.5 ms	1.7×
Falkenstein → Tokyo	9,134 km	91.3 ms	273.6 ms	3.0×
Falkenstein → Sydney	16,220 km	162.2 ms	341.2 ms	2.1×

Over short distances, the fixed costs (equipment, the last metres of cabling, the time the destination takes to answer) dominate and the ratio looks bad while the absolute numbers are tiny. Over long ones, the route is what matters. Tokyo is three times its floor because the packets do not go there directly: the trace leaves Europe on Arelion's network, reaches Singapore at 169 ms, then Tokyo at 246 ms. In our study of cloud latency from 33 cities, Johannesburg to São Paulo took 351 ms at best for a floor of 74 ms: the packets went through Europe.

Same destination, two routes

The same Vultr host in New Jersey, measured the same minute from our two servers:

From Falkenstein (Hetzner, AS24940)
  5. AS201011 ae12-499.nbg40.core-backbone.com      0.0%   100    3.2   3.0   2.7   3.3   0.1
  6. AS201011 ae7-2093.nyk10.core-backbone.com      0.0%   100   86.6  86.7  86.5  87.0   0.1
 11. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   86.2  86.4  85.9 107.1   2.1

From Gravelines (OVHcloud, AS16276)
 10. AS16276  be102.lon-drch-sbb1-nc5.uk.eu         1.0%   100    3.8   3.7   3.5   4.1   0.1
 11. AS16276  nyc-ny1-sbb2-8k.nj.us                 0.0%   100   73.0  73.4  71.6  76.0   0.8
 13. AS???    nyiix.gi3-6.cr1.nyc1.choopa.net       0.0%   100   72.7  72.5  72.3  73.0   0.1
 17. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   71.7  71.7  71.5  73.0   0.2

The 14.7 ms difference is only half distance (the floors differ by 6.8 ms). The rest is the route: from Gravelines, OVH carries the traffic on its own network through London to New York and hands it to Vultr at NYIIX, a New York exchange point; from Falkenstein, Hetzner hands it to Core-Backbone in Nuremberg, which crosses the Atlantic. Choosing a host, or a provider, is also choosing its routes.

Queues: the latency that comes and goes

Propagation does not change. Queues do. On the idle paths above, the spread at the destinations stayed between 0.1 and 2.1 ms over 100 probes. On a home connection, a single large upload can fill the modem's buffer and add hundreds of milliseconds to everything else: that is bufferbloat.

To test it, run ping 1.1.1.1 and, while it runs, start a large upload and then a large download. If the times jump from 15 ms to 200 ms or more and fall back when the transfer ends, the buffer is the problem. The fix is on the router: smart queue management (fq_codel or CAKE, available on OpenWrt and many recent routers), or shaping the link slightly below its rated speed.

Protocols multiply the round trips

A new HTTPS connection pays several round trips before the first byte of the page arrives: a DNS lookup if the name is not cached, one for the TCP handshake, one for TLS 1.3 (two for TLS 1.2), and one for the request itself. Counting four:

Round trip	4 round trips
6 ms (a nearby server)	24 ms
86 ms (Germany to New Jersey)	344 ms
341 ms (Germany to Sydney)	1.4 s

The same arithmetic applies to anything sequential: an application that makes 20 database queries one after the other, to a database 80 ms away, waits 1.6 seconds. HTTP/2 and HTTP/3 reuse connections, TLS 1.3 and QUIC cut handshakes, and fewer sequential requests cut the rest.

How much is too much

Use	Comfortable	Noticeable
Voice and video calls	Under 150 ms one way, the ITU-T G.114 recommendation	Beyond, people start talking over each other
Fast online games	Under about 50 ms round trip	Above 100 ms most players feel it
Web pages and APIs	Depends on the number of sequential round trips	Every extra round trip is added to the time to first byte

Measure it yourself

• ping -c 20 host: the minimum is your floor on that path, the average your usual latency, and mdev the jitter.
• mtr -rwz -c 100 host: where along the path the time is added (see how to read an mtr report).
• From several places: our cloud latency test measures your browser's latency to 36 regions of AWS, OVHcloud, Vultr and Akamai, and TraceMapper traces the same route from more than 30 locations.

What you can change, and what you cannot

• Distance: only by moving the server closer to the users, or adding a region or a CDN. In our 33-city study, Frankfurt alone served 14 cities in under 100 ms; Frankfurt and Singapore together, 27.
• Route: by choosing a provider whose network and peering suit your users. You cannot change another network's routing policy.
• Queues: smart queue management at home, and not running links at 100% in a data centre.
• Round trips: connection reuse, TLS 1.3, DNS caching, fewer sequential calls.

For the practical side, see how to reduce network latency.