Why faster broadband does not remove every delay

A broadband upgrade can make a large download finish much sooner while leaving an awkward pause in a distant video conversation almost unchanged. Both experiences are real. The upgrade has improved one part of the journey, while another part still takes time.

The word “fast” hides several measurements. Bandwidth is a link’s data-carrying capacity, usually expressed in bits per second. Throughput is the rate actually achieved. Latency is delay, which might be measured one way or as a round trip. For example, a 50-millisecond one-way delay becomes a 100-millisecond round trip if the return takes the same time. A useful result must say which journey it measures. Cloudflare’s introduction distinguishes these quantities.

They interact, but they are not interchangeable. Understanding the difference means following a message through the network, rather than judging the whole experience by one number on a broadband package.

The part that more capacity can shorten

Before a file can arrive, its bits must be transmitted. In an idealised example, a 100 MB file contains 800 megabits: here MB means decimal megabytes, with eight bits per byte. At a fully available rate of 100 megabits per second, transmitting those bits takes eight seconds. At 1,000 megabits per second, it takes 0.8 seconds.

Those are the two bars in the diagram. They show a calculation, not a promise about a real download. Real transfers also send extra data for addresses and control messages, called protocol overhead. Other users may share the connection, and a slower link elsewhere may limit the whole journey. The same reasoning also applies to an individual packet: a faster link can put its bits onto the link sooner.

This transmission time is different from the time the signal spends travelling after it has been launched. A faster data rate puts more bits onto the cable each second. It does not automatically make each signal travel faster along the cable. That travel speed is called propagation speed.

Distance still takes time

For the article’s model, assume a one-way fibre path of 10,000 kilometres and an optical propagation speed of 200,000 kilometres per second. Dividing distance by speed gives 0.05 seconds, or 50 milliseconds one way. If the return journey uses an equally long path at the same speed, propagation alone takes 100 milliseconds there and back.

Changing the data rate from 100 to 1,000 megabits per second leaves that calculation unchanged. Shortening the route changes it immediately. These are illustrative inputs, not a measured Delhi–London connection; real cable routes need not follow the shortest line on a map.

The glass-fibre story explains how the signal remains guided. Guidance solves the problem of following a path. It does not remove the length of that path.

A packet can also spend time waiting

Distance is only one source of delay. When packets reach an outgoing link faster than it can serve them, they wait in a queue. A short queue can handle a brief burst of traffic. But if the queue stays full, every new packet has to wait. Keeping too much data waiting in this way is often called bufferbloat.

That explains why a connection may feel responsive when idle but sluggish during a large transfer. Small interactive messages can end up waiting behind bulk traffic. More capacity at the actual bottleneck can help, but the location of that bottleneck and the way its queue is managed also matter.

Network engineers therefore decide which packets go next and how to stop queues growing too long. These methods are called scheduling and active queue management. The experimental algorithm described in IETF RFC 8290, FQ-CoDel, separates traffic flows and manages queues to reduce delay. The important idea is that retaining every packet in an ever-longer queue is not automatically good service.

The sender does not work in isolation

Many applications use TCP, a set of rules for moving data reliably between devices. The receiver sends acknowledgements, messages saying which data arrived. The sender keeps track of data still waiting for an acknowledgement. It cannot always send unlimited data just because the access link is fast. Receiver limits, congestion control and the time taken for acknowledgements to return all affect performance.

Imagine a long delivery route: to keep deliveries arriving steadily, several packages must be on the road at once. A network has a similar need for data sent but not yet acknowledged, called data in flight. The bandwidth–delay product estimates how much is needed to keep a path occupied. At 100 Mb/s and a 0.1-second round trip, the product is 10 megabits, or 1.25 MB. That is an illustrative pipeline calculation, not a recommendation for manually changing a device’s settings. IETF RFC 6349 explains its role in TCP throughput testing.

TCP also adjusts its sending behaviour as it learns about a path and responds to congestion. The classic slow-start and congestion-avoidance mechanisms are documented in RFC 5681. Implementations and algorithms vary, but the broader lesson survives: achievable throughput depends on a conversation between endpoints, not only on the capacity printed on one link.

A webpage has more than one clock

A browser may need to look up a domain name, establish a connection, agree on an encrypted connection and wait for a server response before it can display useful content. Receiving the files is followed by work inside the browser: interpreting content, applying styles and rendering the page. Existing connections and cached resources can change which stages are needed.

MDN’s navigation and resource timing guide explains how these stages can be measured separately. A page that feels slow is therefore not, by itself, evidence that its broadband link lacks capacity. The delay may lie in a different stage.

A content delivery network addresses part of this problem by storing suitable content on distributed servers nearer users. Cloudflare describes how caching and shorter journeys improve delivery. This changes where a request can be answered; it does not make light travel faster.

Ask which kind of faster matters

Even delay is not captured completely by one average. Packets can arrive with different delays, a variation often discussed as jitter. RFC 3393 defines an IP packet delay-variation metric. A bulk-transfer rate alone says little about that variability or about the wait to a particular destination.

Use the controls below to separate the questions. Increase the data rate while holding distance fixed: ideal transfer time falls, but propagation delay stays put. Then shorten the path: the round trip falls too. The animation illustrates sequence only, not real travel speed.

A better connection can deliver more information, start responding sooner, or behave more consistently. Those are different improvements worth asking for. Once they are separated, “faster internet” becomes a useful engineering question: which part of the wait can actually be shortened?