Rahul Sharma

Posted on Jun 1

Frontend Interview Guide: Understanding Every Rendering Strategy

#webdev #productivity #javascript #react

As frontend developers our main job seems easy:

Fetch data render components and show information on the screen.

At first it doesn't seem like theres much to think about. If the page works and users can see the content the job is done.

That's not exactly true.

In applications rendering a page is more than just showing UI. We need to think about things like:

How fast should the page load?
Can search engines index the content?
How many users will visit the application?
How often does the data change?
Are we building a blog, an e-commerce store or a dashboard?

The answers to these questions affect how we choose to render our application.

A rendering strategy that works for a dashboard may not work for a blog. What works for a portfolio website may not scale well for an e-commerce platform with millions of users.

That's why modern frameworks like React and Next.js offer rendering approaches such as:

Client-Side Rendering (CSR)
Server-Side Rendering (SSR)
Static Site Generation (SSG)
Incremental Static Regeneration (ISR)
Streaming SSR
React Server Components (RSC)

When I was in college I thought rendering was just React taking JSX and displaying it on the screen.. After working on real projects I realized that understanding rendering strategies is a big difference, between knowing React and understanding how modern web applications work.

If you're a student, a fresher or someone starting a frontend development career this article may change how you think about rendering.

Lets explore why these rendering strategies exist and when to use each one, like Client-Side Rendering, Server-Side Rendering and so on.

Why Rendering Strategies Exist

Imagine if Amazon, YouTube, Gmail, and your personal portfolio all used the exact same rendering strategy.

Sounds reasonable at first, right?

But think about it:

A portfolio website might update once a month.
An e-commerce site changes prices and inventory constantly.
YouTube serves millions of videos and recommendations every minute.
Gmail needs real-time interactions and doesn't care much about SEO.

Clearly, these applications have completely different requirements.

If they all used the same rendering approach:

Some would load slower than necessary.
Some would struggle with SEO.
Some would put unnecessary load on servers.
Some would deliver a poor user experience.

This is exactly why different rendering strategies exist.

As frontend developers, our goal isn't just to render components—it's to render them in the most efficient way possible based on the application's needs, traffic, SEO requirements, and user experience goals.

That's where rendering strategies like CSR, SSR, SSG, ISR, Streaming SSR, and React Server Components come into the picture.

Each one solves a different problem, and understanding those problems is what separates a React developer from a frontend engineer.

Rendering Evolution Timeline

This topic is extremely important from an interview perspective.

Interviewers often ask:

"Why do we have multiple rendering strategies instead of one?"

The answer is simple: every new rendering strategy was introduced to solve a limitation of the previous one.

Server Rendering
      ↓
CSR
      ↓
SSR
      ↓
SSG
      ↓
ISR
      ↓
Streaming SSR
      ↓
RSC

Understanding this evolution helps you answer the "why" behind each rendering method, not just the definitions.

CSR — Client-Side Rendering

Short Definition

Client-Side Rendering (CSR) is a rendering strategy where the browser downloads JavaScript first, and React renders the page on the user's device.

In simple words:

The server sends minimal HTML, and the browser builds the UI.

Real-Life Example

Imagine ordering a table from IKEA.

Instead of receiving a fully assembled table, you receive:

Wooden parts
Screws
Instructions

You assemble everything at home.

CSR works the same way.

The server sends the required files, and the browser assembles the final UI.

How It Works

1. User requests a page
          ↓
2. Server sends HTML + JavaScript
          ↓
3. Browser downloads JavaScript
          ↓
4. React executes in browser
          ↓
5. UI gets rendered

Example HTML sent by the server:

<div id="root"></div>

React then renders the entire application inside that root element.

Pros

✅ Great user experience after initial load

✅ Fast page navigation

✅ Less work for the server

✅ Ideal for highly interactive applications

Cons

❌ Slower first page load

❌ Poor SEO (search engines may not see content immediately)

❌ Users may see a blank screen while JavaScript loads

❌ Large JavaScript bundles can impact performance

When to Use

CSR works best when:

SEO is not important
Users are authenticated
Application is highly interactive

Examples:

Admin Dashboards
Project Management Tools
CRM Systems
Internal Company Applications

Think of apps like Gmail or Trello, where most interactions happen after the application has loaded.

Interview Tip: CSR improves interactivity but can hurt SEO and initial page load performance because rendering happens in the browser.

SSR — Server-Side Rendering

Short Definition

Server-Side Rendering (SSR) is a rendering strategy where the server generates the complete HTML for every request and sends it to the browser.

In simple words:

The server renders the page before the user receives it.

Real-Life Example

Imagine ordering food from a restaurant.

Instead of receiving raw ingredients and cooking instructions, you receive a fully prepared meal that's ready to eat.

That's exactly how SSR works.

How It Works

1. User requests page
         ↓
2. Server fetches data
         ↓
3. Server generates HTML
         ↓
4. Browser receives ready-to-display page
         ↓
5. React hydrates the page

Pros

✅ Better SEO

✅ Faster first content display

✅ Always serves fresh data

✅ Great for dynamic content

Cons

❌ Server works on every request

❌ Higher server costs

❌ Can be slower under heavy traffic

When to Use

SSR is best when:

SEO matters
Data changes frequently
Content must always be fresh

Examples:

E-commerce product pages
News websites
Travel booking platforms

Interview Tip: SSR improves SEO and initial page load by rendering HTML on the server, but it increases server workload because pages are generated on every request.

SSG — Static Site Generation

Short Definition

Static Site Generation (SSG) creates HTML pages at build time and serves them directly to users.

In simple words:

Build once, serve many times.

Real-Life Example

Imagine a restaurant printing 10,000 menus before opening.

When customers arrive, the menu is already ready—no need to print it again.

That's how SSG works.

How It Works

Build Time
     ↓
Generate HTML
     ↓
Store on CDN
     ↓
User requests page
     ↓
Serve pre-built HTML

Pros

✅ Extremely fast

✅ Excellent SEO

✅ Low server cost

✅ Highly scalable

Cons

❌ Content can become outdated

❌ Requires rebuilding to update pages

❌ Not ideal for frequently changing data

When to Use

SSG is best when:

Content changes rarely
Performance is a top priority
SEO is important

Examples:

Blogs
Documentation sites
Portfolio websites
Marketing pages

Interview Tip: SSG generates pages during build time, making it one of the fastest rendering strategies, but content updates usually require a rebuild.

ISR — Incremental Static Regeneration

Short Definition

ISR is an extension of SSG that allows static pages to be updated automatically after deployment.

In simple words:

Static pages, but with the ability to refresh content periodically.

Real-Life Example

Imagine a restaurant prints menus in advance, but every hour it checks for price changes and prints an updated version if needed.

Customers still get a ready-made menu, but it's not outdated.

How It Works

Build Time
     ↓
Generate Static Page
     ↓
Serve Cached Version
     ↓
Revalidation Time Reached
     ↓
Generate New Version

Pros

✅ Fast like SSG

✅ Better scalability than SSR

✅ Content stays reasonably fresh

✅ Great balance of performance and updates

Cons

❌ Slightly more complex than SSG

❌ Users may briefly see stale content

❌ Cache management considerations

When to Use

ISR is best when:

Content changes occasionally
SEO is important
Full rebuilds are expensive

Examples:

E-commerce product pages
Category pages
News portals
Large content websites

Interview Tip: ISR combines the speed of SSG with the freshness of SSR by regenerating static pages in the background after a specified interval.

Streaming SSR

Short Definition

Streaming SSR sends HTML to the browser in chunks instead of waiting for the entire page to finish rendering.

In simple words:

Show parts of the page as soon as they are ready.

Real-Life Example

Imagine ordering a full-course meal.

Instead of waiting for every dish to be prepared, the restaurant serves:

Soup first
Starter next
Main course later

You can start eating immediately.

How It Works

Request Page
      ↓
Header Ready → Send
      ↓
Products Ready → Send
      ↓
Reviews Ready → Send
      ↓
Page Completes

Pros

✅ Better perceived performance

✅ Faster content visibility

✅ Reduced waiting time

✅ Great user experience

Cons

❌ More complex implementation

❌ Debugging can be harder

❌ Requires modern React features

When to Use

Streaming SSR is best when:

Large pages fetch data from multiple sources
Some sections load slower than others
User experience is a top priority

Examples:

E-commerce websites
Content-heavy platforms
Large dashboards

Interview Tip: Streaming SSR improves perceived performance by sending HTML in chunks, allowing users to see content before the entire page has finished rendering.

Comparison Table

Feature	CSR	SSR	SSG	ISR	Streaming SSR
Rendering Location	Browser	Server	Build Time	Build Time + Background Updates	Server
SEO	❌ Poor	✅ Good	✅ Excellent	✅ Excellent	✅ Good
Initial Load Speed	❌ Slow	✅ Good	🚀 Excellent	🚀 Excellent	✅ Good
Data Freshness	✅ Real-Time	✅ Real-Time	❌ Requires Rebuild	✅ Periodic Updates	✅ Real-Time
Server Load	✅ Low	❌ High	✅ Very Low	✅ Low	⚠️ Medium
Scalability	✅ Good	⚠️ Medium	🚀 Excellent	🚀 Excellent	✅ Good
Complexity	✅ Easy	⚠️ Medium	✅ Easy	⚠️ Medium	❌ High
Best For	Dashboards	Dynamic Content	Blogs & Docs	E-commerce	Large Applications

Quick Summary

CSR → Best for highly interactive applications.
SSR → Best for SEO + frequently changing data.
SSG → Best for maximum performance and static content.
ISR → Best when content updates occasionally.
Streaming SSR → Best for improving perceived performance on large pages.

Interview Tip: If asked which rendering strategy is best, the correct answer is: "It depends on the application's requirements." There is no single best rendering strategy.

Conclusion

There is no "best" rendering strategy—only the right strategy for a specific use case.

As developers, our job isn't just to build components but to choose the most suitable rendering approach based on factors like SEO, performance, scalability, and user experience.

Understanding CSR, SSR, SSG, ISR, and Streaming SSR will not only help you build better applications but also answer one of the most common frontend interview topics with confidence.

Why Rendering Strategies Exist

Rendering Evolution Timeline

CSR — Client-Side Rendering

Short Definition

Real-Life Example

How It Works

Pros

Cons

When to Use

SSR — Server-Side Rendering

Short Definition

Real-Life Example

How It Works

Pros

Cons

When to Use

SSG — Static Site Generation

Short Definition

Real-Life Example

How It Works

Pros

Cons

When to Use

ISR — Incremental Static Regeneration

Short Definition

Real-Life Example

How It Works

Pros

Cons

When to Use

Streaming SSR

Short Definition

Real-Life Example

How It Works

Pros

Cons

When to Use

Comparison Table

Quick Summary

Conclusion

Top 10 Rendering Interview Questions