What happens when you load a page

Press enter, count to one, and the page is there.

It reads as a single action, the way a light switch does. It isn't one. Between the keypress and the first pixel sit five or six separate systems — naming, connecting, encrypting, transferring, parsing, drawing — built by different people in different decades to solve problems the others know nothing about, handing work along in a fixed order.

Follow that order once and a great deal of everyday computing stops being mysterious. Including the security warnings you get asked to make a judgement about, usually while in a hurry.

First the name has to become a number

Nothing on the network can find anything by name. Machines route to IP addresses — numeric labels identifying a destination — and names exist only because people won't memorise numbers.

So step one is a translation. Your browser hands the name to a resolver, normally run by your internet provider or by one of the big public services, and asks which address it corresponds to. If that resolver has seen the name recently, it answers from memory and the step costs essentially nothing. Most of the time that's what happens. The full lookup described below is the uncommon case, not the normal one, which is why people rarely notice DNS existing at all until the day it stops.

With no cached answer, the query climbs a hierarchy. It starts at a root server, which doesn't know the address but knows who's responsible for .com, or .uk, or .org. That server doesn't know either, but knows which nameservers are authoritative for the specific domain. Those return the address. Three or four questions, each one a round trip, and then everybody caches the result for as long as the record's time-to-live permits.

There are thirteen root server addresses, lettered A to M, which sounds alarmingly few for a planet. They aren't thirteen machines. Each address is announced from hundreds of physical locations at once using anycast routing, so your query lands at whichever copy the network thinks is nearest. The number thirteen is a fossil: it's how many entries fitted inside a single early DNS response packet.

A surprising share of outages are really DNS outages, and they present confusingly, because the symptom is nothing happening. The servers are up. Your connection is fine. The name simply doesn't resolve, so no connection is ever attempted. When a large site disappears for an hour and the post-mortem eventually arrives, DNS is very often somewhere in it.

Then something has to open a connection

Address in hand, your device opens a connection to that machine. For most of the web's life the protocol doing this has been TCP, whose central promise is reliability: what you send arrives complete and in order, or the sender finds out it failed.

That promise isn't free. The network underneath makes no such guarantee — packets get lost, duplicated, or turn up out of sequence — so TCP builds order on top of chaos using sequence numbers, acknowledgements and retransmission. It opens with a three-step handshake. Your machine says hello, the server says hello back, your machine confirms. Only then can anything useful travel.

Each of those steps is bounded by distance, and distance is where the time goes.

There's a second thing TCP does that catches people out. A fresh connection doesn't start at full speed — it starts deliberately slowly and accelerates, because the sender has no idea yet what the path between you can take. That's called slow start, and the opening burst is around ten packets, near enough fourteen kilobytes. A small page fits inside that first burst and feels instant. A page that doesn't fit has to wait for an acknowledgement before more can be sent, and you've paid for another round trip.

Then the whole thing gets encrypted

If the address begins with HTTPS, another negotiation happens before a single byte of content moves. The server presents a certificate: a document, signed by an authority your device already trusts, asserting that this machine really is the one for that name.

Your browser checks the signature, and checks the signature on the certificate that signed it, walking up a short chain until it reaches a root certificate shipped with your operating system or browser. If the chain validates, both ends agree on keys and everything afterwards is scrambled in transit. If it doesn't validate, you get the warning page people have become so practised at clicking through.

Be precise about what that padlock claims, because a lot of security advice has muddled it. It says you're talking to whoever controls that domain name, and that nobody in between can read or alter the traffic. It says nothing whatever about whether the site is honest. A fraudulent site can hold a perfectly valid certificate, and essentially all of them do, because certificates became free in 2015 and getting one is now automated. The padlock means the channel is private. It has never meant the destination is trustworthy.

The handshake used to cost two extra round trips on top of TCP's one. TLS 1.3, finished in 2018, cut that to one, and a reconnection to a server you've spoken to before can carry data in the very first packet. Encryption used to be the thing you switched off when you wanted speed. That argument is over.

Only now does anything get asked for

Everything so far has been setup. The actual request is a short block of text: a method, the path of the thing you want, and headers describing your browser, the languages you'll accept, and any cookies for that site.

The server replies with a status code and usually some content. Those codes leak into ordinary life and are worth being able to read. 200 is success. 301 and 302 mean the thing has moved, permanently or otherwise. 304 means your copy is still good, don't download it again. 404 means the server understood the request perfectly and has nothing at that address. 500 means the server hit its own error, which is a genuinely useful distinction — a 404 says your address is wrong, a 500 says the far end is broken and there's nothing you can do about it.

There's also 418, "I'm a teapot", which came from an April Fools' specification in 1998 and has stubbornly refused to die.

HTTP got rewritten twice, and the advice changed with it

The version that carried the web for its first two decades, HTTP/1.1, handled one request at a time per connection. Browsers worked around that by opening around six connections to each host, and developers worked around it further by scattering assets across multiple subdomains and gluing dozens of small images into one big sprite sheet. Both were ugly, and both were rational.

HTTP/2 arrived in 2015 and multiplexed many requests over a single connection, along with compressing the headers, which had grown repetitive and fat. The workarounds didn't just become unnecessary — they became actively harmful, since every extra subdomain reintroduces a DNS lookup and a handshake. A decade of received wisdom inverted more or less overnight, and plenty of sites are still carrying the old tricks.

One problem survived. Streams shared a single TCP connection, and TCP insists on delivering bytes in order, so one lost packet stalls everything behind it even when the other streams are complete and sitting in a buffer. That's head-of-line blocking, and it's exactly the sort of thing you can't fix from above.

HTTP/3, standardised in 2022, fixes it by abandoning TCP. It runs on QUIC, which rebuilds ordering, reliability and encryption on top of UDP, per stream rather than per connection, so a lost packet only stalls the stream it belonged to. QUIC also folds the encryption handshake into connection setup, so a new connection can be ready in one round trip instead of three. A good fraction of the traffic your browser handles today is already running this way without anything on screen mentioning it.

The page arrives as instructions, not as a picture

What comes back isn't an image of a page. It's HTML — a text document describing structure. This is a heading. This is a paragraph. This is a link, pointing there.

The browser reads it top to bottom and builds an internal model called the DOM. The stylesheets get parsed into a parallel model of the styling rules. Those two get combined into a render tree of everything actually visible, and then the browser works out geometry: how wide is this box, where does that line of text wrap, what pushes what down the page. That stage is layout, and it's the expensive one. Then it paints pixels, and composites the painted layers together, usually on the graphics card.

Two things in that pipeline block progress, deliberately.

CSS blocks rendering, because drawing the page unstyled and then restyling it looks far worse than a short wait. And a plain script tag stops the parser dead, because a script is allowed to rewrite the document underneath it, so the browser daren't carry on guessing. Marking scripts as defer or async releases that brake, which is why the advice about script placement has always been so fussy.

Browsers cheat around the pause. While the parser sits blocked on a script, a separate lightweight scanner races ahead through the raw HTML hunting for images, stylesheets and fonts it can start downloading immediately. It's one of the biggest single wins in modern browser performance, and nobody outside the field has heard of it.

All of which is why pages sometimes flash unstyled, or shuffle themselves about as they finish. You're watching stages land out of order: structure first, appearance a moment behind, behaviour later still, and an image whose dimensions weren't declared arriving last and shoving everything down a hundred pixels just as you go to tap something.

Bandwidth is not the thing that's slow

Connections are sold in megabits per second, and that number explains less about how fast a page feels than almost anyone expects. Bandwidth is how much can travel at once. Latency is how long one round trip takes. Loading a page involves dozens of round trips, and no amount of bandwidth shortens the time light needs to cross an ocean.

Light in glass is slower than light in vacuum — roughly two-thirds the speed, about 200,000 kilometres per second, because of how the fibre refracts it. London to New York is about 5,500 kilometres in a straight line and rather more by cable, which puts the best achievable round trip somewhere near 70 milliseconds. No upgrade fixes that. It's geography.

Geostationary satellite internet is the extreme case. The orbit sits 35,786 kilometres up, so a signal to the satellite and down again covers more than 70,000 kilometres, and a request plus its answer does that twice. Half a second gone before anything has been computed, on a link that may well have excellent throughput. It's the cleanest demonstration going that speed and responsiveness are different quantities.

Plenty of the delay isn't the network at all. The browser parses some HTML, discovers it needs a stylesheet, asks for it, waits, then finds fonts and images referenced inside that stylesheet and has to ask again. Each discovery is another trip. Which is why so much web engineering is about reducing the number of trips rather than the size of what travels, and why the order of things inside a document affects how quickly it appears.

What a CDN is actually for

A content delivery network gets described as "making websites faster", which is true and nearly useless. What it does is keep copies of a site's files on servers in many countries, so requests get answered by a machine near the person asking instead of by the origin server wherever that happens to live.

The gain is mostly latency, and by now you can see why that matters more than it sounds. If the origin is in Virginia and the reader is in Singapore, every round trip crosses the Pacific. If a cached copy sits in Singapore, none of them do. For files that rarely change this is straightforward. For pages that differ per visitor it's much harder, which is why sites separate the two so carefully.

The same logic explains your browser's own cache. The fastest possible request is the one that never happens.

Which leaves the awkward part: knowing when a cached copy has gone stale. The usual answer is not to try. Instead of hoping an old file expires, sites put a hash of the contents into the filename, so a changed file is simply a different file with a different name and the old one can be cached more or less forever. It's a neat sidestep of a problem that's otherwise genuinely hard.

Nearly all of this is old

The striking thing, once the sequence is laid out, is the age of the machinery.

The core routing protocols come from the 1970s, and the network completed its switch to them on the first of January 1983. DNS was designed that same year, by Paul Mockapetris, to replace a single text file of every host name on the network that was being copied around by hand and had stopped scaling. The web itself was proposed at CERN in March 1989, and in April 1993 CERN put the whole thing into the public domain — no patent, no licence fee, no permission needed. That single decision shaped more of what followed than any piece of the technology did.

None of it has been replaced, only extended, and the reason is that each layer was built to know as little as possible about the others. TCP doesn't care what it's carrying. HTTP doesn't care how packets are routed. That indifference is why the system absorbed video, encryption, mobile phones and an entire replacement transport protocol without anyone having to rebuild it.

It also explains why the internet and the web aren't the same thing, though the words get swapped constantly. The internet is the network. The web is one service running on top of it, sharing the pipes with email, video calls, app traffic and a great deal else.

Which part just broke

The practical payoff of knowing the order is being able to place a failure in it.

• Nothing happens at all, no error page, or the browser complains it can't find the server — the name never resolved. That's DNS.
• "Connection refused" or a long hang before the timeout — the name resolved fine and the machine at that address isn't answering.
• A full-page security warning — the connection worked and the certificate didn't check out. Expired, wrong name on it, or something in between you'd rather not have there.
• A 404 — everything worked perfectly and you're asking for something that doesn't exist.
• A 500, 502 or 503 — everything worked and the far end is broken. Refreshing occasionally helps and mostly doesn't.
• The page turns up but sits blank, or arrives naked and restyles itself — the transfer succeeded and rendering is where the time's going.

That's the difference between having a vague sense that it all works somehow, and being able to say which of six systems is having a bad day.