What Really Happens When You Hit Enter

You’re on your phone at 11pm. Someone sends you a link. You tap it. Half a second later, a page is on your screen. You read the first sentence, scroll past the rest, and forget it ever existed.

But in those 500 milliseconds, about a dozen things happened in a very specific order. Every single one was necessary. Every single one happened silently, faster than you can blink. And if any one of them goes wrong tomorrow, your job as a developer will be to figure out which one — because “the site is slow” is never a useful diagnosis.

Today we walk the whole journey. One tap, from start to finish. Let’s go.

The full picture (before we zoom in)

When a browser loads a page, it does roughly this, in order:

Parses the URL — figures out what you’re actually asking for
DNS lookup — turns a domain name into an IP address
TCP handshake — establishes a connection with the server
TLS handshake — (if HTTPS) agrees on encryption
Sends the HTTP request — asks for the page
Server processes — the backend does its work
Sends the HTTP response — the server answers
Browser renders — turns bytes into pixels

Eight steps. Half a second. This is the request-response cycle, and it’s the heartbeat of the entire web.

Request-response cycle — The four-step pattern of every HTTP exchange: the client sends a request, the server processes it, the server returns a response, and the client receives it.

In plain terms: “Ask, process, answer, receive — then do it again.”

Analogy: Think of it like ordering jollof rice from a restaurant on the other side of town.

You decide what you want — “jollof, large, with chicken.” (URL parsing)
You look up the restaurant’s address on Google Maps. (DNS)
You call the restaurant; they pick up. (TCP handshake)
You both confirm you’re on the same line, no one’s eavesdropping. (TLS handshake)
You place your order. (HTTP request)
The kitchen cooks. (Server processing)
A rider leaves with your food. (HTTP response)
You plate it, arrange it, and dig in. (Rendering)

Each step matters. Each one can fail. And once you understand the whole chain, you’ll never say “the site is broken” again — you’ll say “the DNS is slow” or “the server is taking 400ms to respond” or “the render is blocking.”

That’s the difference between a junior and someone who actually knows what they’re doing.

Step 1 — Parsing the URL

You tap a link that says https://readunderstory.ink/lessons/003?ref=twitter#top. Before anything else, the browser reads this string and breaks it into parts. This is called parsing the URL.

A URL (Uniform Resource Locator) has a fixed structure:

https://readunderstory.ink/lessons/003?ref=twitter#top
└─┬──┘ └──────┬──────┘ └────┬────┘ └─────┬────┘ └┬─┘
protocol       domain         path         query  fragment

Protocol — https. How to talk to the server.
Domain — readunderstory.ink. Which server to talk to.
Path — /lessons/003. Which page on that server.
Query string — ?ref=twitter. Extra parameters, usually for tracking or filtering.
Fragment — #top. A specific location within the page. The browser handles this one itself; it never goes to the server.

URL — Uniform Resource Locator: a string that identifies a resource on the web and names the scheme by which to retrieve it, composed of a protocol, a domain, a path, an optional query string, and an optional fragment.

In plain terms: “An address that also says how to fetch what lives there.”

Analogy: A URL is like a postal address with a note attached. The protocol says “send it by courier.” The domain says “which city.” The path says “which house.” The query string is a sticky note with instructions. The fragment says “and knock on the third door inside.”

Once the URL is parsed, the browser knows three things: who to talk to, how to talk to them, and what to ask for. Time to find that server.

Step 2 — The DNS lookup

You gave the browser a human-friendly name: readunderstory.ink. But servers don’t have names — they have IP addresses. Somewhere, that name has to be translated into a number like 76.76.21.21.

That’s DNS — the Domain Name System. It’s the internet’s phone book.

DNS — Domain Name System: the distributed, hierarchical naming system that resolves human-readable domain names into IP addresses, with caches at every level to keep repeat lookups fast.

In plain terms: “The phone book — and the reason you type names, not numbers.”

The lookup happens in stages, and each stage caches its result to make future lookups faster:

Browser cache — have I looked this up recently?
OS cache — has my computer looked this up recently?
Router cache — has my network looked this up recently?
ISP resolver — my internet provider’s DNS server. If it doesn’t know, it asks upstream.
Root nameservers → TLD nameservers → authoritative nameservers — the chain of authority that ultimately knows the answer.

If nothing is cached, the whole DNS lookup can take 100–200ms. If everything is cached, it’s under a millisecond.

Analogy: You want to call Mama Nkechi’s restaurant but you only know her name, not her number. You check your phone contacts. Not there. You check your WhatsApp. Not there. You call your cousin. He doesn’t know. He calls his friend. His friend knows. Eventually, you get the number. Next time, you save it — and the lookup is instant.

We’ll go much deeper on DNS on Day 7. For now, just know: it’s the first potential slowdown, and cache makes a huge difference.

Step 3 — The TCP handshake

Now the browser has an IP address. It needs to connect to that server. But before any data flows, both sides have to agree that they’re ready to talk. That agreement is the TCP handshake — also called the three-way handshake.

TCP handshake — The three-message exchange — SYN, SYN-ACK, ACK — that establishes a TCP connection before any application data is sent.

In plain terms: “The greeting ritual before anyone says anything useful.”

Three-way handshake — Another name for the TCP handshake: three messages, one round trip, one open connection.

In plain terms: “Same thing, older name.”

It goes like this:

Client → Server: “SYN” — “Hey, I’d like to talk. Are you there?”
Server → Client: “SYN-ACK” — “Yes, I’m here. Are you ready?”
Client → Server: “ACK” — “Confirmed. Let’s talk.”

Three messages. One round trip (well, one-and-a-half, technically). Once the third message lands, the connection is open.

Analogy: Two people meeting for the first time and shaking hands. “Hello.” “Hello to you too.” “Great, let’s talk.” Nothing gets said until the greeting ritual is complete.

Why does this matter? Because every handshake costs time. If the server is far away, the round trip is longer. From Lagos to a server in Virginia, the round trip is roughly 120–200ms — and that’s on a fast connection. On a slow one, it can be 400ms+.

This is also why where a website is hosted matters. Every connection to a distant server pays that round-trip tax before the first byte even leaves. We’ll dig into this when we cover CDNs in Module 5.

Step 4 — The TLS handshake (if HTTPS)

If the URL starts with https (and today, they almost all do), there’s another handshake before the HTTP conversation begins: the TLS handshake.

TLS handshake — The negotiation that runs after the TCP connection is open, in which the server proves its identity with a certificate and both sides derive shared encryption keys.

In plain terms: “Showing ID and swapping keys before the conversation starts.”

We covered HTTPS on Day 3, so here’s the short version in the context of the cycle:

The client says hello and offers a list of encryption methods it supports.
The server responds with its certificate — proof of identity, signed by a trusted authority.
The client checks the certificate. If valid, both sides derive a shared secret key.
From here on, everything is encrypted.

TLS adds one or two more round trips before the HTTP request can even be sent. In TLS 1.3 (the modern version), it’s optimised to a single round trip, and resumed connections can skip it entirely.

Analogy: You’ve connected with the restaurant on the phone (TCP handshake). Now before ordering, you both agree to switch to a secure line so nobody else can listen (TLS handshake). Only after that do you place your order.

A practical takeaway: this is why modern browsers keep connections open. If they closed after every request, you’d pay the TCP + TLS tax over and over. Instead, they use keep-alive and HTTP/2 multiplexing — but that’s a whole other conversation for later.

Step 5 — The HTTP request goes out

Now the client is finally ready to ask for what it wanted. It sends an HTTP request — the same structure we covered on Day 3:

GET /lessons/003 HTTP/1.1
Host: readunderstory.ink
User-Agent: Mozilla/5.0...
Accept: text/html
Accept-Language: en-US,en;q=0.9
Connection: keep-alive

A few lines of text. Small enough to travel in a single packet. From this moment until the response starts arriving, the client waits.

This waiting period is measured by TTFB — Time To First Byte. It’s a real performance metric you’ll meet in Module 13. TTFB measures how long it takes for the server to send back the very first byte of the response. Everything before this point (DNS, TCP, TLS) is the “connection phase.” TTFB is the “thinking phase.”

TTFB — Time To First Byte: the elapsed time between sending a request and receiving the first byte of the response — the boundary between the connection phase and the server’s processing phase.

In plain terms: “How long the server spent thinking before it said anything at all.”

Step 6 — The server processes

The request arrives at the server. Now the server does whatever it needs to do to figure out the response. This is the biggest black box in the cycle, because it depends entirely on the application.

For a static HTML file, “processing” is instant — just read the file and send it back.

For a modern web app, “processing” might involve:

Parsing the URL to determine the route
Checking authentication (is this user logged in?)
Querying a database (fetching posts, products, users)
Calling external APIs (payment processor, AI model, maps)
Rendering HTML from templates (or from React components on the server)
Compressing the response
Deciding on caching headers

This is where most “the site is slow” problems actually live. DNS is fast. TCP is fast. TLS is fast. But a slow database query, an un-optimised ORM call, or a chatty round trip to a third-party API can add seconds.

Analogy: The request arrived at the restaurant. Now the kitchen has to actually cook the meal. Some dishes are ready instantly (a Coke from the fridge). Others take ten minutes (the jollof rice). Others take an hour (the whole grilled fish). The “server processing” step is the kitchen, and it’s where the interesting work happens.

Step 7 — The HTTP response comes back

The server sends back an HTTP response — again, the same structure we covered on Day 3:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1284
Cache-Control: max-age=3600
Set-Cookie: session=abc123; Path=/; HttpOnly

<!DOCTYPE html>
<html>...</html>

Same headers, same body, same format. The response makes the return trip over the same connection, back through the internet, back to your browser — the same physical journey as the request, in reverse.

Then the last byte arrives. From here, the client takes over.

A small but important note: responses can be streamed. The browser can start receiving and processing the response before the server has finished sending it. This is how streaming SSR works, and it’s why some sites feel faster than their TTFB suggests. We’ll cover this in Module 5.

Step 8 — The browser renders

The browser now has the bytes — in memory, or on disk if the response was cached. It has to turn them into pixels. This is called rendering, and it’s a whole module’s worth of material (Module 2). Here’s the short version:

Parse HTML → build the DOM — a tree of nodes representing the page structure.
Parse CSS → build the CSSOM — a tree of nodes representing the styles.
Combine them → Render Tree — only visible elements, styled.
Layout — calculate where every element goes on the page.
Paint — fill in every pixel.
Composite — layer everything together and show it on screen.

This whole process is called the Critical Rendering Path, and it gets its own day in Module 2.

The key point for today: rendering starts as soon as bytes arrive. The browser doesn’t wait for the entire response — it’s parsing as data streams in. This is why you sometimes see a page’s text and images appear progressively, out of order. The browser is doing its best with what it has.

The whole journey in one picture

Here’s the full cycle, in the order it happens, with a rough cost for each step:

[1] Parse URL          →  client-local, <1ms
[2] DNS lookup         →  network, 0–200ms (cached or not)
[3] TCP handshake      →  network, ~1 round trip
[4] TLS handshake      →  network, ~1–2 round trips (if HTTPS)
[5] HTTP request sent  →  network, ~1 round trip
      ─── [6] server processing happens here (TTFB) ───
[7] HTTP response back →  network, streaming
[8] Render             →  client-local, varies by page

Roughly 3–4 round trips to the server before the first byte of content arrives. On a local server, that’s under 5ms. Across continents, it can be 500ms+. On a bad mobile connection in rural Nigeria, it can be 2+ seconds.

Round trip — One complete journey of a message to the server and a reply back. Handshakes are priced in round trips.

In plain terms: “There and back again — and you pay for every one.”

Latency — The delay between sending a request and receiving a response, usually dominated by round-trip time; distance, handshakes, and server processing all add to it.

In plain terms: “The waiting, not the work.”

This is exactly why CDNs exist, why caching is a superpower, and why we care so much about performance as developers. Every round trip is a chance for something to be slow.

Cache — A stored copy of a response or resource, held close to the requester so the request can be answered without repeating the full journey.

In plain terms: “Keep a copy nearby. The fastest request is the one you never make.”

What goes wrong at each step

Here’s why knowing the cycle matters in real life. When something breaks, the failure points to a specific step:

Symptom	Likely step	Example
“Site not found”	DNS	Domain expired, misconfigured DNS records
“Connection timed out”	TCP	Server down, firewall blocking, wrong port
“Your connection is not private”	TLS	Expired certificate, wrong domain on cert
“404 Not Found”	Request/server	Wrong URL, missing resource
Slow load, spinning	Server processing	Slow DB query, un-optimised backend
“500 Internal Server Error”	Server processing	Unhandled exception in the backend code
Page loads but looks wrong	Rendering	CSS not loading, JS error, encoding issue (mojibake)
Everything is slow	DNS + round trips	No CDN, no caching, distant server

Once you can map a symptom to a step, debugging stops being guesswork and becomes diagnosis. That’s the real payoff of today’s lesson.

What you’d say in the room

This is the most-asked question in web interviews, and it arrives in almost exactly these words:

If an interviewer asks “What happens when you type a URL into your browser and press Enter?” — this is the answer:

Nobody asks it to be cruel. They ask it because it can’t be faked — you either hold the whole chain in your head or you don’t. Here’s the answer:

“The browser starts by parsing the URL — protocol, domain, path, query string, and fragment — so it knows who to ask and what to ask for. Then it needs an IP address, so it runs a DNS lookup, checking caches along the way: browser, operating system, router, ISP resolver, and finally the authoritative nameservers. With the IP in hand it opens a TCP connection with the three-way handshake — SYN, SYN-ACK, ACK. Because the URL is HTTPS, a TLS handshake follows: the server presents its certificate, the client validates it, and both sides agree on encryption keys. Only now can the browser send the HTTP request — method, path, headers, sometimes a body. The server processes it, which might be as simple as returning a static file or as heavy as a database query plus server-side rendering. It sends back an HTTP response — status code, headers, body. The browser begins parsing as soon as the first bytes arrive: DOM from the HTML, CSSOM from the CSS, then layout, paint, and composite. It keeps working while the rest of the response streams in. All told, three or four round trips before the first byte of content even arrives — which is why latency, caching, and CDNs matter so much.”

It’s long. Good. A long answer here is the correct answer, and an interviewer notices the candidate who can hold eight steps in order without hand-waving.

Why it works:

It’s in order. This matters more than any individual fact. A scrambled answer sounds like memorised fragments; an ordered answer sounds like understanding.
It names mechanisms, not vibes. DNS, three-way handshake, SYN/SYN-ACK/ACK, certificate, DOM, CSSOM, layout, paint.
It finishes with a cost. “Three or four round trips” says you understand that the cycle is priced in time, not just sequenced in space.

The follow-up you should expect next: “The page is slow. Where do you look?”

“I’d split it into two phases. First the connection phase: is DNS resolving fast, is the answer cached, is the server physically far away, is there a CDN in front of it? Then the server phase: what’s the TTFB? If TTFB is high, the backend is the problem — a slow query, an un-optimised ORM call, or a third-party API called in the critical path. If TTFB is low but the page still feels slow, it’s rendering — blocking CSS or JavaScript, too many asset round trips, or missing caching headers.”

Learn both answers. Together they cover a huge share of the interview questions you’ll ever be asked about the web.

Say it like a professional

The definitions from today, in one reviewable block. Say each one out loud. If you stumble, go back to that section.

Request-response cycle — The four-step pattern of every HTTP exchange: the client sends a request, the server processes it, the server returns a response, and the client receives it.
URL — Uniform Resource Locator: a string that identifies a resource on the web and names the scheme by which to retrieve it, composed of a protocol, a domain, a path, an optional query string, and an optional fragment.
DNS — Domain Name System: the distributed, hierarchical naming system that resolves human-readable domain names into IP addresses, with caches at every level to keep repeat lookups fast.
TCP handshake — The three-message exchange — SYN, SYN-ACK, ACK — that establishes a TCP connection before any application data is sent.
Three-way handshake — Another name for the TCP handshake: three messages, one round trip, one open connection.
TLS handshake — The negotiation that runs after the TCP connection is open, in which the server proves its identity with a certificate and both sides derive shared encryption keys.
Latency — The delay between sending a request and receiving a response, usually dominated by round-trip time; distance, handshakes, and server processing all add to it.
Round trip — One complete journey of a message to the server and a reply back. Handshakes are priced in round trips.
Cache — A stored copy of a response or resource, held close to the requester so the request can be answered without repeating the full journey.
TTFB — Time To First Byte: the elapsed time between sending a request and receiving the first byte of the response — the boundary between the connection phase and the server’s processing phase.

Before you close this tab

Say these out loud, in your own words, without looking:

What are the eight steps of a page load, in order?
What are the five parts of a URL — and which one never reaches the server?
What does DNS do, and name three places the answer can be cached.
Why is the second visit to a site usually faster than the first?
What are the three messages of the TCP handshake, in order?
What does the TLS handshake prove, and what does it agree on?
Why does HTTPS add round trips to every new connection?
What is TTFB, and which part of the cycle does it measure?
Name three things a server might do between receiving a request and sending a response.
Why can a page start appearing before it has finished downloading?
A user reports “site not found.” Which step failed? And what about “your connection is not private”?
Why does hosting a server far from your users slow down every page, even fast ones?

If you can answer all twelve without peeking — you’ve done Day 4.

If some are fuzzy, go back to the symptom table. Being able to name the failing step from the symptom alone is the whole point of today: debugging as diagnosis, not guesswork.

Tomorrow, we take the request line apart and look at the one word that decides what actually happens on the server: the method. GET, POST, PUT, PATCH, DELETE — what each one promises, which one to reach for, and why using the wrong one is one of the most common HTTP mistakes in real code.