When you open a website, have you ever wondered where the HTML actually comes from?
Does the browser build the page itself?
Does the server send a fully rendered page?
Or was the page generated days ago and simply served from a CDN?
The answer depends on the rendering strategy used by the application.
Over the years, frontend frameworks have evolved from Client-Side Rendering (CSR) to Server-Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR), and Streaming Rendering, each solving a specific challenge around performance, scalability, SEO, and user experience.
In this article, we'll explore how these strategies work, why they exist, and how to choose the right one for your application.
The Evolution of Frontend Rendering
Instead of memorizing five different terms, think of them as milestones in the evolution of web rendering.
CSR
↓
SSR
↓
SSG
↓
ISR
↓
Streaming SSR
Every new strategy improves one or more aspects of the previous one.
Client-Side Rendering (CSR)
The first generation of modern SPAs relied heavily on Client-Side Rendering.
Here's what happens when a user visits a page:
Browser
→
HTML
→
JavaScript
→
API
→
Data
→
UI
The server initially returns a minimal HTML shell and a JavaScript bundle. The browser downloads the JavaScript, executes it, fetches data from APIs, and finally renders the UI.
Advantages
- Fast client-side navigation after the initial load
- Rich, interactive experiences
- Simpler backend rendering
- Great developer experience
Drawbacks
- Slow first page load
- Poor SEO without additional optimization
- Large JavaScript bundles
- Blank screen until JavaScript finishes loading
Best For
- Dashboards
- Admin panels
- Internal tools
- Authenticated applications
Why CSR Wasn't Enough
Imagine opening an online store.
With CSR:
- Browser downloads HTML.
- Downloads JavaScript.
- Executes JavaScript.
- Fetches products.
- Finally displays the page.
For search engines and users on slower connections this can lead to delayed content visibility.
This limitation gave rise to Server-Side Rendering.
Server-Side Rendering (SSR)
Instead of sending an empty shell, the server renders the HTML before responding.
The browser immediately receives meaningful HTML, which improves perceived performance and SEO.
Advantages
- Better SEO
- Faster First Contentful Paint (FCP)
- Dynamic, request-specific content
- Easier social sharing with rich previews
Drawbacks
- Higher server workload
- Every request requires server rendering
- Increased infrastructure costs for high traffic
Best For
- E-commerce
- News websites
- Search pages
- Personalized dashboards
But Why Render Every Request?
Consider a blog.
Your homepage changes once a week.
Why should the server regenerate the exact same HTML for every visitor?
This is where Static Site Generation (SSG) shines.
Static Site Generation (SSG)
With SSG, pages are generated during the build process, not when users visit them.
Source
→
Build
→
StaticHTML
→
CDN
→
Browser
Once built, the pages are deployed to a CDN and served instantly.
Advantages
- Extremely fast
- Minimal server cost
- Excellent SEO
- High scalability
Drawbacks
- Content only updates after a rebuild
- Large sites may have long build times
Best For
- Documentation
- Blogs
- Marketing pages
- Landing pages
The Problem with SSG
Imagine an e-commerce website with 500,000 product pages.
A single price update shouldn't require rebuilding the entire site.
This challenge led to Incremental Static Regeneration (ISR).
Incremental Static Regeneration (ISR)
ISR combines the speed of static pages with the freshness of server rendering.
When the cache expires:
- The current visitor still receives the cached page.
- A fresh version is generated in the background.
- Future visitors receive the updated page.
Advantages
- Fast like SSG
- Fresh content
- Lower server load
- No full rebuild required
Best For
- Product catalogs
- News sites
- CMS-driven websites
- Frequently updated content
Streaming Rendering
Even SSR has a limitation.
The server traditionally waits until all data is ready before sending the HTML.
What if the hero section is ready, but customer reviews are still loading?
Streaming Rendering solves this.
Instead of waiting for everything, the server streams HTML in chunks.
The browser starts rendering immediately while the remaining content arrives progressively.
Advantages
- Faster perceived performance
- Progressive rendering
- Better user experience
- Ideal for data-heavy pages
Best For
- Large product pages
- Dashboards
- Streaming content
- React Server Components
- Modern Next.js applications
Hydration
Receiving HTML isn't enough.
The page also needs to become interactive.
This process is called hydration.
HTML
→
Browser
→
DownloadJS
→
Hydration
→
InteractiveUI
Hydration attaches JavaScript event listeners to the pre-rendered HTML so buttons, forms, and interactions work as expected.
Side-by-Side Comparison
| Strategy | SEO | Initial Load | Freshness | Server Cost | Best For |
|---|---|---|---|---|---|
| CSR | ⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ | Dashboards |
| SSR | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | Dynamic content |
| SSG | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐ | Blogs |
| ISR | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ | E-commerce |
| Streaming | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | Modern React apps |
Visual Comparison
A quick way to think about these strategies is to compare the tradeoffs they make.
Which Strategy Should You Choose?
There isn't a universal winner.
Instead, choose based on the nature of each page.
| Page | Recommended Strategy |
|---|---|
| Marketing Landing Page | SSG |
| Documentation | SSG |
| Blog | SSG / ISR |
| Product Catalog | ISR |
| Product Details | ISR / SSR |
| Search Results | SSR |
| User Dashboard | CSR |
| Admin Panel | CSR |
| Personalized Homepage | Streaming SSR |
A modern application often uses multiple rendering strategies together.
Real-World Architecture
Large applications don't commit to a single rendering strategy.
For example:
Landing Page → SSG
Blog → ISR
Product Pages → ISR
Search → SSR
Checkout → SSR
Dashboard → CSR
Admin Portal → CSR
Product Reviews → Streaming SSR
Choosing the right rendering approach per route leads to better performance, SEO, and scalability.
Common Mistakes
❌ Using CSR for SEO-critical pages.
❌ Using SSR for pages that rarely change.
❌ Rebuilding an entire site for small content updates.
❌ Ignoring hydration costs when optimizing performance.
❌ Assuming one rendering strategy fits every page.
Key Takeaways
- CSR renders content in the browser and is ideal for highly interactive applications.
- SSR renders HTML on every request, improving SEO and first-page experience.
- SSG generates pages during the build process for maximum speed and scalability.
- ISR keeps static pages fresh by regenerating them in the background.
- Streaming Rendering progressively sends HTML, reducing perceived loading time.
- Modern frameworks like Next.js allow different pages to use different rendering strategies within the same application.
Conclusion
Frontend rendering has evolved significantly from browser-rendered SPAs to intelligent hybrid approaches that balance performance, SEO, scalability, and user experience. Rather than searching for the "best" rendering strategy, the key is understanding the strengths and tradeoffs of each approach and applying them where they make the most sense. The best frontend architectures are rarely built on a single rendering model. They're built by choosing the right strategy for each page and user experience.
The best frontend applications don't choose between CSR, SSR, SSG, ISR, or Streaming. They combine them strategically to deliver the right experience for every page.
