Tags: web-dev concept

Latency and Bandwidth

Date: 2026-08-17

---

Bandwidth is how much data fits down the pipe; latency is how long one trip takes. Bandwidth has improved enormously and latency has barely moved — which is why most pages are slow for reasons that adding megabits cannot fix.

---

Bandwidth is throughput — bytes per second. Latency is delay — time for one round trip, usually measured as RTT (round-trip time).

BANDWIDTH   how WIDE the pipe is
LATENCY     how LONG the pipe is

Why latency doesn’t improve

Bandwidth is an engineering problem — better hardware, more spectrum, more fibre. Latency is bounded by physics.

London → New York        5,500 km
speed of light in fibre  ~200,000 km/s
                         ─────────────
theoretical minimum      ~28ms one way
                         ~55ms round trip
actual, with routing
and switching            ~75–90ms

Nobody will ever make that meaningfully faster. Bandwidth has increased by orders of magnitude in twenty years; RTT to a given city is roughly what it was.

The consequence for page loads

A page load is mostly round trips, not transfer:

COLD CONNECTION, RTT 100ms

DNS                    1 RTT   100ms
TCP handshake          1 RTT   100ms
TLS handshake        1–2 RTT   100–200ms
HTTP request+response  1 RTT   100ms
                              ─────────
before a byte of HTML         400–500ms

None of that is affected by bandwidth. Doubling the connection speed changes it by nothing.

100 KB page

on 5 Mbps, RTT 100ms      ~700ms
on 50 Mbps, RTT 100ms     ~550ms
                          ↑ 10× bandwidth,
                            ~20% faster

on 5 Mbps, RTT 20ms       ~250ms
                          ↑ 5× lower latency,
                            ~3× faster

Latency dominates for typical page weights. Bandwidth only becomes the constraint on large transfers — video, big images, huge bundles.

Where the round trips hide

each new HOSTNAME        DNS + TCP + TLS
each REDIRECT            a full extra RTT
each sequential API call one RTT
                         each
await in a loop, n items n RTTs

// sequential — 300ms
await a()
await b()
await c()
 
// parallel — ~100ms
await Promise.all([a(), b(), c()])

Same bytes, a third of the time — Async Models, N+1 Queries.

What actually reduces latency

• Get physically closer. A CDN is a latency optimisation, not a bandwidth one — the bytes travel less far — Content Delivery Networks
• Remove round trips. Fewer hostnames, no redirect chains, batched API calls
• Reuse connections. Keep-alive and HTTP/2 multiplexing avoid repaying handshakes — HTTP Versions
• Start early. preconnect pays the handshake during idle time; 103 Early Hints starts subresource fetching before the HTML is ready
• Cache. A cache hit has zero round trips, which beats every other optimisation — HTTP Caching

Bandwidth still matters where it matters

Don’t over-correct. Bandwidth is the constraint for large payloads, and on mobile it’s also a cost and battery question:

• Images, which are usually the largest thing on a retail page — Image Optimisation
• Video
• Very large JavaScript bundles
• Unbounded API responses

Compression is a bandwidth optimisation, and Brotli over gzip is a real saving on text.

The testing implication

Your connection is not representative. Office fibre with sub-20ms RTT hides every latency problem in the product.

test at            because
Slow 4G            RTT ~150ms+, real users
throttled CPU      mid-range Android
a distant region   if you serve one

Field data is the arbiter, not lab data — real users are distributed across networks you can’t simulate individually, which is why Core Web Vitals is assessed on field measurements at the 75th percentile — Core Web Vitals, Percentiles in Performance.