Rendering in Next.js: Making Sense of CSR, SSR, SSG, and ISR

As front-end developers, we deal with more than just pixels and colors. One of the most important choices we make is: when and where should our app render its content? 
 
If you've worked with Next.js, you've likely come across terms like CSR, SSR, SSG, and ISR. At first, these might sound like scary acronyms, but they’re simply different ways your app can render content. And knowing which one to use — and when — can make a big difference in your app's speed, SEO, and user experience. 
 
So, let’s take a little walk through the world of rendering strategies. Imagine we’re designing an app together, and we have different needs for different pages. Depending on the goal of the page, we pick the best rendering approach — like choosing the right tool from a toolbox. 

Client-Side Rendering (CSR) 

Client-Side Rendering lets the browser do the heavy lifting. When a user visits a page, the server sends a minimal HTML shell along with JavaScript files. Once the browser downloads and executes the JavaScript, the page content is dynamically constructed and rendered.

How CSR Works?

1. Initial Request: The browser sends a request to the server.
2. Server Response: The server responds with a minimal HTML shell and links to JavaScript assets.
3. Browser Processing: The browser downloads and executes the JavaScript. React runs in the browser, rendering components and populating data via API calls.
4. Content Display: The final content appears only after JavaScript is fully loaded and executed.

When to use CSR?

• For authenticated or user-specific views, such as dashboards.
• When SEO is not a priority.
• For applications that require dynamic interactivity and update frequently after load.

Real-world example: A banking dashboard where your balance and transactions load after you log in. 

// app/news/page.tsx
export default async function NewsPage() {
  const res = await fetch('https://api.site.com/news', {
    next: { revalidate: 600 }, // Regenerate every 10 minutes
  });
  const news = await res.json();

  return (
    <ul>
      {news.map(item => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>
  );
}

Why Client-Side? It’s fast after the first load and great for user-specific, interactive UIs. 

Server-Side Rendering (SSR) 

Server-Side Rendering fetches data and returns a fully rendered HTML page for every request. 

How SSR Works?

1. Initial Request: The browser sends a request to the server.
2. Data Fetching: The server fetches the necessary data (e.g., from a database or external API).
3. HTML Generation: The server renders the full HTML page with the data already embedded.
4. Server Response: The complete HTML is sent to the browser.
5. Hydration: The browser loads JavaScript and "hydrates" the HTML to make it interactive using React.

When to Use SSR

• For pages with frequently changing or dynamic content.
• When SEO is important, and you want crawlers to see fully rendered HTML.
• When you want fresh content to be delivered on every request.

Real-world example: A product detail page that shows live inventory and dynamic pricing. 

// app/product/[id]/page.tsx
export default async function Page({ params }) {
  const res = await fetch(`https://api.site.com/products/${params.id}`, {
    cache: 'no-store',
  });
  const data = await res.json();

  return <h1>{data.name}</h1>;
}

Why Server-Side? Fresh, up-to-date content for every user, with solid SEO benefits. 

Static Site Generation (SSG) 

Static Site Generation builds the HTML during the app's build process and serves it as a static file. 

How SSG Works?

1. Build Phase (One-Time Setup): During deployment, Next.js fetches the required data. HTML files are generated for each page using that data.
2. Deployment: The generated HTML and static assets are uploaded to a CDN.
3. Runtime Request: When a user visits a page, the CDN serves the pre-built static HTML. No backend processing occurs at this stage.

When to Use SSG?

• For pages with rarely changing content.
• Where performance and SEO are key (e.g., blogs, marketing pages).
• When you want high reliability and low server cost.

Real-world example: A personal blog or company 'About Us' page that rarely changes. 

// app/blog/page.tsx
export default async function BlogPage() {
  const res = await fetch('https://api.site.com/posts');
  const posts = await res.json();

  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

Why Static? Speed. Reliability. Minimal server load. And SEO goodness. 

Incremental Static Regeneration (ISR) 

Incremental Static Regeneration is like SSG — but smarter. You can set pages to regenerate after a certain interval, keeping them fast and fresh. 

How ISR Works?

1. Initial Build: At build time, HTML is generated and stored on the CDN, just like SSG.
2. User Request (Before Revalidation Window): The existing static HTML is served directly from the CDN.
3. Revalidation Triggered (In Background): Once the revalidation interval expires, the next user request triggers a background update. Fresh data is fetched, and a new HTML version is generated.
4. Subsequent Requests: Future users receive the updated page without downtime or full rebuild.

When to Use ISR?

• For content that updates periodically (e.g., news, product listings).
• When you want to avoid full rebuilds for minor content updates.
• If you want CDN-level performance with dynamic content refresh.

Real-world example: A news homepage where headlines update every few minutes. 

// app/news/page.tsx
export default async function NewsPage() {
  const res = await fetch('https://api.site.com/news', {
    next: { revalidate: 600 }, // Regenerate every 10 minutes
  });
  const news = await res.json();

  return (
    <ul>
      {news.map(item => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>
  );
}

Why Incremental? Best of both worlds: fast loads, fresh data. 

Summary: When to Use What 

Choosing the right rendering strategy isn’t about right or wrong — it’s about understanding your app’s needs and your users’ expectations. 

Use CSR for private dashboards. Go for SSR when content is dynamic and SEO matters. Choose SSG for timeless, static content. And lean on ISR when you want performance and periodic freshness. 

Once you get the hang of these, rendering stops being a guess — and becomes a superpower. 

Happy coding!