Latency vs Bandwidth
debt(d7/e5/b5/t7)
Closest to 'only careful code review or runtime testing' (d7). The tools listed (WebPageTest, Lighthouse) are specialist audit tools that require manual invocation and interpretation — they flag symptoms like slow page loads but won't automatically diagnose 'you confused latency with bandwidth as your bottleneck.' The detection hint explicitly notes 'automated: no,' meaning identifying the wrong optimisation target requires careful profiling and developer judgement, not an automated signal.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix points to solutions like adopting HTTP/2, adding a CDN, and restructuring serial API calls to be concurrent — these are not one-line patches. Switching from serial to parallel requests, adding keep-alive, and integrating a CDN each touch multiple layers of the codebase (HTTP client configuration, infrastructure config, request orchestration logic), amounting to a significant refactor across one or more components.
Closest to 'persistent productivity tax' (b5). The choice to optimise bandwidth instead of latency (or vice versa) shapes multiple workstreams: image optimisation efforts, API call patterns, CDN decisions, and HTTP client configuration. The applies_to covers both web and CLI contexts, meaning the wrong mental model can influence decisions across a broad surface area. It's not architectural (b7/b9), but it persistently misdirects optimisation work across many features.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field captures the exact trap: developers assume more bandwidth = faster site, which directly contradicts how latency-bound workloads behave. A 100Mbps connection with 200ms RTT is slower for small responses than a 10Mbps connection at 10ms. This is a well-documented gotcha but it strongly contradicts the intuitive model (bigger pipe = faster) making it a serious cognitive trap for competent developers.
Also Known As
TL;DR
Explanation
Latency: time for a packet to travel from source to destination — physical distance, hops, processing time. Cannot be improved beyond the speed of light. Bandwidth: maximum data transfer rate — upgradeable with better hardware. For small responses (API calls, HTML pages), latency dominates performance. A 10Mbps connection at 10ms RTT delivers a 10KB response faster than 100Mbps at 200ms RTT. HTTP/2 multiplexing and CDN reduce the impact of latency.
Common Misconception
Why It Matters
Common Mistakes
- Serial HTTP requests where parallel would reduce total time
- No HTTP keep-alive — each new connection adds one RTT
- No CDN — distant users have high latency regardless of origin bandwidth
- Optimising file sizes when connection count is the real bottleneck
Code Examples
// 10 serial API calls — each adds full RTT:
async function loadDashboard() {
const user = await fetch('/api/user'); // 100ms RTT
const orders = await fetch('/api/orders'); // 100ms RTT
const reviews = await fetch('/api/reviews'); // 100ms RTT
// Total: 300ms in latency alone
}// Parallel requests — latency is max(individual):
async function loadDashboard() {
const [user, orders, reviews] = await Promise.all([
fetch('/api/user'),
fetch('/api/orders'),
fetch('/api/reviews'),
]);
// Total: ~100ms (parallel) vs 300ms (serial)
}