SSR vs CSR: The Interview Question That Made Me Rethink Rendering π€―
I was sitting in an interview.
The interviewer asked:
"Can you explain what happens in Server-Side Rendering?"
I confidently replied:
"In SSR, the server renders the component and sends the HTML file to the browser."
I thought I cooked.
The interviewer looked at me.
I looked at the interviewer.
He looked back.
Then he said:
"That's not wrong⦠but that's not the whole story either."
Ouch.
That sentence sent me on a rabbit hole that ended with me understanding SSR and CSR much better than before.
First, What Is Rendering?
Rendering simply means:
Taking your code and turning it into something the user can see on the screen.
The question is:
Who creates the HTML?
The answer decides whether it's SSR or CSR.
Client-Side Rendering (CSR)
- Browser requests the page.
- Server sends an almost empty HTML and a JavaScript bundle.
- Browser downloads JavaScript.
- React executes in the browser.
- React creates the UI.
<body>
<div id="root"></div>
</body>The actual content doesn't exist initially.
CSR Flow
Browser
β
Request
β
Server sends HTML + JS
β
Browser downloads JS
β
React renders UI
β
User sees contentWhy CSR Can Feel Slow
Imagine ordering food and the restaurant says:
- Build the kitchen.
- Hire the chef.
- Buy vegetables.
- Then we'll cook.
That's CSR.
The browser has a lot of work before showing content.
Server-Side Rendering (SSR)
This is where my interview answer was incomplete.
The server doesn't simply send HTML.
The server actually runs React.
<Home />becomes
<h1>Hello World</h1>
<p>Welcome back.</p>before it even reaches the browser.
SSR Flow
Browser
β
Request
β
Server runs React
β
Generates HTML
β
Sends HTML + JS
β
Browser shows content immediatelyThe Missing Piece: Hydration π§
Then my next question was:
If HTML is already there, why do we still need JavaScript?
Because HTML is just the picture.
The page still needs:
- Click handlers
- Forms
- State
- Interactivity
So the browser:
- Displays HTML immediately.
- Downloads JavaScript.
- React attaches event handlers.
This process is called:
Hydration
HTML arrives
β
Content becomes visible
β
JS arrives
β
React hydrates
β
Page becomes interactiveThis was the detail I missed in the interview.
Visual Comparison
CSR
Request
β
HTML
β
Download JS
β
Execute JS
β
Render UI
SSR
Request
β
Server generates HTML
β
Display UI immediately
β
Download JS
β
HydrateBenefits of SSR
β Better First Paint
β Better SEO
β Better User Experience
β Better for slower devices
Benefits of CSR
β Great for highly interactive applications
β Lower server work
β Fast client-side navigation
When Should You Use What?
| Situation | Better Choice |
|---|---|
| Blogs | SSR |
| Marketing Pages | SSR |
| SEO-heavy apps | SSR |
| Admin Dashboards | CSR |
| Internal Tools | CSR |
| Highly Interactive Apps | CSR |
The Interview Answer I'd Give Today
In Server-Side Rendering, the server executes React components and generates HTML on the server itself. The browser receives this pre-rendered HTML and displays content immediately. Along with the HTML, JavaScript is also sent so React can hydrate the page and attach event handlers, making the page interactive.
Final Thoughts
I wasn't completely wrong.
I was just⦠incomplete.
And sometimes in tech, that's the difference between:
"Knows React"
and
"Understands React."
As Harvey Specter would say:
"The difference between good and great is attention to detail."
This tiny detail called hydration completely changed my understanding of rendering.
And honestly?
That's the best part of learning.
There is always one more layer beneath what you think you know.
Keep digging. Keep learning. The browser always has another story to tell. π