The distance to the server sets a delay no upgrade can remove

Most explanations of network latency stop at the point where it starts to matter. This one carries on.

Light in glass is slower than light in vacuum

Signals in optical fibre travel at roughly two thirds of the speed of light in empty space, because glass slows the wave down. That gives a hard floor for any long path, and no equipment purchased at either end can push a signal below it.

Cables also do not run in straight lines, following coasts, roads and existing rights of way that add distance to the geometric minimum. A request crossing an ocean and returning has covered that padded distance twice before a single byte of the answer appears. This is why a server on another continent feels sluggish even when the connection at both ends is entirely uncongested.

Delay is four different things added together

Propagation delay is the travel time along the path, and it depends only on distance and the medium carrying the signal. Serialisation delay is the time spent clocking bits onto the wire, and this is the only part that a faster line shortens.

Processing delay is the time each router spends examining a packet and deciding where to send it next, usually very small. Queueing delay is time spent waiting behind other packets in a buffer, and it is by far the most variable of the four. Anyone diagnosing a slow connection is really trying to work out which of these four is dominating at that moment.

Round trips multiply everything

Most protocols ask a question and wait for an answer, so every fixed delay along the path is paid once per exchange. Establishing a secure connection historically required several such exchanges before the first byte of actual content could even be requested. Loading a page may involve name lookups, connection setup and many separate requests, each carrying the full round trip cost again.

This is why a page with many small resources feels slow on a distant link while one large download feels perfectly fine. Reducing the number of round trips is usually a much larger win than reducing the size of what travels in them.

More bandwidth shortens only one of the four

Doubling the line rate halves serialisation delay, which matters for large transfers and hardly at all for a small request. For a request that fits in a single packet, the time on the wire is negligible next to the time in transit. This is the reason an upgraded connection can leave interactive tasks feeling exactly the same as they did before.

It also explains why two connections with very different advertised speeds can produce almost identical results in a browser.

Bandwidth determines how much can be in flight; latency determines how long you wait before anything starts arriving at all.

Where the delay actually accumulates

The final hop into a home is often the largest single contributor, because access technologies add framing, scheduling and error correction. Wireless links add more, since a device must wait for a transmission opportunity and may need to repeat frames that were lost.

Mobile networks schedule access in fixed intervals, so a packet arriving just after a slot has closed waits for the next one. Any device performing inspection, filtering or translation on the path adds processing time, and several such devices are common. Congestion anywhere in the chain converts into queueing, which is why delay rises sharply exactly when a link is being used hard.

This is the general case; a specific device may behave differently by design.

What genuinely reduces it

Choosing a server closer to the user removes propagation delay permanently, which is why service providers distribute their infrastructure geographically. Reusing an existing connection avoids repeating setup exchanges, and protocols have been redesigned repeatedly to cut those exchanges down.

Putting the final hop on a cable rather than a radio removes contention and retransmission from the most variable part of the path. Keeping queues short matters more than making them large, because a full buffer converts spare capacity into waiting time. Measuring delay while the link is busy, rather than while it is idle, is the only way to see the problem people actually experience.

The takeaway

Bandwidth is how wide the road is; latency is how far away the destination sits.

The constraint is almost always physical, and marketing rarely mentions which one.