Confused by Next.js rendering? This guide breaks down SSG, SSR, ISR, and CSR from a Senior DevOps perspective, telling you exactly when to use each to build fast, scalable apps and avoid production fires.

SSG, SSR, ISR, CSR? A Senior Engineer’s Guide to Ending the Next.js Rendering Debate.

I still remember the 3 AM PagerDuty alert. “Site Down – High CPU”. It was our biggest product launch of the year. The marketing team had built a beautiful, dynamic landing page in Next.js. The problem? They used Server-Side Rendering (SSR) for every single visit. When the launch-day traffic hit, our web-app-prod-01 cluster just… melted. We were serving the same ‘dynamic’ page to thousands of users per second, re-rendering it from scratch every single time. It was a bloodbath. That’s when I learned, the hard way, that choosing your rendering strategy in Next.js isn’t an academic exercise—it’s the difference between a smooth launch and a career-limiting event.

The Real Question: “When Do We Build the HTML?”

Let’s cut through the noise. This whole acronym soup boils down to one simple question: When do we compute the final HTML for a page? Is it done once when you deploy? Is it done for every single person who visits? Is it done in the user’s browser? The answer dictates your server costs, your site’s speed, and whether you sleep through the night during a launch. Get this wrong, and you’re either paying a massive cloud bill for no reason or serving stale data to your users.

Here’s a cheat sheet I wish I had when I started. We’ll break it down right after.

The Strategies: Your Rendering Toolkit

Strategy 1: The Fortress (SSG – Static Site Generation)

This is your default. Your rock. Your fortress of solitude. With SSG, you generate all the HTML for your pages once, at build time. The result is a folder of plain old HTML, CSS, and JS files. You can throw these on any CDN (like Vercel, Netlify, or AWS S3/CloudFront) and it will be absurdly fast and cheap to serve.

When to use it: Any page where the content is the same for every user and doesn’t change from second to second. Think documentation sites, the company blog, marketing landing pages, or a “Terms of Service” page. If you can build it once and forget about it until the next code push, use SSG.

// pages/posts/[slug].js

// This function runs at BUILD TIME on the server.
export async function getStaticProps({ params }) {
  const post = await getPostFromDatabase(params.slug);
  return {
    props: {
      post,
    },
  };
}

// Your page component gets the 'post' as a prop.
function PostPage({ post }) {
  // Render post...
}

Pro Tip: Don’t underestimate the power of SSG. My rule of thumb is: “Start with SSG for everything, then move away from it only when you have a very good reason.” It solves most performance problems before they even start.

Strategy 2: The Live Tailor (SSR – Server-Side Rendering)

This is the high-powered, expensive tool in your kit. With SSR, the server generates the HTML from scratch for every single request. It’s like having a personal tailor who crafts a brand new suit for every person who walks in the door. It’s powerful, but it’s resource-intensive. This was the strategy that torched my servers during that launch.

When to use it: When a page’s content is highly dynamic, personalized, and must be up-to-the-second fresh for SEO or the initial view. Think of a user’s account dashboard, a banking portal, or a flight search results page. If the page is behind a login and is unique to that user, SSR is a strong contender.

// pages/dashboard.js

// This function runs on EVERY REQUEST on the server.
export async function getServerSideProps(context) {
  const user = await getUserFromSession(context.req);

  if (!user) {
    // Redirect to login if no user
    return { redirect: { destination: '/login', permanent: false } };
  }

  const data = await getDashboardDataForUser(user.id);
  return {
    props: {
      user,
      data,
    },
  };
}

function Dashboard({ user, data }) {
  // Render dashboard for the specific user...
}

Warning: Be very careful with SSR on public-facing pages that get a lot of traffic. A single slow database query in getServerSideProps can bring your entire site to a crawl. Use it surgically.

Strategy 3: The Hybrid Hero (ISR – Incremental Static Regeneration)

This is the “hacky” but brilliant solution that feels like a cheat code. ISR is SSG with a timer. You build a static page at deploy time, but you give it a “time-to-live”. For example: “This page is good for 60 seconds.” The first person to visit after 60 seconds gets the old (stale) page instantly, which is great for speed. In the background, Next.js triggers a rebuild. Everyone who visits after that gets the fresh new version. It’s the best of both worlds: the speed of static with the freshness of dynamic.

When to use it: Pages with popular content that updates periodically, but not in real-time. An e-commerce site’s product catalog, a news organization’s homepage, a list of top blog posts. You want it fresh, but you can tolerate a few seconds or minutes of staleness.

// pages/products/[id].js

// This is just getStaticProps...
export async function getStaticProps({ params }) {
  const product = await getProductFromApi(params.id);
  return {
    props: {
      product,
    },
    // ...with this magic key! Re-generate this page at most
    // once every 60 seconds.
    revalidate: 60, 
  };
}

function ProductPage({ product }) {
  // Render the product page...
}

Strategy 4: The ‘Nuclear’ Option (CSR – Client-Side Rendering)

Sometimes, you just need a blank canvas. With CSR, your server sends a minimal HTML shell, and a large JavaScript bundle does all the heavy lifting in the user’s browser. It fetches data from your APIs and builds the UI from scratch. This is how traditional Single-Page Applications (SPAs) like old-school React apps work.

When to use it: For pages that are less like “pages” and more like “applications.” Think of a complex admin dashboard with dozens of filters, charts, and tables that update constantly based on user input. Think Figma, Google Sheets, or the AWS Console. The initial load might be slow (a blank screen while the JS loads), but once it’s running, it’s incredibly interactive.

// pages/app/analytics.js
import { useState, useEffect } from 'react';

// No server-side data fetching functions here!
export default function AnalyticsDashboard() {
  const [data, setData] = useState(null);
  const [isLoading, setLoading] = useState(true);

  useEffect(() => {
    fetch('/api/analytics-data')
      .then((res) => res.json())
      .then((data) => {
        setData(data);
        setLoading(false);
      });
  }, []);

  if (isLoading) return <p>Loading dashboard...</p>;
  if (!data) return <p>No data found.</p>;

  // Render your complex, interactive dashboard using the 'data'
  return <div>...</div>;
}

My Final Take

There is no “best” rendering method. There is only the “right” method for the job. A great Next.js application isn’t just one of these; it’s a mix of all four. The blog is SSG, the homepage is ISR, the user dashboard is SSR, and the heavy reporting tool is CSR. The mark of a senior engineer isn’t knowing the fanciest solution, it’s knowing which problem each solution was designed to solve. Start with static, and only add complexity when the page’s requirements demand it. Your servers—and your on-call schedule—will thank you.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions