Table of Contents
Introduction
Ever wondered what happens when you type a web address like www.example.com into your browser and press Enter? It feels instant, but under the hood, an orchestra of processes works in harmony to fetch and display that webpage.
In this article, let’s break down that magical moment in a way even kids (like Chomu and Catoza) can understand—but with the technical richness that any developer or future CTO will appreciate.
Let’s pop the hood and explore what’s really going on, step by step.
Learn more how internet works from browser to server – Explained
The Evolution – From Static Files to Complex Systems
In the early 90s, a website was a plain HTML file sitting on a server. Type a URL, and the server sent you the file. That’s it. But today, websites are powered by complex stacks—databases, APIs, JavaScript engines, CDNs, containerized environments (like Docker or Kubernetes), and more.
Understanding how a website loads isn’t just academic—it’s foundational. Whether you’re optimizing performance, fixing bugs, or building better experiences, it all starts here.
The Problem Statement – Why Do We Need to Understand This?
Chomu once told her cat (Catoza), “I typed in a site and it just appeared. Magic!”
But when that site is down, or slow, or showing the wrong data, “magic” isn’t enough. Knowing how it works empowers you to:
- Troubleshoot DNS issues
- Optimize load performance
- Design better architecture
- Improve SEO and user experience
- Understand full-stack development holistically
Step-by-Step – How a Website Loads (Under the Hood)
Let’s walk through every stage, from address bar to pixel.
1. Typing a URL – What Really Happens?
Say Chomu types https://www.chomu.dev.
- The browser first checks if this domain is cached.
- If not, it asks: “Who knows the IP of this domain?”
2. DNS Resolution – Finding the IP Address
The browser triggers a DNS lookup:
- First, it checks the OS cache.
- Then the router’s cache.
- If not found, it goes to the ISP’s DNS server.
- Eventually, it may query a root DNS server → TLD DNS → Authoritative DNS, which returns the IP of
www.chomu.dev.
Result? The browser now knows: “Ah, this domain lives at 172.217.14.228!”
Think of DNS like your phone contacts. You don’t memorize every number—you just know the name.
3. TCP/IP Handshake – Making a Connection
Using the IP address, your browser initiates a connection using the TCP protocol.
- It says, “Hey server, can we talk?”
- The server replies, “Yes.”
- The browser says, “Cool, I’ll start sending data now.”
This 3-step handshake ensures both sides are ready to transmit data reliably.
4. TLS Handshake (If HTTPS
If the site is using HTTPS (and it should!), there’s an extra security step:
- Browser and server exchange certificates.
- They establish an encrypted connection using TLS (Transport Layer Security).
- Now, everything you see or type is encrypted.
That little padlock icon in your browser? This is why it matters.
5. HTTP Request – Asking for the Page
Now that a secure connection is ready, the browser sends:
GET / HTTP/1.1
Host: www.chomu.devThis is an HTTP GET request, asking the server:
“Hey, give me the homepage of this site.”
6. Server Processes the Request
Depending on the backend setup:
- It might serve static HTML from disk.
- Or it could render dynamic pages using Node.js, Django, PHP, or others.
- It may fetch data from databases or external APIs.
The server bundles the HTML and sends it back.
7. Browser Receives HTML – Rendering Begins
Now, the browser gets the HTML and starts building the DOM (Document Object Model).
But wait, the HTML often references:
- CSS files (for styling)
- JavaScript files (for logic and interactivity)
- Images, Fonts, Videos, etc.
For each of those, more HTTP(S) requests are made.
This is why performance optimization—like reducing HTTP requests and using CDNs—matters so much.
8. CSS and JavaScript Parsing
- The CSSOM (CSS Object Model) is built from CSS files.
- JavaScript is parsed and executed. It can modify the DOM, fetch data, or do things like analytics, animation, or real-time updates.
If there’s JavaScript that blocks rendering (like document.write() or alert()), it can delay what the user sees.
9. Page Painting and Interactivity
Now the browser has:
- A DOM (HTML)
- A CSSOM (Styles)
- JavaScript logic
It combines them and paints the pixels onto the screen. Your website is now visible.
At this point, the user can scroll, click, type—interact!
Learn More about HTTPS and HTTP
Summary Flowchart
URL → DNS → TCP Handshake → TLS (if HTTPS) → HTTP Request → Server Response (HTML)
→ Parse HTML → Fetch CSS/JS → Build DOM/CSSOM → Render Page → User Sees WebsiteWhy This Matters to You (and Catoza)
Understanding this helps you:
- Build faster websites by optimizing load steps.
- Fix frontend bugs by knowing where things break.
- Improve security with HTTPS and headers.
- Architect scalable systems for production traffic.
- Explain it to your future team or clients like a true pro.
And most importantly—it demystifies the web.
Real-Life Analogy
Let’s say Manrahul wants pizza.
- He tells his mom: “I want pizza!” (
Enter URL) - She checks her recipe list. (
DNS lookup) - Finds the correct steps. (
TCP/IP handshake) - She puts on gloves to avoid germs. (
TLS) - She fetches the ingredients. (
HTTP request) - Cooks the pizza. (
Server processing) - Hands it to Manrahul. (
Response) - He eats and enjoys. (
Page rendering & interaction)
See? Tech isn’t that scary when you relate it to pizza.
Final Thoughts
When someone says, “The website is slow,” or “I can’t access the site,” you now know exactly where things could be breaking. The beauty of the web isn’t just in what we see—it’s in how all the layers come together seamlessly.
As someone who’s built and scaled systems for nearly two decades, I promise you: once you understand the flow, every debugging session, architecture decision, and user experience becomes clearer.
