Rendering Strategies: CSR vs SSR vs SSG vs ISR
Rendering strategy is not about memorizing acronyms. It is about understanding when HTML is generated and where the work happens.
🔥 Insight
Good engineers don’t memorize CSR vs SSR vs SSG. They understand when the user gets meaningful HTML and who pays the cost — server or client.
🧠 Core Mental Model
CSR → HTML late, JS heavy
SSR → HTML early, server per request
SSG → HTML precomputed at build time
ISR → HTML cached + refreshed over timeAll rendering strategies are trade-offs between:
Quick Navigation: CSR • SSR • SSG • ISR • Hydration • Comparison • Decision Guide • Hybrid
The Four Rendering Strategies
Rendering strategies are different ways of shifting work between build time, request time, and client runtime.
- CSR (Client-Side Rendering): browser executes JavaScript and generates most of the UI at runtime
- SSR (Server-Side Rendering): server generates HTML on each request
- SSG (Static Site Generation): HTML is generated at build time
- ISR (Incremental Static Regeneration): static HTML is cached and refreshed over time
Client-Side Rendering (CSR)
In CSR, the browser receives minimal HTML and JavaScript is responsible for generating the UI.
Mental model: HTML arrives late, JavaScript does most of the work.
How CSR Works
✅ Key Point: Static files loaded once, only data fetched on navigation
Advantages
- ✓Fast navigation after load: client-side routing avoids full page reloads
- ✓Rich interactivity: great for dashboards and app-like UIs
- ✓Decoupled architecture: frontend and backend can evolve independently
- ✓Lower request-time server cost: server mainly serves static assets and APIs
Disadvantages
- ✗Slower initial render: UI depends on JavaScript download, parsing, and execution
- ✗SEO can be weaker: content may appear late to crawlers if critical HTML is missing initially
- ✗Higher client CPU and memory cost: especially on low-end devices
- ✗Blank or skeletal initial experience: until app code runs
🎯 Best For:
Dashboards, admin panels, authenticated apps, internal tools, and highly interactive experiences where SEO is not the main requirement.
Server-Side Rendering (SSR)
SSR generates HTML on the server for each request.
How SSR Works
⚠️ Key Point: Each navigation = New server request + New HTML page
Advantages
- ✓Fast initial content display: useful for LCP and perceived performance
- ✓SEO-friendly: crawlers receive meaningful HTML immediately
- ✓Works better under JS failure: content can still appear before interactivity loads
Disadvantages
- ✗Higher server load: HTML is generated per request
- ✗TTFB can grow: expensive server work delays the response
- ✗Still pays hydration cost: fast HTML does not guarantee fast interactivity
🎯 Best For:
SEO-critical pages, public content, dynamic per-request data, and first-load experiences where meaningful HTML should arrive quickly.
Static Site Generation (SSG)
SSG generates HTML during the build process and serves it as static files.
Mental model: HTML is precomputed — close to zero request-time render cost.
How SSG Works
✅ Key Point: HTML generated once at build time, served instantly from CDN
Advantages
- ✓Excellent performance: pre-built HTML served from CDN
- ✓Excellent SEO: full content available in HTML
- ✓Highly scalable: traffic is handled by static infrastructure
- ✓Low request-time cost: no server rendering on each request
Disadvantages
- ✗Content updates need rebuilds: unless paired with revalidation
- ✗Build times can grow: especially for large sites
- ✗Weak fit for personalized content: same HTML for everyone
🎯 Best For:
Blogs, documentation, marketing pages, portfolios, and other mostly static pages that benefit from maximum CDN performance.
Incremental Static Regeneration (ISR)
ISR combines static delivery with periodic regeneration after deployment.
Mental model: HTML is cached and refreshed over time.
How ISR Works
✅ Key Point: Best of both worlds - static performance with dynamic updates
Advantages
- ✓Static-like performance: cached HTML from CDN
- ✓Fresher content: without full rebuilds
- ✓Better scaling for large catalogs: not every page must rebuild every time
Disadvantages
- ✗Stale windows exist: some users may briefly see older content
- ✗Cache invalidation is real complexity: refresh rules need careful design
- ✗Framework/platform support matters: behavior depends on hosting primitives
🎯 Best For:
E-commerce product pages, blog posts, documentation, and content that changes periodically but does not need real-time freshness.
ISR Revalidation Strategies
- Time-based: regenerate every X seconds
- On-demand: trigger updates via webhook or API
- Hybrid: combine scheduled and event-based refresh
Hydration and JavaScript Cost
🔥 Insight
Hydration is not rendering — it is attaching behavior to already-rendered HTML.
What Happens During Hydration
- HTML is already present from SSR or SSG
- JavaScript bundle loads in the browser
- Framework executes component logic again on the client
- Event listeners are attached and interactivity becomes available
Why It Matters
- Large bundles delay interactivity
- JavaScript execution can dominate on low-end devices
- Fast HTML does not automatically mean fast UX
Senior-Level Takeaway
The biggest bottleneck in many modern apps is not HTML generation. It is JavaScript execution, hydration work, and the cost of making the page interactive.
Comparison Table
| Aspect | CSR | SSR | SSG | ISR |
|---|---|---|---|---|
| Initial Load | ⚠ Slower - Must load JS first | ✓ Fast - HTML with data ready | ✓ Fastest - Pre-built HTML | ✓ Fastest - Pre-built HTML |
| Subsequent Navigation | ✓ Fastest - Only data fetched | ✗ Slower - Full page reload | ✓ Fast - Static files | ✓ Fast - Static files |
| SEO | ✗ Poor - JS-rendered content | ✓ Excellent - Pre-rendered HTML | ✓ Excellent - Pre-rendered HTML | ✓ Excellent - Pre-rendered HTML |
| Content Updates | ✓ Instant - Client-side | ✓ Instant - Server-side | ✗ Requires rebuild - Build time | ⚠ Periodic - Revalidation |
| Server Load | ✓ Low - Static files only | ✗ High - Every request | ✓ None - CDN only | ✓ Low - Only on revalidation |
| Build Time | ✓ Fast - No pre-rendering | ✓ Fast - No pre-rendering | ✗ Slow - All pages at build | ⚠ Medium - Initial build |
| Dynamic Content | ✓ Full support | ✓ Full support | ✗ Limited - Static only | ⚠ Periodic updates |
Decision Guide
Choose CSR when
- •SEO is not critical
- •You need highly interactive client-side UX
- •Content is heavily personalized or authenticated
Choose SSR when
- •First-load content visibility matters
- •SEO is important
- •Data changes frequently per request
Choose SSG when
- •Content is mostly static
- •You want maximum CDN performance
- •Rebuild-based publishing is acceptable
Choose ISR when
- •You want SSG-like speed with periodic freshness
- •You have many pages but only some need frequent refresh
- •Full rebuilds are too expensive
🔥 Interview Insight
Most real-world performance issues are not caused by choosing CSR vs SSR. They are caused by excessive JavaScript, poor data fetching, and hydration cost. Understanding where the cost moves matters more than memorizing acronyms.
Hybrid Approaches
Most production apps combine strategies rather than choosing a single one everywhere.
SSR + CSR Hydration
A common hybrid approach is: server render the first HTML, then use client-side routing for later navigation.
What This Looks Like
good for SEO and first paint
interactivity becomes available
faster transitions without full page reload
✅ Key benefit: SEO-friendly initial HTML plus faster app-like navigation afterward.
Performance Benefits
- ✓Fast initial load: Server-rendered HTML shows immediately
- ✓Fast navigation: Client-side routing after hydration
- ✓Progressive enhancement: Works even if JavaScript fails
- ✓Selective hydration: Only hydrate what's needed
SEO Benefits
- ✓Crawlable content: Search engines see full HTML
- ✓Meta tags: Proper Open Graph and Twitter cards
- ✓Social sharing: Rich previews work correctly
UX Benefits
- ✓No blank screen: Content visible immediately
- ✓Smooth transitions: Client-side navigation feels instant
- ✓Works offline: After initial load, app can work offline
When to Use Hybrid Approach
Common Public/App Split
Public pages use SSR or SSG for SEO. Authenticated app areas use CSR for speed and interactivity.
SSG + CSR
Static article content is pre-rendered, but comments, search, or personalization load on the client.
ISR + CSR
Product pages stay fast and cacheable while cart, filters, and user interactions stay client-driven.
Best Practices
- Pick per page, not per app
- Minimize JavaScript on public pages
- Use SSR or SSG where meaningful HTML matters
- Use CSR where interactivity and personalization dominate
- Measure hydration and bundle cost, not just TTFB