Out of Loop

What Happens When You Type a URL

Following one request from the address bar to the first pixel.

You type example.com into the address bar and press Enter. A fraction of a second later, a page appears.

It feels instant, but in that moment your browser has looked up an address, opened a connection, agreed on encryption, asked for a file, and turned text into pixels. Let's slow things down and follow that single request from start to finish.

Real browsers cache and reuse almost everything you'll read about here, so most visits skip several of these steps. We'll follow a first visit, where nothing is cached yet.

Finding the server

Computers on the internet don't find each other by name — they use IP addresses like 93.184.215.14. So the first job is to turn example.com into an address, using the Domain Name System (DNS).

Your browser asks a DNS resolver, which may in turn ask a chain of other servers: the root servers point it to the .com servers, which point it to the servers responsible for example.com, which finally answer with the address.

$ dig +short example.com93.184.215.14

Opening a connection

With an address in hand, the browser opens a TCP connection to the server. TCP makes sure data arrives complete and in order, and it starts with a three-step handshake:

client → server   SYN       "Can we talk?"server → client   SYN-ACK   "Sure, can you hear me?"client → server   ACK       "Loud and clear."

Because the URL is served over HTTPS, a TLS handshake follows. The server proves its identity with a certificate, and the two sides agree on keys to encrypt everything that comes next.

Problem

Each handshake is a round trip across the network. How much of our wait is spent just getting ready to ask for the page?

Asking for the page

Finally, the browser sends an HTTP request:

GET / HTTP/1.1Host: example.comAccept: text/html

The server does whatever it needs to — read a file, query a database, render a template — and responds with a status code, some headers and the HTML itself:

HTTP/1.1 200 OKContent-Type: text/html; charset=UTF-8Cache-Control: max-age=3600<!doctype html><html>…

The time between sending the request and receiving the first byte of the response is called Time to First Byte, or TTFB. It's often the largest single slice of the wait.

Where the time goes

Put it all together and a first request looks something like the waterfall you'd see in your browser's DevTools:

phase0ms200ms400mstime
  1. DNS lookup24ms
  2. TCP handshake32ms
  3. TLS handshake48ms
  4. Waiting (TTFB)118ms
  5. Download36ms
  6. Parse & render142ms
An illustrative waterfall for a first visit. Real timings vary wildly with distance, network and server.

A good chunk of the time passes before the server has even seen the request. That's why techniques like CDNs (moving servers closer), connection reuse and HTTP/3 (fewer round trips) make such a noticeable difference.

From HTML to pixels

Receiving the HTML is only half the story. The browser now has to turn it into something you can see:

  1. Parse the HTML into the DOM, a tree of every element on the page.
  2. Fetch and parse CSS into the CSSOM, a tree of styles. Each stylesheet, script and image is another request like the one above.
  3. Combine them into a render tree containing only the visible elements.
  4. Layout: work out the exact size and position of every box.
  5. Paint: fill in the pixels — text, colors, borders, images.

JavaScript can interrupt this process at almost any point, which is why a slow script in the wrong place can hold up the whole page.

The short version

So what happens when you type a URL? The browser finds the server, shakes hands twice, asks politely for a file, and then does a remarkable amount of work to draw it. All in the time it takes you to blink.