Thuta Learning
BasicDevOps & Toolsbeginner

What Happens When You Open a Website?

What you'll walk away with

  • Explain the core ideas behind What Happens When You Open a Website?
  • Read the diagram and trace how a request or data flows through the architecture
  • Explain what this means for your own project's decisions

Build the mental model

Typing a domain into your browser feels instant, but a whole sequence of steps runs before a single pixel appears on your screen.

Type a domain

The user types thutatech.com into the browser.

DNS lookup

DNS translates the domain name into an IP address, like a phonebook.

Connect

The browser opens a connection to the server at that IP address.

HTTPS handshake

Before any content is exchanged, a handshake makes the connection encrypted.

Send HTTP request

The browser asks the server, please send me this page.

Server responds

The server or a CDN responds with the HTML, CSS, and JS.

Browser renders

The browser turns all of that into the page you actually see.

This lesson deliberately keeps DNS and HTTPS at a conceptual level; the Networking tutorial on this site covers DNS record resolution and the TCP and TLS handshakes in full technical depth.

text
HOW A WEBSITE LOADS
-------------------
1. You type: thutatech.com
        |
        v
2. DNS lookup -> finds the server's IP address
        |
        v
3. Browser connects to that server (TCP)
        |
        v
4. HTTPS handshake -> connection becomes encrypted
        |
        v
5. Browser sends an HTTP request ("send me this page")
        |
        v
6. Server or CDN sends back HTML, CSS, and JS
        |
        v
7. Browser renders the page you see

Connect it to a real scenario

The code below is a simulation, not a real network call, built to make the sequence from this lesson concrete instead of abstract. resolveDNS stands in for asking DNS to translate a domain into an IP address, connect stands in for the browser opening a connection to that address, and sendRequest stands in for the actual HTTP request asking the server for a page.

Running the three functions in order and logging each result mirrors the real sequence step by step: first you resolve a name to an address, only then can you connect to something, and only after connecting can you actually ask for content. In a real browser, every one of these steps involves real network traffic and, for HTTPS sites, an encryption handshake between the connect and request steps, which this simplified version skips on purpose to keep the shape visible.

If you want to see this exact sequence happen for real, open your browser's developer tools, go to the Network tab, and reload any page: you will see the DNS lookup, the connection, and the actual request and response, all as real entries.

Try the working example

javascript
function resolveDNS(domain) {
  return "203.0.113.42";
}

function connect(ip) {
  return `Connected to ${ip} over TCP`;
}

function sendRequest(path) {
  return `GET ${path} -> 200 OK`;
}

console.log("Simplified simulation (not a real network call):");
const ip = resolveDNS("thutatech.com");
console.log(`1. DNS resolved thutatech.com -> ${ip}`);
console.log(`2. ${connect(ip)}`);
console.log(`3. ${sendRequest("/index.html")}`);
You should see
Simplified simulation (not a real network call):
1. DNS resolved thutatech.com -> 203.0.113.42
2. Connected to 203.0.113.42 over TCP
3. GET /index.html -> 200 OK

5-minute try-it

Modify sendRequest to hardcode "/about.html" instead of taking a path parameter, then call resolveDNS with a new domain like "learn.thutatech.com" and change its returned IP to see how the output changes.

One important caution

Assuming an HTTP request can be sent before DNS lookup happens -- a connection has to exist first

Assuming DNS lookup happens once and never changes again, when caches can expire and re-resolve

Order of the Website Load Process

Which ordering of these three steps is correct: DNS lookup, HTTPS handshake, HTTP request?

MDN: Populating the page: how browsers workCloud & Deployment

Easy traps

  • Assuming an HTTP request can be sent before DNS lookup happens -- a connection has to exist first
  • Assuming DNS lookup happens once and never changes again, when caches can expire and re-resolve
  • Never assume that working on localhost means it will work in production -- environment, network, database, and security differences can all bite.

Exercise

Modify sendRequest to hardcode "/about.html" instead of taking a path parameter, then call resolveDNS with a new domain like "learn.thutatech.com" and change its returned IP to see how the output changes.

You'll know it worked when: Simplified simulation (not a real network call): 1. DNS resolved thutatech.com -> 203.0.113.42 2. Connected to 203.0.113.42 over TCP 3. GET /index.html -> 200 OK