Latency is the time a piece of data needs to travel from sender to receiver. In networking it is usually given as round-trip time (RTT): the time from sending a request until the answer arrives back, measured in milliseconds.

How much latency does an edge server save?

That depends on how far away the alternative cloud region is and how the network is routed. The physical estimate is roughly 1 ms of round-trip time per 100 km of fibre. Measure your own paths with tools like ping or traceroute instead of relying on general figures.

Is 5G faster than Wi-Fi in terms of latency?

Not in general. Both can achieve low latency under good conditions. 5G campus networks are chosen mainly for coverage, mobility and predictable quality of service in large areas, not because they are always faster than a well-planned Wi-Fi.

Does a CDN reduce latency for dynamic content?

A CDN mainly speeds up cacheable content. For dynamic requests it can still help by terminating connections close to the user, but the request must eventually reach your application and database.

Edge vs. Cloud Latency: Where Milliseconds Come From

Edge computing reduces latency by shortening the path between the user or device and the server that processes the request. The gain is largest when the alternative is a cloud region far away, or when the application needs answers within a few milliseconds. For many web applications, however, choosing a cloud region in the same country already removes most of the distance, and the remaining delay comes from handshakes, the access network and the application itself.

What latency is made of

Network latency is usually measured as round-trip time (RTT), the time from sending a request until the response arrives. It is the sum of several components:

Propagation delay. The time the signal needs to cover the physical distance. It depends only on distance and medium.
Transmission and serialisation. Putting the bits of a packet onto the wire. Small at modern link speeds, relevant for large payloads.
Queuing and routing. Each router on the path adds a little delay, more under load.
Access network. The last mile: DSL, cable, fibre to the home, Wi-Fi or mobile radio each add their own delay, which can vary a lot.
Protocol handshakes. Establishing a TCP connection and negotiating TLS encryption costs round trips before the first byte of the actual request is sent.
Server processing. The application, database queries and calls to other services.

Edge computing mainly reduces items 1 and 3, and with network-integrated edge also part of item 4. It does nothing for slow database queries.

A physical estimate

This section is a physical approximation, not a measurement. Light in a vacuum travels at about 300,000 km per second. In optical fibre it is slower, roughly two thirds of that, about 200,000 km per second. That means about 5 microseconds per kilometre one way, or about 1 ms of round-trip time per 100 km of fibre.

Fibre distance (one way)	Minimum round trip from propagation alone
10 km (same city)	about 0.1 ms
100 km	about 1 ms
500 km (within a large country)	about 5 ms
1,000 km (across central Europe)	about 10 ms
6,500 km (roughly Frankfurt to the US east coast as the crow flies)	about 65 ms

Real fibre routes are longer than straight lines and every router adds delay, so measured values are higher. Still, the table shows the order of magnitude: within one European country, distance accounts for only a few milliseconds; across an ocean, it dominates.

Handshakes multiply distance

A secure web request over TCP with TLS 1.3 needs one round trip for the TCP handshake and one for the TLS handshake before the HTTP request itself, which takes another round trip. So the first response costs at least three round trips. TLS 1.3 and QUIC, the transport under HTTP/3, reduce the number of handshake round trips, and connection reuse avoids them for later requests.

This is why distance matters more than the raw numbers suggest: at 65 ms RTT, three round trips already add up to around 200 ms before your server has done any work.

When the cloud is close enough

For a typical web or mobile application with users in Germany, Austria or Switzerland, a cloud region in Frankfurt, Nuremberg or another nearby city keeps propagation delay in the low milliseconds. Improvements then come from:

keeping connections open and using HTTP/2 or HTTP/3,
caching static content at a CDN,
making database queries and APIs faster.

If you are choosing a provider with data centres close to your users, the overview of European cloud providers lists locations.

When the edge is worth it

Moving compute closer pays off when:

Control loops need a response within a few milliseconds, for example in robotics, machine control or augmented reality.
Users or devices are far from any suitable cloud region, such as remote industrial sites or ships.
Large data volumes (video, high-frequency sensor data) would otherwise have to travel to a distant data centre.
The connection is unreliable and the application must keep working regardless.

In factories, the combination of an on-site edge server and a private 5G network or well-planned Wi-Fi keeps the entire path inside the premises. The broader concept is explained in what edge computing is.

Measure instead of guessing

Before investing in edge infrastructure, measure. ping shows round-trip times to a host, traceroute or mtr show the path and where delay accumulates, and browser developer tools break down the timing of a web request into DNS, connection, TLS and waiting for the server. Measure from where your users actually are, at the times they use the application. These numbers tell you whether distance is really the problem.