Latency vs bandwidth

What it means

Latency describes delay. Bandwidth describes capacity to move data at a particular layer and along a particular path. Neither alone tells you how long a web response will take. This example uses round-trip time for delay and a separately chosen goodput for the useful body-data rate. It does not equate a connection's advertised capacity with delivered application data. Capacity terminology

Try it

Simulation — compare one wait with one transfer. Change RTT, decimal kilobytes or application goodput; save a valid result as A, then change the current B scenario. The comparison shows separate waiting, transfer and total differences, not a score for your connection.

The initial calculation is 80 + 8 × 1000 / 20 = 480 ms. Save it as A and double goodput to 40 Mbps. Transfer time falls from 400 to 200 ms, but the unchanged 80 ms wait means the total is 280 ms, not 240 ms. Then try the small, high-RTT preset and the large-transfer preset to see which term dominates.

A zero-byte response still has the modeled wait; setting both size and RTT to zero makes the modeled total zero. Goodput must remain positive. Empty, negative or out-of-range inputs produce an error rather than a plausible-looking result. Reset removes the saved comparison as well as restoring the three defaults.

These are arithmetic examples on an already available connection with constant goodput. DNS, connection establishment, TLS, server work, congestion dynamics and browser rendering are outside the model. The number is neither a page-load prediction nor a benchmark. Capacity and measured application throughput are different quantities. Capacity terminology TCP measurement limitations

Same question, different constraints

The distinction between network capacity and achieved throughput matters. A capacity figure needs a layer and a path; it is not automatically the rate available to a particular application. We therefore make the useful data rate an explicit input. Capacity terminology

Why the numbers change

Our deliberately narrow model is T = RTT + 8 × size / goodput, with time in milliseconds, size in decimal kilobytes and goodput in megabits per second. One kB is 1,000 bytes; eight bits make one byte. Converting both decimal units and seconds to milliseconds gives the factor of eight.

At the default settings, 1,000 kB at 20 Mbps needs 400 ms of transfer time. Add 80 ms of RTT and the model gives 480 ms. Doubling goodput halves the transfer portion, not the whole total. Setting the body size to zero leaves the RTT term. These values are arithmetic examples, not performance promises.

In practice

Use the controls to distinguish two hypotheses: “the response is small but starts slowly” and “the response starts promptly but contains a lot of data.” In this model, reducing RTT helps the first situation; increasing goodput or reducing size helps the transfer portion. The comparison has no universal winner.

Actual TCP throughput can depend on RTT, congestion and receive windows, loss and other conditions. Holding goodput independent of RTT is a teaching simplification, not a claim about TCP behavior. TCP throughput

About the boundary

Assume an already established connection, one response body, constant positive goodput and no separate server-processing time. DNS, connection/TLS setup, request bytes, headers, slow start, retransmissions, competing requests and browser rendering are not separately modeled. The formula is our two-term teaching model; RFC 6349 is context for TCP behavior, not its source.

Key takeaways

Ask whether a task is dominated by waiting or moving bytes before choosing a remedy. Compare one changed condition at a time and keep the units explicit. A larger bandwidth figure does not remove latency, and a faster result in this bounded calculation does not prove a faster real website.