Latency, Bandwidth, and the Speed of Light

The Number One Lie in Web Performance

"Just get faster internet." This is what most people think when a website feels slow. More bandwidth. Bigger pipe. The truth? For modern web applications, bandwidth almost never matters. Latency almost always does.

A 100 Mbps connection and a 1 Gbps connection will load the same webpage in roughly the same time. The HTML is 50KB. The CSS is 30KB compressed. The critical JS is 80KB. Even at 100 Mbps, those transfer in under 15ms. But if the server is 5000km away, the speed of light guarantees at least 50ms of latency per round trip — and with DNS, TCP, TLS, and HTTP, you're looking at 4-6 round trips before the first useful pixel appears. That's 200-300ms of pure waiting, regardless of bandwidth.

Bandwidth is for throughput. Latency is for responsiveness. And for web apps, responsiveness is everything.

The Mental Model

The Speed of Light: The Hard Floor

Light in a vacuum travels at 299,792 km/s. But we don't have vacuum cables. Light in fiber optic cable travels at roughly 200,000 km/s (about 2/3 the speed of light, due to the refractive index of glass).

Let's do the math for a round trip:

These are theoretical minimums — the speed of light through fiber, with no routing, switching, or processing delays. Real-world RTTs are 1.5-3x higher because packets travel through routers, switches, and don't follow a straight path.

Actual measured RTTs (typical):

Latency vs Bandwidth: When Each Matters

Bandwidth Matters For:

• Video streaming — Netflix needs sustained throughput (5+ Mbps for HD, 25+ for 4K)
• Large file downloads — transferring a 2GB file over 10 Mbps takes 27 minutes. Over 100 Mbps: 2.7 minutes
• Backup and sync — cloud storage uploads are bandwidth-limited
• Bulk data transfer — API responses returning megabytes of data

Latency Matters For:

• Web page loads — dominated by round trips (DNS, TCP, TLS, HTTP) not data volume
• API calls — a 2KB JSON response needs under 1ms of transfer but 50-200ms of round trip
• Interactive applications — every user action triggers a round trip to the server
• Real-time features — chat, collaboration, gaming need sub-100ms latency
• Search — each keystroke might trigger a request; 200ms latency makes autocomplete feel broken

For typical web applications, the bottleneck is almost always latency, not bandwidth. The critical resources (HTML, CSS, key JS) are small. The problem is the number of sequential round trips required to fetch them.

The Math That Proves It

Consider loading a page with 200KB of critical resources (HTML + CSS + JS, compressed):

Going from 10 Mbps to 1 Gbps saves 158ms. Reducing latency from 100ms to 20ms RTT saves 320ms (4 x 80ms). Latency reduction has 2x more impact, even with the slowest broadband connection.

And on mobile with high latency (200ms RTT):

The 5G speed boost comes largely from lower latency, not just higher bandwidth.

Practical Strategies to Fight Latency

You can't speed up light. But you can reduce the distance it travels and the number of trips it makes.

1. CDNs: Reduce Distance

Put your content close to users. A CDN with edge nodes in 200+ cities means the nearest server is typically within 50km — reducing RTT from 100ms+ to under 10ms.

<!-- Serve static assets from CDN edge -->
<link rel="stylesheet" href="https://cdn.example.com/style.a8f3e2.css">

2. Reduce Round Trips

Every sequential round trip is latency you can't hide:

• DNS prefetch + preconnect — start DNS/TCP/TLS early, in parallel with HTML parsing
• HTTP/2 multiplexing — one connection for all requests, no connection queuing
• HTTP/3 (QUIC) — 1 RTT handshake instead of 2 (TCP + TLS)
• Inline critical CSS — eliminate the round trip to fetch CSS
• Server-side rendering — send ready HTML, no round trip for client-side data fetching

3. Preconnect and Prefetch

Tell the browser to start connections and fetch resources before they're needed:

<!-- Complete DNS + TCP + TLS for critical origins -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

<!-- Resolve DNS for less-critical origins -->
<link rel="dns-prefetch" href="https://analytics.example.com">

<!-- Fetch resources the next page will need -->
<link rel="prefetch" href="/next-page-bundle.js">

<!-- Preload resources the current page needs ASAP -->
<link rel="preload" href="/critical-font.woff2" as="font" type="font/woff2" crossorigin>

4. Connection Reuse

Avoid paying the handshake cost multiple times:

• HTTP/2 — single connection per origin, all requests multiplexed
• Keep-alive — connections persist across requests (HTTP/1.1 default)
• Connection pooling — browsers maintain a pool of connections to recently visited origins

5. Edge Computing

Move computation closer to the user. Instead of a user in Tokyo hitting a server in Virginia:

Without edge:  Tokyo user → Virginia server (180ms RTT) → response
With edge:     Tokyo user → Tokyo edge (5ms RTT) → response (for cacheable/edge-computable data)

Edge functions (Cloudflare Workers, Vercel Edge Functions) can handle authentication, personalization, A/B testing, and API routing with sub-10ms latency.

6. Reduce Payload Size (Latency * Bandwidth Interaction)

TCP slow start means the first data round trip carries only ~14KB. Keeping critical resources small reduces the number of round trips needed to transfer them:

50KB compressed → 4 slow start round trips
14KB compressed → 1 slow start round trip

That's 3 fewer round trips. At 100ms RTT, that's 300ms saved.

Measuring Latency

Browser DevTools

Chrome DevTools Network tab shows per-request timing breakdown:

• Queueing — waiting for an available connection
• DNS Lookup — DNS resolution time
• Initial Connection — TCP handshake time
• SSL — TLS handshake time
• Waiting (TTFB) — Time to First Byte — includes server processing + round trip
• Content Download — actual data transfer time

TTFB is the most telling metric. If TTFB is high but Content Download is fast, the problem is latency and/or server processing, not bandwidth.

Key Performance APIs

const timing = performance.getEntriesByType('navigation')[0];

console.log('DNS:', timing.domainLookupEnd - timing.domainLookupStart);
console.log('TCP:', timing.connectEnd - timing.connectStart);
console.log('TLS:', timing.secureConnectionStart > 0
  ? timing.connectEnd - timing.secureConnectionStart : 'N/A');
console.log('TTFB:', timing.responseStart - timing.requestStart);
console.log('Download:', timing.responseEnd - timing.responseStart);

Common Mistakes

Key Takeaways