Understanding SSR, CSR and SSG in Next.js

Modern web applications are expected to be fast, SEO-friendly, and highly interactive.

The challenge is that not every page has the same requirements.

A blog post, an ecommerce product page, and an admin dashboard all serve different purposes. Yet many developers initially assume every page should be rendered the same way.

This is where Next.js becomes powerful.

It gives us multiple rendering strategies, each optimized for different scenarios.

Understanding when to use SSR, CSR, and SSG can dramatically improve performance, SEO, and user experience.

The Problem

Let's say we're building three completely different pages:

text

1. Admin Dashboard
2. Product Page
3. Blog Article

At first, they seem similar.

They're all web pages.

They're all built using React.

They're all displayed inside a browser.

So why not render them all the same way?

Because each page has different priorities.

text
Admin Dashboard
↓
Interactivity

Product Page
↓
Fresh Data + SEO

Blog Article
↓
Speed + SEO

And that's where things get interesting.

The Browser-First Approach (CSR)

For years, React applications followed a simple pattern.

text
Browser
↓
Download JavaScript
↓
Execute React
↓
Fetch Data
↓
Render UI

The browser does almost everything.

This became known as Client Side Rendering (CSR).

The approach works great for dashboards and highly interactive applications.

But there was a problem.

Search engines don't enjoy waiting for your JavaScript to finish loading.

Neither do users.

That's why many React applications started showing this:

text
Loading...
Loading...
Loading...

Developers loved CSR.

Users didn't always love the waiting.

The Server Says: Let Me Help (SSR)

To solve this problem, frameworks like Next.js introduced Server Side Rendering.

Instead of asking the browser to build the page:

text
Browser Request
↓
Server Builds HTML
↓
Ready Page Returned

The user immediately receives content.

No waiting for React to fetch critical information.

This made ecommerce, blogs, and SEO-heavy websites significantly better.

But a new question appeared.

Why build the same page thousands of times if it barely changes?

The "Build It Once" Idea (SSG)

Imagine a blog article.

The content might stay unchanged for weeks.

Generating it repeatedly makes little sense.

So Next.js introduced another strategy.

text
Build Time
↓
Generate HTML Once
↓
Store Static File
↓
Serve Instantly

This became Static Site Generation.

Instead of generating pages per request, the work happens before users even arrive.

The result?

Extremely fast websites.

Three Strategies, One Question

When developers learn SSR, CSR, and SSG, they often treat them as separate concepts.

They're not.

They're simply three answers to one question:

Where should the HTML be created?

text
Browser
↓
CSR

Server Request Time
↓
SSR

Build Time
↓
SSG

That's the entire story.

Everything else is just trade-offs.

Final Thought

SSR, CSR, and SSG each have their place.

Every choice improves something and sacrifices something else.