You type example.com, press Enter, and a page appears. It feels like one action. It's actually a relay race with at least six runners, spread across several machines, sometimes several continents, and every one of them can drop the baton.

This is the classic interview question, but I don't care about it for interviews. I care because when someone says "the site is slow", the useful answer is almost never "the site". It's one specific runner in that race. If you have the whole route in your head, you know where to look.

So let's follow one request from the keyboard to the pixels, and at each step note where the slowness hides.

Step 0: The browser checks what it already knows

Before touching the network, the browser asks itself a few questions. Is this a URL or a search? Should it be https://? (If the site sent an HSTS header before, the browser upgrades to HTTPS without even trying plain HTTP.) Do I have a fresh copy of this page in cache? Is there a service worker that wants to answer instead?

The fastest network request is the one that never happens. Good cache headers are the reason a returning visitor can load your page much faster than a first-time one.

Step 1: DNS turns a name into an address

Computers don't connect to names, they connect to IP addresses. So the browser needs to turn example.com into something like 203.0.113.10.

It checks its own cache, then the operating system's cache. If neither knows, the question goes to a recursive resolver, usually run by your ISP or a public service. If the resolver doesn't have it cached either, it walks the tree:

1. It asks a root server: "Who handles .com?"
2. It asks the .com servers: "Who handles example.com?"
3. It asks the domain's authoritative server: "What's the address?"

The answer comes back with a TTL (time to live), which tells everyone how long they may cache it.

Where it gets slow: a cold lookup can take several round trips. That's why each extra third-party domain on your page (fonts, analytics, a chat widget) costs a little. Each one is another lookup, and as we'll see, another connection.

Step 2: TCP opens a connection

Now the browser knows where to go. For classic HTTP/1.1 and HTTP/2, it opens a TCP connection with the famous three-way handshake:

• Browser: SYN ("can we talk?")
• Server: SYN-ACK ("yes, can you hear me?")
• Browser: ACK ("yes")

That's one full round trip before a single byte of your page is requested. On a fast local network, nothing. Between Doha and a server in the US, very noticeable.

Where it gets slow: distance. No code optimisation beats the speed of light. This is the main reason CDNs exist: they put a server physically closer to the user so every round trip is shorter.

Step 3: TLS makes it private

For HTTPS, the browser and server now agree on encryption. The server presents its certificate, the browser checks it was issued by a certificate authority it trusts and that it matches the domain, and both sides derive shared keys.

With TLS 1.3, this takes one extra round trip (older TLS 1.2 needed two). Reconnecting visitors can sometimes skip part of it with session resumption.

HTTP/3 goes a step further. It runs over QUIC, which uses UDP and folds the transport and encryption handshakes together, so there are fewer round trips before the first request.

Where it gets slow: again, round trips. Also, a misconfigured server that sends an incomplete certificate chain can make some clients do extra work or fail outright.

Step 4: The HTTP request

Finally, the browser asks for the page:

GET / HTTP/1.1
Host: example.com
Accept: text/html
Cookie: session=abc123
User-Agent: Mozilla/5.0 ...

(HTTP/2 and HTTP/3 send the same information in a compact binary form, but the idea is identical.) Notice the cookies: they ride along with every request to that domain, which is one reason giant cookies are a bad idea.

Step 5: The server does its work

This is the part we developers usually own. A typical path for a Laravel app looks like this:

1. A load balancer or reverse proxy (often Nginx) receives the request.
2. It passes it to PHP-FPM, which boots the framework.
3. Middleware runs: sessions, authentication, CSRF.
4. The controller runs, queries the database, maybe calls an external API.
5. A view is rendered and the HTML is sent back with a status code and headers.

Where it gets slow: this is what Time To First Byte (TTFB) mostly measures. N+1 queries, a missing index, a synchronous call to a slow third-party API, or sending an email inside the request instead of queuing it. If TTFB is high, the problem is almost certainly here, not in the frontend.

Step 6: The browser turns bytes into pixels

The HTML arrives, and the browser starts working before the whole document has even downloaded:

• It parses HTML into the DOM.
• It finds CSS and builds the CSSOM. Rendering waits for CSS, because painting unstyled content and then restyling it would look broken.
• When it meets a plain <script> tag, HTML parsing stops until that script downloads and runs. defer and async exist to avoid exactly this.
• It combines DOM and CSSOM, works out the layout (where everything goes), then paints and composites the result on screen.

Every image, font and script it discovers along the way triggers its own mini version of steps 1 to 5.

Where it gets slow: render-blocking CSS and scripts, huge JavaScript bundles that must be parsed and executed, web fonts that hide text while loading, and images with no dimensions that make the layout jump around.

The cheat sheet

One mental model to keep

Think of it as find → connect → secure → ask → work → draw. When a page is slow, open the Network tab in your browser's dev tools and look at the timing breakdown of the main request. It literally shows DNS, connection, TLS, waiting (TTFB) and download as separate bars. The longest bar tells you which runner dropped the baton.

Most of the time, in my experience, it's "work". But not always, and that's exactly why it's worth knowing the whole route.

Which of these steps has surprised you the most when you were chasing a slow page?