Next.js SSR vs SSG: When to Use Each

Next.js is a powerful React framework that enables developers to build fast, SEO-friendly web applications. One of the key features that sets it apart is its flexible data fetching strategies — namely SSR (Server-Side Rendering) and SSG (Static Site Generation). In this post, we’ll break down what these terms mean, when to use each, and show practical examples using modern Next.js App Router patterns.

🧠 What is Server-Side Rendering (SSR)?

With SSR, the HTML for a page is generated on the server at every single request. This ensures that the data is always fresh and up to date.

✅ Pros:

• Real-time, fresh data on every request.
• Highly SEO-friendly for dynamic data.
• Works perfectly with user-specific or personalized content.

❌ Cons:

• Slower Time to First Byte (TTFB) compared to static pages.
• Higher load on your server or hosting provider.

🔧 How to Use SSR in Modern Next.js (App Router)

In the modern Next.js App Router, every Server Component is dynamic by default if you use dynamic functions or data fetching without explicit caching. You can also explicitly force dynamic rendering:

// app/products/page.tsx
import React from 'react';

// Forces dynamic server-side rendering on every request
export const dynamic = 'force-dynamic';

async function getProducts() {
  const res = await fetch('[https://api.example.com/products](https://api.example.com/products)', { cache: 'no-store' });
  return res.json();
}

export default async function ProductsPage() {
  const products = await getProducts();

  return (
    <div>
      <h1>Live Product List (SSR)</h1>
      <ul>
        {products.map((p: any) => (
          <li key={p.id}>{p.name}</li>
        ))}
      </ul>
    </div>
  );
}

---

🧊 What is Static Site Generation (SSG)?

With SSG, the HTML is generated once at build time. The cached result is then served instantly to every user request.

✅ Pros:

• Super fast page loads (ideal for performance metrics).
• Minimal server load (can be hosted on a simple CDN).
• Ideal for documentation, marketing, and static content.

❌ Cons:

• Content becomes stale until you trigger a full site rebuild.
• Not suitable for real-time or user-specific data.

🔧 How to Use SSG in Modern Next.js (App Router)

By default, standard fetch requests in Next.js are cached aggressively, which gives you SSG out of the box:

// app/blog/page.tsx
import React from 'react';

async function getPosts() {
  // Cached by default (SSG)
  const res = await fetch('[https://api.example.com/posts](https://api.example.com/posts)');
  return res.json();
}

export default async function BlogPage() {
  const posts = await getPosts();

  return (
    <div>
      <h1>Static Blog Posts (SSG)</h1>
      <ul>
        {posts.map((post: any) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </div>
  );
}

---

🔄 Bonus: ISR (Incremental Static Regeneration)

Next.js also allows incremental static regeneration, where static pages can be updated in the background after deployment without rebuilding the entire site.

async function getPosts() {
  const res = await fetch('[https://api.example.com/posts](https://api.example.com/posts)', {
    next: { revalidate: 60 }, // Revalidate every 60 seconds
  });
  return res.json();
}

---

🧪 Use Cases Comparison

Use Case	Recommended Strategy
Product pages with live inventory	SSR
Blog posts & documentation	SSG or ISR
User dashboards & profiles	SSR (Dynamic)
Marketing landing pages	SSG
Frequently updated news	ISR or SSR

💡 Final Thoughts

Choosing between SSR and SSG depends entirely on your data requirements. When in doubt, use SSG for static, content-driven pages and SSR when data needs to be fresh on every click. With modern Next.js, mixing both approaches inside the same application has never been easier.