Skip to content
Browser Lab · LAB-01DNS / TCP

What happens when you load a URL?

The interview question, run as an actual experiment: every hop, with a stopwatch on it.

Level
ENGINEER
Read time
14 min
Experiment
Available
Type
SIMULATION

The question

Between pressing Enter and seeing content, how much of the delay is network, how much is the server, and how much is your own JavaScript?

Hypothesis

On a typical connection the first paint is dominated by round trips, not by bandwidth, and the interactive delay is dominated by script execution, not by transfer.

Method

Laboratory available

The instrument for this investigation runs in the laboratory, where the controls, the live model and the observation log share one workstation.

Enter the laboratory

Set the distance to the server, the protocol and the cache state. The bench animates each packet and reports the time budget of every phase.

Protocol

  1. 01Start on a cold cache, HTTP/1.1, server on another continent. Note the total.
  2. 02Switch to HTTP/2 and watch what changes, and what does not.
  3. 03Move the server to an edge location 20ms away. Compare the handshake cost.
  4. 04Enable a warm connection and observe how many round trips disappear.

What we observed

PhaseRound tripsNotes
DNS0 to 2Often cached at the OS or resolver
TCP handshake1SYN → SYN-ACK → ACK
TLS 1.3 handshake1TLS 1.2 needed 2; 0-RTT resumption can reach 0
QUIC (HTTP/3) first connection1Transport and crypto handshake are combined
HTTP request → first byte1Plus server think time
Round trips before the first byte of HTML (cold connection)

At 150ms of latency, three round trips are 450ms spent before the server has even read your request line. This is why the single most effective 'performance optimisation' is often moving the origin closer, not shrinking the payload.

Why it happens

The journey

  1. 01URL parsing and scheme handling; HSTS may upgrade http:// to https:// with no network at all.
  2. 02DNS resolution: OS cache → resolver → recursive lookup.
  3. 03TCP (or QUIC) connection established to the resolved address.
  4. 04TLS handshake: certificate verification, key agreement, ALPN negotiates the HTTP version.
  5. 05The request is sent; the server responds with headers, then the HTML body.
  6. 06The HTML parser starts building the DOM incrementally as bytes arrive.
  7. 07Subresources are discovered, the preload scanner fetches them ahead of the parser.
  8. 08Render-blocking CSS must arrive and be parsed before the first paint.
  9. 09Scripts execute, hydration runs, and the page becomes interactive.
example.htmlhtml
<script src="a.js"></script> <!-- blocks the parser --><script src="b.js" defer></script> <!-- parse continues, runs in order --><script src="c.js" async></script> <!-- parse continues, runs ASAP --><script src="d.js" type="module"></script><!-- deferred by default -->
Four very different loading behaviours

CSS is render-blocking but not parser-blocking, except that a script cannot run until pending stylesheets have loaded, because a script may read computed styles. That coupling is why a slow stylesheet can delay a script that has nothing to do with it.

Further research

TCP slow start means bandwidth is not available immediately. A new connection begins with a congestion window of roughly 10 segments (~14KB) and doubles each round trip. That is the real reason for the 'first 14KB' rule of thumb: whatever fits in the first flight arrives one round trip sooner than everything else.

References

  1. 01MDNPopulating the page: how browsers work
  2. 02web.devCritical rendering path
  3. 03IETF / QUIC WGHTTP/3 explained