DEV Community

Giorgi Parunov
Giorgi Parunov

Posted on

Static Site Generation (SSG) vs Server-Side Rendering (SSR) in Next.js: A Deep Dive

As modern web applications demand high performance, excellent SEO, and real-time interactivity, Next.js emerges as a full-stack React framework that empowers developers to choose the right rendering strategy for each page. Two of its core rendering modes—Static Site Generation (SSG) and Server-Side Rendering (SSR)—offer distinct advantages depending on the application's requirements.

In this advanced guide, we’ll dissect SSG and SSR in Next.js with technical explanations, use cases, code examples, performance insights, and a decision framework.

What is Static Site Generation (SSG)?

SSG pre-renders pages at build time, generating static HTML, JSON payloads, and assets that can be deployed to a CDN for ultra-fast global delivery.

How it Works:

  • The getStaticProps() function is executed during the build process.
  • For dynamic routes, getStaticPaths() is also called to determine which paths to generate.
  • Output is stored as .html and .json files in .next/ and deployed to static hosting.

Example:

// pages/blog/[slug].tsx

export async function getStaticPaths() {
  const data = await fetchAll();
  return {
    paths: data.map(slug => ({ params: { slug } })),
    fallback: 'blocking'
  };
}

export async function getStaticProps({ params }) {
  const post = await fetchPostBySlug(params.slug);
  return {
    props: { post },
    revalidate: 60
  };
}
Enter fullscreen mode Exit fullscreen mode

Use Cases:

  • Marketing pages
  • Documentation
  • Product listings (when content updates infrequently)
  • Blog posts

Benefits:

  • 🏎️ Blazing Fast Load Times via CDN
  • 🔒 Reduced Server Load (no backend rendering per request)
  • ✅ Reliable SEO since HTML is pre-rendered
  • 💸 Low Operational Cost using platforms like Vercel or Netlify

Limitations:

  • 🐢 Slow Builds for Large Sites
  • ⚠️ Content Can Be Stale without frequent rebuilds or ISR
  • ❌ Difficult to Personalize (e.g., per-user content or auth logic)

What is Server-Side Rendering (SSR)?

SSR pre-renders HTML on each request. Every time a user visits a page, Next.js executes the page’s getServerSideProps() on the server.

How it Works:

  • The HTML is dynamically generated at runtime.
  • Data fetching, auth checks, and conditional logic are done per request.
  • Useful for personalized, real-time, or data-sensitive content.

Example:

// pages/dashboard.tsx

export async function getServerSideProps(context) {
  const session = await getSession(context.req);

  if (!session) {
    return {
      redirect: { destination: '/login', permanent: false }
    };
  }

  const dashboardData = await fetchDashboardData(session.user.id);

  return {
    props: {
      user: session.user,
      dashboardData
    }
  };
}
Enter fullscreen mode Exit fullscreen mode

Use Cases:

  • User dashboards
  • Admin panels
  • Search results
  • Authenticated pages
  • Real-time financial data or inventory

Benefits:

  • 🔁 Always Up-to-Date content
  • 🔐 Supports Auth & Personalization
  • ✅ SEO-Friendly with server-rendered HTML
  • 🧠 Rich Contextual Logic possible per request

Limitations:

  • 🐢 Slower Time-to-First-Byte (TTFB) compared to SSG
  • 💰 More Server Resources and higher cloud costs
  • 📉 Poorer Performance Under Load without caching
  • 🧩 Higher Operational Complexity (handling failures, retries, etc.)

Hybrid Rendering with Next.js

Next.js allows per-page rendering strategies, enabling hybrid architectures that combine SSG and SSR.

ISR: Incremental Static Regeneration
You can update statically generated pages after deployment using ISR:

export async function getStaticProps() {
  const data = await fetchData();
  return {
    props: { data },
    revalidate: 300 // Regenerates page every 5 minutes
  };
}
Enter fullscreen mode Exit fullscreen mode

Use Case: Updating product prices, blog comments, event schedules without full rebuilds.

** Middleware + Edge + SSR**
You can combine SSR with Next.js Middleware and Edge Functions for lower-latency personalization at the CDN level.

Performance Comparison

Metric SSG SSR
TTFB ~10-50ms (from CDN) 300ms–2s (depends on backend)
SEO Support ✅ Excellent ✅ Excellent
Personalization ❌ Limited (via JS) ✅ Native support
Content Freshness ❌ Stale unless ISR ✅ Always fresh
Complexity ✅ Simple ❌ More complex
Scalability ✅ Global CDN ❌ Needs backend scaling

Decision Framework

Question If YES, Use
Does your content update in real-time or per-user? SSR
Can you precompute pages ahead of time? SSG
Do you need both speed and freshness? ISR
Are you building a marketing or blog site? SSG
Does your app rely on authentication or session? SSR
Is your site large (10k+ pages)? Mix of SSG + ISR + SSR

Conclusion

Next.js doesn't force you to pick just one rendering method—instead, it enables composability. Use SSG for static, high-performance pages. Use SSR where dynamic, personalized content matters. Use ISR to scale the benefits of both.

Modern Next.js apps often mix these strategies intelligently across routes, and even at the component level using React Server Components, Edge Functions, and streaming responses.

The real power of Next.js lies not in choosing SSG or SSR—but in knowing when and where to use them together

Top comments (0)