The Simplest Explanation of Rendering Techniques like CSR, SSR, SSG, ISR, and RSC

Most people fumble when explaining these concepts in interviews, or they’re completely clueless while explaining these concepts by giving textual definitions only.

But honestly, these concepts are much simpler when you stop looking at them as complicated rendering strategies and instead ask one question:

“Where is the HTML being generated?”

That’s literally the core idea behind almost all modern rendering patterns.

Once you understand this, frameworks like Next.js start making much more sense.

Let’s start.

1. CSR - Client Side Rendering

This is the default behavior of normal React apps.

Here’s what happens:

• The server sends a mostly empty HTML file and JS files
• The browser downloads the JS files
• React runs in the browser and generates/updates the DOM
• The browser renders the final UI on the screen.

So the rendering happens on the client side (browser). That’s why React apps sometimes show a blank white screen for a moment before loading.

Why people still use CSR -

Once the app loads, everything feels extremely smooth and fast because navigation happens without reloading the page.

That’s why dashboards, chat apps, and highly interactive apps often use CSR heavily.

The tradeoff -

SEO. Search engines prefer ready HTML content. In CSR, the HTML is mostly empty initially, so SEO becomes weaker compared to server-rendered approaches as the crawlers aren’t able to see the content in the HTML initially

2. SSR - Server Side Rendering

SSR flips the process.

Instead of the browser generating the page, the server generates the HTML first and sends a fully rendered page to the browser.

This means users can see content immediately.

SSR is great when -

• Data changes frequently
• SEO matters
• You want fresh content on every request

Examples: E-commerce products, Social platforms

The tradeoff -

Since the server renders the page for every request, it can be slower and more expensive than serving static pages.

3. SSG - Static Site Generation

SSG is basically “pre-building” pages.

Instead of generating HTML on every request, the HTML is generated during build time and stored as static files. When users visit the page, the server simply sends that ready-made HTML instantly.

This makes SSG incredibly fast.

Best use cases

SSG works best for pages that don’t change often:

• About pages
• Blog posts
• Landing pages

This is one reason why Next.js became so popular. It made static generation extremely easy.

One important misconception

People often think SSG means “the data is always old.” Not necessarily. Modern frameworks support revalidation and regeneration, which leads to ISR.

4. ISR - Incremental Static Regeneration

ISR is like a mix of SSG and SSR.

The page is initially generated statically, but it can automatically regenerate in the background after a certain time interval.

So you get:

• Static-site speed
• Better scalability
• Fresher data

Without rebuilding the entire application.

This is extremely useful for :- blogs pages, product pages, large content websites

Because rebuilding thousands of pages every time would be painful.

5. RSC - React Server Components

This is where many developers get confused.

React Server Components are not exactly another rendering strategy like CSR or SSR.

Instead, they decide:

“Where should this component run?”

In modern Next.js apps:

• Server Components run on the server
• Client Components run in the browser

By default, components are server components.

If you add:

"use client"
// below component which will run on the client side

then that component runs in the browser and can use:

• react hooks like useState & useEffect
• browser APIs

The biggest misunderstanding

Many beginners think: ***"use client" = CSR***

But that’s not true. A page can still be server-rendered while containing client components inside it.

IN SUMMARY -

Thank you for reading…