DEV Community: koushik Hazra

What Happens When You Enter a URL in Your Browser?

koushik Hazra — Sun, 13 Sep 2026 13:31:48 +0000

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.

SSR vs CSR — What Actually Happens When Your Page Loads?

koushik Hazra — Sat, 12 Sep 2026 17:30:45 +0000

SSR vs CSR — What Actually Happens When Your Page Loads?

If you've worked with React or Next.js for a while, you've probably heard these two terms a hundred times:

CSR — Client-Side Rendering
SSR — Server-Side Rendering

At first, they sound simple.

"CSR renders on the client, SSR renders on the server."

Technically correct.

But that explanation doesn't really answer the questions that matter.

What actually happens when a user opens a page?

Why can one website show content almost immediately while another appears blank for a moment?

Why does SSR usually help with SEO?

And most importantly — when should you actually use SSR or CSR?

Let's understand it from the browser's point of view, rather than memorizing definitions.

First, Let's Understand the Problem

Imagine you're visiting an e-commerce website.

You click:

example.com/products

Your browser needs to somehow turn that URL into something you can see:

Products
────────────────────
iPhone
MacBook
AirPods
...

The interesting question is:

Who is responsible for creating this HTML?

There are two major possibilities.

CSR → Browser creates the page

SSR → Server creates the page

That single difference changes quite a lot.

🟦 CSR — Client-Side Rendering

Let's start with something most React developers are familiar with.

In a typical React application, the browser initially receives something similar to:

<div id="root"></div>

There's not much actual content inside it.

The browser then downloads the JavaScript bundle.

React starts running.

The application makes API requests.

The data arrives.

React renders the UI.

Finally, the user sees the page.

The flow looks like this:

Browser
   │
   │ Request page
   ↓
Server
   │
   │ HTML + JavaScript
   ↓
Browser
   │
   ├── Download JS
   ├── Execute React
   ├── Fetch API data
   └── Render UI
   ↓
User sees page

📍 IMAGE 1 — Add a diagram here

Create a clean diagram showing:

User
 ↓
Browser
 ↓
Request HTML
 ↓
Server
 ↓
Empty HTML + JS
 ↓
Browser executes JS
 ↓
API Request
 ↓
Data
 ↓
React renders UI

A flow diagram works much better here than a random stock image.

Why Does CSR Feel Slow Sometimes?

Imagine the user has a slow internet connection.

The browser receives:

<div id="root"></div>

Then it waits for JavaScript.

Then React loads.

Then the API request happens.

Then the data arrives.

Only after all of that does the user get the actual content.

You might see something like:

Loading...
Loading...
Loading...

Products finally appear.

This doesn't mean CSR is bad.

It simply means that the browser has more work to do before it can display meaningful content.

And for applications like dashboards, admin panels, or highly interactive applications, that's often perfectly acceptable.

🟩 SSR — Server-Side Rendering

Now let's change the approach.

Instead of asking the browser to build the page, we ask the server to build it first.

The flow becomes:

Browser
   │
   │ Request /products
   ↓
Server
   │
   ├── Fetch product data
   ├── Generate HTML
   ↓
Browser
   │
   │ Receives complete HTML
   ↓
User sees content

The server might send something like:

<h1>Products</h1>

<div>
    <h2>iPhone</h2>
    <p>$999</p>
</div>

<div>
    <h2>MacBook</h2>
    <p>$1299</p>
</div>

The browser doesn't have to wait for React to create the initial page.

It already has meaningful HTML.

The Interesting Part: Hydration

And this is where things become more interesting.

Getting HTML from the server doesn't mean React is finished.

The browser still needs to make that HTML interactive.

For example:

Server
   ↓
HTML
   ↓
Browser displays HTML
   ↓
JavaScript loads
   ↓
React hydrates
   ↓
Page becomes interactive

Suppose you have a button:

<button onClick={handleClick}>
    Add to Cart
</button>

The server can send the button's HTML.

But the server can't handle the user's click inside their browser.

React needs to connect the JavaScript behavior to that existing HTML.

That's hydration.

SSR vs CSR — The Real Difference

Here's the simplest way I remember it:

CSR asks the browser to build the page.

SSR asks the server to build the initial page.

Everything else — SEO, performance, loading experience, hydration — follows from this fundamental difference.

Let's Compare Them

	CSR	SSR
Initial HTML	Mostly empty shell	Contains page content
Rendering happens	Browser	Server
Initial load	Can be slower	Usually faster for content
JavaScript dependency	High	Still required for interactivity
SEO	More challenging	Generally better
Server workload	Lower	Higher
Interactivity	Excellent	Excellent after hydration
Best for	Dashboards, apps	Content-heavy pages

🚀 What About SEO?

This is one of the biggest reasons SSR became popular.

Search engines need to understand your content.

Consider a blog page.

With CSR, the initial HTML might look like:

<div id="root"></div>

The actual article content appears only after JavaScript executes.

With SSR, the initial HTML can already contain:

<h1>Understanding Distributed Systems</h1>

<p>
Distributed systems are...
</p>

A crawler can immediately see meaningful content.

This makes SSR a natural fit for:

Blogs
News websites
E-commerce product pages
Documentation
Marketing websites
Public-facing pages

But Wait — Is SSR Always Better?

No.

And this is where many tutorials oversimplify the topic.

If SSR were always better, we wouldn't need CSR.

Imagine a dashboard:

/dashboard

The page contains:

Charts
Filters
Tables
Drag-and-drop components
Real-time notifications
User-specific data

Almost everything depends on the current user's interaction.

Do you really need the server to generate every version of that UI?

Probably not.

A client-rendered dashboard can make perfect sense.

# 🧠 A Real-World Example

Imagine you're building an online learning platform.

You have:

/
├── Home
├── Courses
├── Course Details
├── Dashboard
├── Profile
└── Settings

Would you render everything the same way?

Probably not.

Home

Mostly public content.

→ SSR / SSG can be useful.

Course Details

Public and SEO-friendly.

→ SSR / SSG can be useful.

Dashboard

Highly personalized.

→ CSR can be a great choice.

Settings

Private and interactive.

→ CSR is often reasonable.

The important lesson is:

A modern application doesn't have to choose only one rendering strategy.

You can use different strategies for different pages.

⚡ Where Does Next.js Come In?

This is one of the reasons Next.js is so interesting.

Instead of forcing developers into:

Everything = CSR

Everything = SSR

Next.js gives you multiple rendering strategies.

Depending on the architecture and version, you can work with concepts such as:

Server-side rendering
Static generation
Incremental regeneration
Client-side rendering
React Server Components

So instead of asking:

"SSR or CSR?"

the better question becomes:

"What rendering strategy makes sense for this particular part of my application?"

🔥 The Biggest Misconception

One thing I wish I had understood earlier:

SSR does not mean the entire application runs on the server.

And:

CSR does not mean there is no server.

Both applications still have servers.

Both can have APIs.

Both can use databases.

Both can use JavaScript.

The main difference is where the initial UI rendering happens.

That distinction makes the whole topic much easier to understand.

So, Which One Should You Use?

Here's my practical rule of thumb.

Choose SSR when:

The page is public.
SEO matters.
Initial content should appear quickly.
The content is generated from server-side data.
You want search engines to easily understand the page.

Choose CSR when:

The page is highly interactive.
SEO isn't important.
The content is heavily personalized.
Most of the work happens after user interaction.
You're building dashboards or application-like interfaces.

And in many real applications?

Use both.

That's usually the better answer.

Final Thought

SSR vs CSR isn't really a battle.

It's a design decision.

The interesting question isn't:

"Which one is better?"

It's:

"Which one is better for this page, this user, and this application?"

Once you start thinking that way, rendering stops being a collection of confusing acronyms.

It becomes an architectural decision.

And that's the part that actually matters.

📌 Quick Mental Model

If you remember only one thing from this article:

CSR
Browser → JavaScript → Data → UI

SSR
Server → Data → HTML → Browser → Hydration

That's the foundation.

Everything else builds on top of it.

Hey Community .

koushik Hazra — Sat, 12 Sep 2026 17:22:40 +0000

Today i joined dev.to. And this is my first Post .