Learning on Web Dev Open is free for all.

Take It Apart > What the browser actually doesFrom a URL to a pixel
Phase 01What the browser actually does31 of 434

From a URL to a pixel

DNS, TCP, TLS, request, response, parse, paint. The order matters, and so does the fact that most of it happens before your code exists.

Concept18 minAI pair

A DNS lookup turns a name into an address. Your machine asks a resolver, the resolver asks the root, then the registry, then the authoritative nameserver, and caches the answer for as long as the TTL says. Cold, that is anywhere from twenty to a hundred and twenty milliseconds. Warm, it is zero, so measuring your own site after you have loaded it forty times tells you almost nothing about what a stranger experiences.

Then a TCP connection opens, which is one round trip, and TLS negotiates on top of it, which is one more on TLS 1.3 and two on 1.2. Notice the unit: round trips, not milliseconds. A round trip to a server in the same city is about 10ms; to one on another continent it is 150ms or more, and no amount of server-side optimisation changes the speed of light. This is one reason a CDN is not a micro-optimisation, it is the only thing that makes those numbers smaller.

Only now does the actual HTTP request leave your machine. The server thinks for a while and the first byte comes back. That interval is Time To First Byte, and it is the number that separates a slow host from a slow page. A static file on a good CDN answers in 30ms; an unoptimised database query behind a cold serverless function can take two seconds before a single byte of your beautiful HTML has moved.

The response streams in, and the browser starts parsing before it has finished arriving. This is the moment everything changes hands. Everything after this point is yours: how much HTML there is, what it references, in what order, and how much work the browser has to do before it can show anything. Everything before it belongs to your host, your DNS provider and physics.

Drive the waterfall below through all four connection presets. Watch the number at the bottom, the share of total time your code can actually influence. On fibre with a warm cache it is most of it. On a cold 3G connection from the other side of the world it collapses to under a quarter, and the entire performance conversation changes from "make the JavaScript smaller" to "get the bytes closer".

What happens between Enter and the first pixel

451 ms total
both are the host’s settings, not your code
Waterfallyoursnot yours
DNS24
TCP26
TLS26
Request13
TTFB93
Download139
Parse130
Totalfirst pixel on screen451
Against the slowest run this model can produce6.77 s
Your code controls 2 of these 7 phasesabout 60% of the 451 ms on this connection

Click any bar to find out what that phase is and whether anything you write can change it. Then change the connection and watch the percentage move.

Model, not a measurement: round-trip times and CPU costs typical of each connection class, against a 780 KB page (180 KB when most of it is already cached). Real numbers vary; the proportions do not.

Change the connection and watch which bars you own. The percentage at the bottom is the clearer version of "is this worth optimising".

One consequence useful to remember: the first visit and the second visit are different products. Cold, you are fighting DNS, TLS and an empty cache. Warm, none of that exists and your own code is the whole cost. Most developers only ever experience the warm path, on a fast laptop, on the same continent as the server, which is how sites that feel instant in development take eleven seconds in the field.

Worth reading

You should now be able to

  • Trace a request from DNS lookup to first paint
  • Say which steps your code can affect and which it cannot
  • Estimate where the time goes on a cold mobile connection
  • Explain why measuring your own site on your own laptop flatters it
Ask the community

Loading…