Do you have Google? Go and Type
You type:
https://koushikHazra.com
You press Enter.
A moment later, a webpage appears.
It feels almost instantaneous.
But have you ever stopped to think about what actually happened during those few milliseconds?
Your browser didn't simply "open a website."
A surprisingly long chain of events took place:
URL
↓
DNS
↓
IP Address
↓
TCP Connection
↓
TLS Handshake
↓
HTTP Request
↓
Server
↓
HTTP Response
↓
Browser
↓
HTML Parsing
↓
CSS + JavaScript
↓
Rendering
↓
Page
That's a lot of work for one press of the Enter key.
Let's follow the journey from the beginning.
1. You Enter a URL
Suppose you type:
https://koushik.com/photos
A URL generally contains several important pieces:
https://koushik.com/photos
│ │ │
│ │ └── Path
│ └───────────── Domain
└────────────────────── Protocol
Here:
-
https→ protocol -
koushik.com→ domain -
/photos→ path
But your computer doesn't actually communicate with example.com.
Networks communicate using IP addresses.
So the browser needs to answer a simple question:
"What IP address belongs to example.com?"
That's where DNS comes in.
2. DNS — Finding the Server
DNS stands for:
Domain Name System
You can think of DNS as the internet's phonebook.
Humans prefer:
google.com
Computers need something like:
142.250.x.x
So the browser needs to translate the domain name into an IP address.
A simplified flow looks like this:
Browser
↓
DNS Resolver
↓
Root DNS Server
↓
.com DNS Server
↓
Authoritative DNS Server
↓
IP Address
For example:
koushik.com
↓
93.184.216.34
Now the browser knows where to send the request.
📍 IMAGE 1 — Add a DNS resolution diagram here
Create a clean technical diagram showing:
Browser
↓
DNS Resolver
↓
Root
↓
.com
↓
Authoritative DNS
↓
IP Address
Keep it simple. Don't use a generic internet image.
3. The Browser May Already Know the IP
There's an important optimization here.
Your browser doesn't necessarily perform a complete DNS lookup every time.
DNS results can be cached at multiple levels:
Browser Cache
↓
OS Cache
↓
Router Cache
↓
DNS Resolver Cache
↓
DNS Servers
If the IP address is already cached, the browser can skip much of the DNS process.
This is one of the many reasons why the second visit to a website can feel faster.
4. Now We Need a Connection
The browser knows the server's IP address.
But it still needs a reliable connection to communicate with it.
For HTTPS connections, this involves TCP and TLS.
For a traditional HTTP/1.1 or HTTP/2 connection, TCP establishes the transport connection first.
5. TCP Three-Way Handshake
TCP needs to establish a connection between the client and server.
This is commonly called the:
Three-Way Handshake
The basic process is:
Client Server
SYN ──────────────────→
←────────────────── SYN + ACK
ACK ──────────────────→
In simple terms:
Step 1
Client:
"Can we establish a connection?"
Step 2
Server:
"Yes. I received your request, and I'm ready."
Step 3
Client:
"Great. Let's communicate."
Now the TCP connection is established.
6. HTTPS Adds TLS
But we're accessing:
https://koushik.com
not:
http://koushik.com
The S in HTTPS is important.
It means the HTTP communication is protected using TLS (Transport Layer Security).
TLS provides things such as:
- Encryption
- Server authentication
- Data integrity
During the TLS handshake, the browser and server negotiate cryptographic parameters and establish keys that will protect the connection.
You don't see any of this.
You just see:
🔒 https://koushik.com
But underneath, cryptographic work is happening.
7. The Browser Sends an HTTP Request
Now we're finally ready to request the webpage.
The browser might send something conceptually similar to:
GET /photos HTTP/1.1
Host: koushik.com
User-Agent: Chrome
Accept: text/html
The important part is:
GET /photos
We're telling the server:
"Please give me the resource located at /products."
The request travels through the network to the server.
8. What Happens on the Server?
Now things get interesting.
The request reaches the backend application.
Imagine the server is running:
Node.js
Express.js
The request might pass through several layers:
Request
↓
Load Balancer
↓
Web Server
↓
Express Router
↓
Middleware
↓
Controller
↓
Service
↓
Database
For example:
GET /products
might eventually trigger:
photos.find()
The backend retrieves the required information from the database.
For a dynamic application, the server might need to:
- Authenticate the user
- Check permissions
- Query the database
- Fetch data from another service
- Generate HTML
- Return JSON
- Cache the result
All of this can happen before your browser receives the response.
9. The Server Sends an HTTP Response
The server now sends a response back.
For example:
HTTP/1.1 200 OK
Content-Type: text/html
followed by the HTML document:
<!DOCTYPE html>
<html>
<head>
<title>Products</title>
</head>
<body>
<h1>Products</h1>
</body>
</html>
The browser receives the response.
But we're still not finished.
In fact, this is where the browser's real work begins.
10. The Browser Parses HTML
The browser reads the HTML and builds a structure called the:
DOM — Document Object Model
For example:
<h1>photos</h1>
<p>Explore our products.</p>
becomes a tree-like structure:
Document
│
└── html
│
└── body
├── h1
│ └── Products
│
└── p
└── Explore our products.
The browser uses this structure to understand what should appear on the page.
11. Then Comes CSS
Suppose the HTML contains:
<h1 class="title">photos</h1>
and the CSS says:
.title {
font-size: 32px;
}
The browser downloads and parses the CSS.
It creates another internal structure describing the styles.
The browser then combines information from HTML and CSS to determine:
What should this page look like?
12. JavaScript Enters the Picture
Modern websites rarely consist of only HTML and CSS.
JavaScript can:
- Fetch API data
- Handle button clicks
- Update the UI
- Validate forms
- Create animations
- Communicate with WebSockets
- Modify the DOM
For example:
fetch("/api/photos")
might trigger another HTTP request.
So your original page request can lead to many additional requests:
┌── CSS
│
HTML ───────────────┼── JavaScript
│
├── Images
│
├── Fonts
│
└── API requests
That's why opening one website can result in dozens or even hundreds of network requests.
13. The Browser Finally Renders the Page
Now the browser has enough information to start turning everything into pixels.
A simplified rendering pipeline looks like:
HTML
↓
DOM
CSS
↓
CSSOM
DOM + CSSOM
↓
Render Tree
↓
Layout
↓
Paint
↓
Compositing
↓
Screen
Layout
The browser calculates:
- Width
- Height
- Position
- Spacing
Paint
It determines what needs to be visually drawn:
- Text
- Colors
- Borders
- Images
- Shadows
Compositing
The browser combines different layers and produces the final visual output.
And finally...
You see the webpage. 🎉
📍 IMAGE 2 — Add the Browser Rendering Pipeline Here
This is probably the most important visual in the article.
Show:
HTML → DOM
CSS → CSSOM
DOM + CSSOM
↓
Render Tree
↓
Layout
↓
Paint
↓
Compositing
↓
Browser Screen
A clean technical diagram would make this section much easier to understand.
14. So How Fast Did All of This Happen?
Usually, very fast.
But the actual time depends on many factors:
DNS lookup
+
Connection setup
+
TLS handshake
+
Server processing
+
Network latency
+
HTML parsing
+
CSS processing
+
JavaScript execution
+
Rendering
This is why web performance is much more complicated than:
"My server responds in 100 ms."
The server might respond quickly, but the browser could still spend significant time downloading and executing JavaScript.
Likewise, a fast frontend can't completely hide a slow backend.
Web performance is a chain.
15. And This Connects Back to SSR vs CSR
This is where things start connecting.
Remember the difference between SSR and CSR?
With SSR:
Browser
↓
Server
↓
Server generates HTML
↓
Browser
↓
Render content
With CSR:
Browser
↓
Server
↓
HTML + JavaScript
↓
JavaScript executes
↓
API request
↓
Data
↓
UI rendered
So understanding what happens when you enter a URL makes SSR vs CSR much easier to understand.
They're not isolated frontend concepts.
They're part of the larger web request lifecycle.
16. One URL Request Is Actually a Chain of Systems
This is the part I find most interesting.
When you type one URL, you're interacting with many different technologies:
URL
│
↓
DNS
│
↓
TCP
│
↓
TLS
│
↓
HTTP
│
↓
Web Server
│
↓
Application
│
↓
Database
│
↓
Response
│
↓
Browser
│
↓
Rendering
│
↓
Screen
What looks like one simple action is actually a conversation between many systems.
🌐 The Full Journey
Let's put everything together.
1. User enters URL
↓
2. Browser parses URL
↓
3. DNS resolves domain
↓
4. Browser gets IP address
↓
5. TCP connection established
↓
6. TLS handshake
↓
7. HTTP request sent
↓
8. Server receives request
↓
9. Backend processes request
↓
10. Database may be queried
↓
11. Server sends HTTP response
↓
12. Browser receives HTML
↓
13. Browser builds DOM
↓
14. Browser processes CSS
↓
15. JavaScript executes
↓
16. Layout + Paint
↓
17. Pixels appear on screen
And all of this happens because you pressed Enter.
Final Thoughts
The next time you type a URL into your browser, remember that you're not simply "opening a website."
You're starting a journey through:
DNS → TCP → TLS → HTTP → Backend → Database → Browser → Rendering
Understanding this journey changes how you think about web development.
A slow website is no longer just:
"The website is slow."
You can start asking better questions:
- Is DNS taking too long?
- Is the server slow?
- Is the database query inefficient?
- Is the network connection slow?
- Is JavaScript blocking rendering?
- Are we sending too much data?
- Are we rendering on the server or client?
- Can caching help?
- Can we reduce the number of requests?
That's when web development becomes more than writing components and APIs.
You start seeing the entire system.
And that's where things get really interesting. 🚀
Quick Mental Model
If you remember only one diagram from this article, remember this:
URL
↓
DNS
↓
IP
↓
TCP + TLS
↓
HTTP Request
↓
Server
↓
Database
↓
HTTP Response
↓
Browser
↓
DOM + CSSOM
↓
Layout
↓
Paint
↓
Screen
One URL.
A whole lot of engineering.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.