CSR vs SSR vs SSG in Next.js
Next.js supports multiple rendering strategies that affect SEO, performance, scalability, caching, and user experience. Understanding CSR, SSR, and SSG is one of the most commonly asked frontend interview topics.
CSR (Client Side Rendering)
In Client Side Rendering (CSR), the browser initially receives minimal HTML from the server along with a JavaScript bundle. React then executes in the browser, fetches required data, and renders the UI on the client side. This approach creates highly interactive applications but can negatively impact SEO and initial page load performance because users may initially see a blank page before JavaScript finishes executing.

How It Works
- Browser requests page
- Server sends minimal HTML + JS bundle
- React hydrates application
- Browser renders UI
Real World Usage
CSR is commonly used for dashboards, admin panels, analytics tools, and highly interactive applications.
Pros
- Rich interactivity
- Fast client-side navigation
- Good for dynamic dashboards
Cons
- Poor SEO
- Slower initial render
- Heavy JavaScript bundle
Example
"use client";
import { useEffect, useState } from "react";
export default function UsersPage() {
const [users, setUsers] = useState([]);
useEffect(() => {
fetch("/api/users")
.then((res) => res.json())
.then(setUsers);
}, []);
return (
<div>
{users.map((user) => (
<p key={user.id}>{user.name}</p>
))}
</div>
);
}
Interview Tips
- Mention hydration when explaining CSR.
- Talk about SEO limitations.
- Explain bundle size impact.
SSR (Server Side Rendering)
In Server Side Rendering (SSR), the server generates fully rendered HTML for every incoming request before sending it to the browser. The browser immediately displays meaningful content, which improves SEO and initial page performance. After the HTML reaches the client, React hydrates the application to make it interactive.

How It Works
- Request reaches server
- Server fetches data
- Server renders HTML
- Browser receives complete page
- Hydration attaches interactivity
Real World Usage
SSR is commonly used for ecommerce websites, blogs with dynamic content, news platforms, and SEO-heavy applications.
Pros
- Excellent SEO
- Better first contentful paint
- Fresh server-side data
Cons
- Higher server cost
- Slower than static pages
- Increased server load
Example
export default async function ProductsPage() {
const products = await fetch(
"https://api.example.com/products",
{
cache: "no-store",
}
).then((res) => res.json());
return (
<div>
{products.map((product) => (
<p key={product.id}>
{product.name}
</p>
))}
</div>
);
}
Interview Tips
- Mention hydration after HTML delivery.
- Explain why SSR improves SEO.
- Discuss server load tradeoffs.
SSG (Static Site Generation)
Static Site Generation (SSG) generates HTML during the build process instead of generating it for every request. The generated pages are deployed to a CDN and served instantly to users. Because pages are pre-rendered and cached globally, SSG provides excellent performance, scalability, and SEO.

How It Works
- Application builds during deployment
- Pages are pre-rendered into static HTML
- CDN serves static files instantly
Real World Usage
SSG is ideal for blogs, documentation sites, landing pages, marketing websites, and portfolios.
Pros
- Extremely fast performance
- Excellent SEO
- Low server cost
- Highly cacheable
Cons
- Requires rebuild for updates
- Not suitable for real-time dynamic data
Example
export default async function BlogPage() {
const posts = await fetch(
"https://api.example.com/posts",
{
cache: "force-cache",
}
).then((res) => res.json());
return (
<div>
{posts.map((post) => (
<p key={post.id}>{post.title}</p>
))}
</div>
);
}
Interview Tips
- Mention CDN caching advantages.
- Explain build-time rendering.
- Compare SSG with SSR carefully.
Comparison
CSR, SSR, and SSG all solve rendering differently.
| Feature | CSR | SSR | SSG |
|---|---|---|---|
| Rendering Location | Browser | Server | Build Time |
| SEO | Poor | Excellent | Excellent |
| Initial Load Speed | Slow | Medium | Very Fast |
| Client Side Navigation | Excellent | Good | Excellent |
| Server Load | Low | High | Very Low |
| Data Freshness | Real-Time | Fresh Per Request | Build-Time Data |
| Scalability | High | Medium | Excellent |
| Best Use Cases | Dashboards, SaaS Apps | Ecommerce, News Sites | Blogs, Docs, Landing Pages |
| Caching | Browser Cache | Difficult | Excellent CDN Caching |
| Time To First Byte | Fast | Slower | Very Fast |
| Hydration Needed | Yes | Yes | Yes |
| Infrastructure Cost | Low | High | Very Low |
| Offline Support | Possible | Limited | Excellent |
| Suitable For Dynamic Data | Excellent | Excellent | Poor |