🚀 Next.js Rendering Strategies: The Restaurant Kitchen Story

Imagine you run a restaurant. How you prepare food for customers can make or break their experience. Next.js rendering strategies work exactly like different kitchen styles!

🎯 The Big Picture

Think of a webpage as a meal and the server as the kitchen.

🍳 Server-Side Rendering (SSR)

What Is It?

SSR = Cook fresh for every customer

When someone visits your page, the server cooks the entire meal (builds the HTML) right then and serves it hot.

Simple Example

Imagine a news website:

1. You click a news article
2. Server fetches the latest comments
3. Server builds the complete page
4. You see everything instantly!

// pages/news.js
export async function getServerSideProps() {
  // This runs on EVERY request
  const news = await fetch('api/latest-news')
  return { props: { news } }
}

When to Use SSR?

✅ Use when:

• Data changes frequently (stocks, news)
• Content is personalized per user
• You need real-time information

❌ Avoid when:

• Content rarely changes
• Speed is critical (SSR is slower)

The Trade-off

🏪 Static Site Generation (SSG)

What Is It?

SSG = Pre-cook everything before opening

The kitchen prepares ALL meals before the restaurant opens. When customers arrive, food is served instantly!

Simple Example

Think of a blog post:

1. You write an article
2. At build time, Next.js creates the HTML
3. When visitors come, they get the pre-made page
4. Super fast! No waiting!

// pages/blog/[slug].js
export async function getStaticProps({ params }) {
  // Runs at BUILD time only
  const post = await getPost(params.slug)
  return { props: { post } }
}

export async function getStaticPaths() {
  // Which pages to pre-build
  return {
    paths: [
      { params: { slug: 'hello-world' } },
      { params: { slug: 'intro-nextjs' } }
    ],
    fallback: false
  }
}

When to Use SSG?

✅ Use when:

• Content rarely changes (blog, docs)
• Same content for everyone
• Speed is critical

❌ Avoid when:

• Data changes often
• Content is user-specific

The Trade-off

🔄 Incremental Static Regeneration (ISR)

What Is It?

ISR = Pre-cook + refresh the menu periodically

This is the best of both worlds! Pre-cook meals, but update them automatically every few minutes.

Simple Example

An e-commerce product page:

1. Page is pre-built at build time
2. Customer visits and gets fast page
3. After 60 seconds, Next.js checks for updates
4. Next visitor gets the fresh version!

// pages/products/[id].js
export async function getStaticProps({ params }) {
  const product = await getProduct(params.id)

  return {
    props: { product },
    revalidate: 60  // Refresh every 60 seconds!
  }
}

The Magic of revalidate

revalidate: 60 means:
┌─────────────────────────────────────┐
│ 0-60 sec: Serve cached page         │
│ After 60s: Rebuild in background    │
│ Next visitor: Gets fresh page       │
└─────────────────────────────────────┘

When to Use ISR?

✅ Use when:

• Content updates periodically (prices, inventory)
• You want speed + freshness
• Building all pages takes too long

❌ Avoid when:

• Data must be real-time (stocks)
• Content is user-specific

The Trade-off

🎨 Client-Side Rendering (CSR)

What Is It?

CSR = Let the customer cook at their table

The kitchen sends ingredients and a recipe. The customer’s browser cooks the meal!

Simple Example

A dashboard with user data:

1. Browser loads empty page + JavaScript
2. JavaScript fetches your personal data
3. Browser builds what you see
4. Interactive immediately!

// components/Dashboard.js
import { useState, useEffect } from 'react'

function Dashboard() {
  const [data, setData] = useState(null)

  useEffect(() => {
    // Runs in the BROWSER
    fetch('/api/my-data')
      .then(res => res.json())
      .then(setData)
  }, [])

  if (!data) return <p>Loading...</p>
  return <div>{data.name}'s Dashboard</div>
}

When to Use CSR?

✅ Use when:

• Page is behind login
• Data is user-specific
• SEO doesn’t matter
• Highly interactive features

❌ Avoid when:

• SEO is important
• Users have slow devices
• Initial load speed matters

The Trade-off

🗺️ Decision Flowchart

graph TD
    A["New Page Needed"] --> B{SEO Important?}
    B -->|No| C["CSR"]
    B -->|Yes| D{Data Changes?}
    D -->|Never| E["SSG"]
    D -->|Sometimes| F["ISR"]
    D -->|Every Request| G["SSR"]

🎯 Quick Comparison

💡 Real-World Examples

🧙‍♂️ Pro Tips

Mixing Strategies

You can use different strategies for different pages!

/            → SSG (marketing page)
/blog        → SSG (articles)
/products    → ISR (prices update)
/dashboard   → CSR (user data)
/news        → SSR (live updates)

Fallback for ISR

When someone visits a page that wasn’t pre-built:

export async function getStaticPaths() {
  return {
    paths: [...],
    fallback: 'blocking'
    // or true, or false
  }
}

🎉 You Did It!

You now understand the four cooking styles of Next.js:

1. SSR = Fresh meal every time (slower but always current)
2. SSG = Pre-made meals (lightning fast but can be stale)
3. ISR = Pre-made + auto-refresh (best of both worlds)
4. CSR = Cook in browser (great for private, interactive stuff)

Pick the right strategy for each page, and your Next.js app will be fast, fresh, and fantastic! 🚀