Next.js Rendering Explained: CSR vs SSR vs SSG vs ISR vs React Server Components
If you've recently started learning Next.js, you've probably encountered terms like Client-Side Rendering (CSR), Server-Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR), and React Server Components (RSC).
At first glance, they seem like completely different technologies. In reality, they're all trying to answer two simple questions:
Where is the HTML generated?
When is the HTML generated?
Understanding these two questions will eliminate most of the confusion around Next.js rendering.
In this article, we'll build a mental model from the ground up. We'll start with how browsers render websites, then explore each rendering strategy, explain React Server Components, and finish by discussing when to use each approach in real-world applications.
Before We Talk About Next.js, Let's Understand Rendering
Regardless of whether you're using React, Next.js, Vue, Angular, or plain HTML, every website eventually goes through the same browser rendering pipeline.
When you visit a website, the browser receives HTML, CSS, and JavaScript from the server.
From there, it performs several steps before anything appears on your screen.
Browser receives HTML
↓
Creates the DOM
↓
Downloads CSS
↓
Creates the CSSOM
↓
Combines them into the Render Tree
↓
Calculates Layout
↓
Paints Pixels
↓
Composites Layers
↓
Page Appears
The important thing to understand is that the browser always performs these rendering steps.
Whether you're using CSR, SSR, SSG, or ISR, the browser is still responsible for displaying the page.
The difference lies in where the HTML came from before the browser received it.
What Happens When You Visit a Website?
Every webpage begins with an HTTP request.
Browser
│
│ HTTP Request
▼
Server
│
│ HTML
▼
Browser
│
▼
DOM
CSSOM
Render Tree
Layout
Paint
Composite
Every rendering strategy follows this same process.
The only thing that changes is who generated the HTML and when it was generated.
Keep that thought in mind because it explains almost everything in Next.js.
Client-Side Rendering (CSR)
Client-Side Rendering means the browser is responsible for generating most of the HTML.
Here's what happens:
Browser
│
▼
Server
Returns:
HTML (mostly empty)
JavaScript
│
▼
Browser downloads JavaScript
│
▼
React runs
│
▼
React creates HTML
│
▼
Browser renders the page
If you've built a React application with Vite or Create React App, you've already used Client-Side Rendering.
The initial HTML usually looks something like this:
<body>
<div id="root"></div>
<script src="main.js"></script>
</body>
Notice something?
There's almost no content.
Instead, React downloads JavaScript, executes it, creates the virtual DOM, converts it into real DOM nodes, and injects everything into the page.
Advantages
Fast page navigation after the initial load.
Excellent for highly interactive applications.
Reduced server workload after the initial request.
Disadvantages
Slower first page load because JavaScript must download and execute first.
SEO can be more challenging if search engines don't execute JavaScript effectively.
Users may briefly see a blank screen while the application loads.
Best Use Cases
Client-Side Rendering works well for applications such as:
Gmail
Trello
Notion
Chat applications
Social media platforms
Server-Side Rendering (SSR)
With Server-Side Rendering, React executes on the server instead of the browser.
Before the browser receives anything, the server has already generated the HTML.
Browser
│
▼
Server
Runs React
↓
Creates HTML
↓
Returns HTML
↓
Browser displays page
↓
JavaScript hydrates the page
This means users immediately receive meaningful HTML instead of an empty <div>.
Hydration then makes the page interactive by attaching React's event handlers.
Advantages
Faster first meaningful paint.
Better SEO because search engines receive complete HTML.
Content appears immediately.
Disadvantages
Every request requires server work.
Higher server costs compared to static pages.
Slower response under heavy traffic if not optimized.
Best Use Cases
Server-Side Rendering is ideal for:
Dashboards
User profiles
Personalized pages
News websites
E-commerce product pages that change frequently
Static Site Generation (SSG)
Static Site Generation moves the rendering process even earlier.
Instead of generating HTML when a user visits the page, Next.js generates the HTML during the build process.
npm run build
↓
Next.js generates HTML
↓
HTML stored on disk
↓
User visits
↓
Static HTML served instantly
Once deployed, no rendering is needed for each request because the HTML already exists.
Advantages
Extremely fast.
Excellent SEO.
Low server costs.
Can be served directly from a CDN.
Disadvantages
Content doesn't update until the site is rebuilt.
Not suitable for frequently changing data.
Best Use Cases
Static Site Generation is perfect for:
Blogs
Documentation
Portfolio websites
Company landing pages
Marketing sites
Incremental Static Regeneration (ISR)
One limitation of SSG is that the content becomes outdated until another build is performed.
ISR solves this problem.
Imagine you've configured:
export const revalidate = 60;
This tells Next.js to regenerate the page at most once every 60 seconds.
Here's what happens:
Visitor requests page
↓
Receives cached HTML
↓
Cache expires
↓
Next visitor requests page
↓
Old page returned immediately
↓
Background regeneration starts
↓
Cache updated
↓
Future visitors receive fresh page
The key advantage is that users never wait for regeneration to complete.
Advantages
Nearly as fast as static pages.
Automatically updates content.
Great balance between performance and freshness.
Disadvantages
Content may remain slightly outdated until regeneration occurs.
More complex than traditional SSG.
Best Use Cases
ISR is excellent for:
Product catalogs
Blogs with frequent updates
Documentation sites
News articles
Public APIs with periodically changing data
React Server Components
This is where many developers become confused.
React Server Components are not another rendering strategy.
Instead, they determine where a component executes.
A Server Component runs on the server.
A Client Component runs inside the browser.
These are completely separate from CSR, SSR, SSG, and ISR.
A Server Component can:
Fetch data directly from a database.
Read files.
Access environment variables.
Use server-only APIs.
Keep secrets on the server.
However, it cannot use browser features.
For example, this is not allowed:
useState()
useEffect()
window
document
localStorage
Those APIs only exist inside the browser.
Whenever you need browser interactivity, you create a Client Component.
'use client';
Client Components can use React hooks, browser APIs, and event handlers.
In a modern Next.js application, it's common to combine both types of components within the same page.
For example:
Page
├── Server Component
│ ↓
│ Fetches blog posts
│
├── Client Component
│ ↓
│ Search box
│
├── Client Component
│ ↓
│ Like button
│
└── Server Component
↓
Footer
This combination allows Next.js to send less JavaScript to the browser while keeping interactive features where they're needed.
Putting Everything Together
Think of Next.js as having two separate concepts.
The first decides how pages are rendered.
Rendering Strategies
CSR
SSR
SSG
ISR
The second decides where components execute.
Component Types
Server Components
Client Components
These concepts work together rather than replacing one another.
For example:
A page can use SSR with Server Components.
A page can use SSG with Client Components.
A page can use ISR with both Server and Client Components.
This flexibility is one of the reasons Next.js has become so popular.
Which Rendering Strategy Should You Choose?
Choosing the right rendering strategy depends on the type of application you're building.
ApplicationRecommended StrategyBlogSSGPortfolioSSGDocumentationSSGProduct CatalogISRE-commerce Product PagesISR or SSRAdmin DashboardSSRUser DashboardSSRChat ApplicationCSRSocial Media AppCSRMarketing WebsiteSSG
There's no single "best" rendering strategy. The right choice depends on how often your data changes, how important SEO is, and how interactive your application needs to be.
Common Misconceptions
Let's clear up a few common misunderstandings.
❌ Server Components replace SSR
No.
Server Components decide where components execute.
SSR decides when HTML is generated.
These are different concepts.
❌ Client-Side Rendering means there is no HTML
Incorrect.
There is always HTML.
The question is whether the browser or the server created it.
❌ SSR is always faster
Not necessarily.
SSR usually improves the initial page load, but every request requires server work.
For content that rarely changes, SSG is often faster.
❌ Static pages can't display dynamic data
They can.
Static pages can use Client Components to fetch dynamic data after the page loads, or they can use ISR to periodically regenerate the HTML.
❌ React Server Components eliminate APIs
Not always.
They can fetch data directly from a database or server-side resources, reducing the need for some internal API routes. However, APIs are still necessary when exposing services to external clients, mobile apps, third-party integrations, or other systems.
A Simple Mental Model
Whenever you're confused, ask yourself these two questions.
Question 1: Where was the HTML generated?
In the browser → CSR
On the server for every request → SSR
During the build process → SSG
During the build process and regenerated later → ISR
Question 2: Where does this component execute?
In the browser → Client Component
On the server → Server Component
These two questions will help you identify almost any rendering scenario in Next.js.
Final Thoughts
The browser always follows the same rendering pipeline: it parses HTML into a DOM, applies CSS, calculates layout, paints pixels, and composites layers to display the page.
What changes between CSR, SSR, SSG, and ISR is who generates the HTML and when it is generated.
React Server Components add another dimension by determining where individual components execute, allowing Next.js to reduce the amount of JavaScript sent to the browser while keeping interactive features where they're belong.
Once you understand these ideas separately, Next.js becomes much easier to reason about. Rather than memorizing acronyms, you'll be able to choose the rendering strategy that best fits your application's needs and explain exactly why.