What happens when you open a website

You type stayhub.com into your browser and press Enter. Less than a second later, a hotel page is on your screen. It feels like nothing happened. In fact, your request just travelled to a computer that may be thousands of kilometres away, and came back, several times.

In this lesson we follow that one click, step by step. There are six steps. By the end, you'll be able to name each one, say roughly how long it takes, and know which one has broken when a website doesn't work.

Why does this matter if Claude Code writes the code for you? Because when something goes wrong, the agent will propose a fix. Your job is to know which step is actually broken, so you can tell a real fix from a guess.

First, the big picture. Every website is a conversation between two computers. Your browser, on your phone or your laptop, is the client: it asks. Somewhere else, a computer called a server answers.

A server is not a magic box. It's a computer like yours, but it stays switched on day and night, it lives in a data centre, and it has one job: wait for questions and send back answers.

The question is called a request. The answer is called a response. Everything you do on the web, opening a page, tapping a button, sending a message, is one or more requests and responses.

To remember the six steps, think of a phone call. You look up the number. You dial and wait for the other side to pick up. You ask your question. They look up the answer. They reply. And you write it down. Opening a website works exactly like that.

Step one: find the address. Computers don't find each other by names like stayhub.com. They use numbers called IP addresses, a bit like phone numbers. For example: 203.0.113.42.

Names are for humans, numbers are for machines, so something has to translate one into the other. That something is DNS, the Domain Name System. Think of it as the internet's contacts list.

Your browser asks a DNS server: what's the number for stayhub.com? The answer comes back: 203.0.113.42. Your device remembers it for a while, so next time it doesn't need to ask again.

When the answer is already remembered, this step takes almost no time. When it isn't, it usually takes a few tens of milliseconds. A millisecond is a thousandth of a second, and as you'll see, milliseconds add up.

When DNS goes wrong, the browser simply can't find the site. You see an error like "This site can't be reached", even though the server itself may be perfectly fine. Nobody can call a number they don't have.

Step two: dial, and wait for the other side to pick up. Your browser opens a connection to the server. The two computers exchange a short hello: are you there? Yes, I'm here. This is called a handshake, and the rules it follows are called TCP.

Then they agree on a secret code, so that nobody in between, on the café Wi-Fi or anywhere along the way, can read or change what you send. This is TLS. It's what the S in https stands for, and what the padlock next to the address means.

Here's the important part. Each of these exchanges is a round trip: a message goes there, and an answer comes back. Before your browser has asked for anything at all, it has already made about two round trips.

And every round trip takes time, because of distance. Signals in a fibre-optic cable travel at about two hundred thousand kilometres per second. That's fast, but cables don't run in straight lines, and every machine along the way adds a little delay.

From Paris to a server in Frankfurt, a round trip takes about 15 milliseconds. From Tokyo to the same server, about 230 milliseconds. Same server, same code. Only the distance is different.

Step three: ask your question. Now that the line is open, the browser sends the request. It's written in a simple language called HTTP, and it's just a few lines of text.

The first line says what you want: GET, which means "give me", and then the page, /hotels/42. The next lines add details called headers: which browser you use, which languages you read, and a small note called a cookie that reminds the server who you are.

GET is for reading. When you send something, like booking a room or submitting a form, the browser uses POST instead. A huge part of the web is built from just those two words.

Step four: the server does the work. The request arrives, and a program on the server runs. This is the backend: code you never see, which decides what to send back.

To answer, it usually needs facts: the hotel's name, its photos, tonight's price, how many rooms are left. Those facts live in a database, a program built to keep information safe and find it fast.

So the server asks the database, gets the facts back, and uses them to build the page. On StayHub this takes about a tenth of a second. But one slow question to the database can turn it into whole seconds.

Step five: the answer comes back. The response starts with a status code, a three-digit number that says how it went.

200 means OK: here's your page. 404 means not found: that page doesn't exist. 500 means server error: the code on the server crashed while it was trying to answer. Remember these three. You'll see them all the time.

A useful trick: codes starting with a 4 mean the request had a problem, like a wrong address. Codes starting with a 5 mean the server had a problem. When an app breaks, the first digit already tells you where to look.

After the status code comes the content itself. For a web page, that's HTML: plain text that describes what's on the page. A title here, a paragraph there, a button, a photo.

Step six: the browser builds the page. HTML is the skeleton of the page, and also a list of everything else it needs. So the browser reads it, and goes to fetch the rest.

CSS files say how things look: colours, fonts, layout. JavaScript files say how things behave: what happens when you tap a button. Then come the images, the fonts, and more. A typical page today asks for dozens of files, often more than fifty.

Each of those files is another request and another response. The browser keeps the line open and asks for several at once, but it only discovers some files after others arrive. So it pays the round trip again, and again.

As the pieces arrive, the browser draws the page: first the text and the layout, then the photos, and finally the JavaScript makes everything work. Only now can you tap Book.

Let's put it together. Find the address. Open a safe line. Ask. The server works. The answer comes back. The browser builds the page. Six steps, and most of the time it all happens in under a second.

But not everywhere. Picture a guest in Tokyo opening a StayHub hotel page, served from Frankfurt. About 30 milliseconds to find the address. Nearly half a second for the handshakes. A third of a second for the page itself. And more than two seconds for the photos, styles and scripts, trip after trip. Total: 3.1 seconds.

Now the surprise: the server's own work is only about a tenth of a second of that. The page isn't slow because the code is slow. It's slow because of round trips multiplied by distance. A faster server would barely help. Fewer trips, or copies of the files closer to Tokyo, would.

That's the habit to keep as a leader: before you accept a fix for a slow page, ask which step is slow, and ask for the measurement.

The six steps also tell you where to look when a website breaks. "This site can't be reached"? Usually step one, the address. "Your connection is not private"? Step two, the safe line. A 404? The request asked for something that doesn't exist. A 500? The server's code crashed. Slow? Measure each step, and fix the biggest one.

So the next time Claude Code tells you "I fixed it", you can ask the right questions: which step was broken, and how do we know it works now?

Here's the whole journey one last time: find, connect, ask, work, answer, build. Below the video you'll find everything I said, with diagrams for the tricky parts, and a few questions to check that it stuck. See you in the next lesson.