Why a fast link can feel slow
Trace a fictional slow page through several distinct causes of delay without pretending that one speed number diagnoses them all.
Ask what kind of waiting matters
Imagine a fictional page that reacts slowly even though large downloads elsewhere complete quickly. That observation suggests separating throughput from responsiveness rather than declaring the connection uniformly fast or slow. A small dependent request can spend time waiting for a response without needing much capacity. No measurement in this example identifies the actual cause of a particular user’s delay.
Small messages can still involve noticeable waits.
A useful explanation starts by distinguishing delay from transfer rate.
Read the complete journey
- 1
Ask what kind of waiting matters
Imagine a fictional page that reacts slowly even though large downloads elsewhere complete quickly. That observation suggests separating throughput from responsiveness rather than declaring the connection uniformly fast or slow. A small dependent request can spend time waiting for a response without needing much capacity. No measurement in this example identifies the actual cause of a particular user’s delay.
Notice: Small messages can still involve noticeable waits.
Explore Latency & round trips
Why: A useful explanation starts by distinguishing delay from transfer rate. - 2
Check the first shared resource
The access link is only one part of the path, but it may become a bottleneck when several activities compete for it. Its available rate can differ from a headline service rating. Local radio conditions may also matter. Moving to a different access path can change these constraints without altering the destination service or its processing requirements.
Notice: The usable first-link capacity depends on current conditions.
Explore The access network
Why: An advertised rate does not describe every transfer at every moment. - 3
Notice packets waiting behind other work
At a busy outgoing link, packets can wait in a queue before transmission. Increasing the queue’s storage does not make that link serve packets faster, and a persistent queue can add substantial waiting. Management and endpoint feedback can help control the load. This qualitative example does not specify buffer sizes, scheduler settings, or any measured queue delay.
Notice: Queue occupancy can rise while the path stays connected.
Explore Congestion & packet queues
Why: Reachability does not imply a responsive or uncongested path. - 4
Account for feedback and recovery
Transport behaviour determines how data is sent, acknowledged, and recovered after loss. A sender may reduce its rate in response to congestion or wait for needed feedback. A receiver may impose a separate flow-control limit. These mechanisms support useful communication, but their interaction means that an empty-looking application screen does not identify one missing physical link.
Notice: Sending can pause or change rate while a connection still exists.
Explore TCP, QUIC & reliable delivery
Why: Delivery needs coordination with both the receiver and the network. - 5
Avoid a trip when reuse is valid
A suitable cached response can remove a repeated transfer or shorten the route to a serving location. Reuse must still obey the response’s rules, and validation may involve a network exchange. Caching helps the requests it can satisfy; it does not automatically remove every application dependency, personalise every response, or repair a congested connection for unrelated traffic.
Notice: Some requests can be answered with an eligible stored response.
Explore Caches & content delivery
Why: Avoiding unnecessary work can reduce a specific part of the wait. - 6
Include the work after delivery
Once resources arrive, the browser still parses, lays out, paints, and may execute scripts. A busy device or costly application work can delay interaction independently of available network capacity. The full experience may contain several overlapping bottlenecks. This journey therefore identifies questions to distinguish mechanisms, rather than promising one universal cause or adjustment for a slow page.
Notice: Visible interaction depends on local processing as well as arrival.
Explore The browser
Why: The user’s experience ends at a usable interface, beyond the packet journey.
Why might a faster access plan leave a small interactive request just as slow?
Reveal the explanation
The request may be limited by propagation, dependent exchanges, server processing, browser work, or a bottleneck elsewhere. More access capacity only changes the parts of the journey that can use it.
Sources & further reading
Original explanations informed by these sources. Diagrams are conceptual; local systems differ.
- RFC 2681: A Round-trip Delay Metric for IPPM IETF / RFC Editor; G. Almes, S. Kalidindi, and M. Zekauskas · 1999-09 · Source & rights record
- RFC 7567: IETF Recommendations Regarding Active Queue Management IETF / RFC Editor; F. Baker and G. Fairhurst (editors) · 2015-07 · Source & rights record
- RFC 5681: TCP Congestion Control IETF / RFC Editor; M. Allman, V. Paxson, and E. Blanton · 2009-09 · Source & rights record
- RFC 9293: Transmission Control Protocol (TCP) IETF / RFC Editor; W. Eddy (editor) · 2022-08 · Source & rights record
- RFC 9111: HTTP Caching IETF / RFC Editor; R. Fielding, M. Nottingham, and J. Reschke (editors) · 2022-06 · Source & rights record
- Populating the page: how browsers work MDN Web Docs / Mozilla contributors · Not stated · Source & rights record
Another way through the system.
Load a page on your phone
A request across a network of networks.
When a network path breaks
Redundancy helps only when it is usable.
Why the second visit can be faster
The trip that does not need repeating.
Send a photo while moving
Radio is the first part of a much longer trip.