Choosing the Right Web Rendering Mode: From CSR to ISR Explained

Rendering Modes Overview

When starting a new web project or optimizing performance, developers often wonder whether to use CSR, SSR, or newer approaches. This guide explains how web rendering modes have evolved since the birth of the web, the design rationale behind each, their advantages and disadvantages, and suitable scenarios.

1. Rendering Mode Overview

CSR (Client‑Side Rendering) and SSR (Server‑Side Rendering) are the two most familiar modes for front‑end engineers. Rendering mode describes how a page’s content is generated—CSR fetches an empty HTML shell from a CDN and renders it in the browser with JavaScript, while SSR generates HTML on the server and sends it to the browser.

Rendering Timing – Some modes render entirely on the client, some on the server, and some combine both.

Rendering Steps – Some render in a single pass, others split the process into multiple stages.

The evolution can be divided into three stages:

Chaotic Beginnings – Early web (first 10 years) relied on pure static pages and traditional SSR templates.

Rapid Development – AJAX made CSR mainstream; Node.js popularized SSR; CSR, SSR, and SSG became the core trio.

Exploratory Innovation – New modes emerged to push performance and developer experience, often tightly coupled with frameworks.

2. Evolution of Rendering Modes

2.1 Chaotic Beginnings

2.1.1 Pure Static Rendering

In the early internet, pages were simple documents with very low bandwidth. The workflow was to write HTML and upload it directly; browsers fetched the full HTML and rendered it.

Timing: HTML rendered ahead of time on the build machine.

Steps: One‑time rendering.

Advantages

Very simple, no framework needed.

Best performance for small assets.

Resource‑saving via CDN caching.

SEO‑friendly.

Disadvantages

Unsuitable for frequently changing data.

Complex interactivity requires heavy custom JavaScript.

Typical Use Cases – Personal blogs, corporate homepages, school introductions.

2.1.2 Traditional SSR

Each request triggers the server to fetch dynamic data, inject it into a template, and return complete HTML.

Timing: Server‑side rendering.

Steps: One‑time rendering.

Advantages

Supports dynamic data.

Good performance when data fetching is fast.

SEO‑friendly.

Disadvantages

Requires backend templating; no front‑back separation.

Needs server deployment and maintenance.

Potentially high TTFB if data fetching is slow.

Typical Use Cases – Small teams with a backend but no dedicated front‑end engineers (generally not recommended today).

2.2 Rapid Development Stage

2.2.1 CSR

Traditional SSR’s lack of separation led to a hybrid approach where the server returns data inside a script tag and the browser renders the page with JavaScript. True CSR fetches data via AJAX after loading the empty HTML shell.

Timing: Client‑side rendering.

Steps: Can be single‑pass or incremental.

Advantages

True front‑back separation, low deployment cost.

Rich interactive experiences via SPA.

Disadvantages

Poor initial performance; long white‑screen time.

Not SEO‑friendly.

Typical Use Cases – Most modern Vue/React projects where SEO is not critical.

2.2.2 Hybrid/Isomorphic SSR

Node.js enables code to run both on the server and the client. The server renders HTML with data, the client hydrates the markup to make it interactive.

Timing: Server‑side rendering.

Steps: One‑time rendering.

Advantages

Good performance when server data fetch is fast.

Graceful fallback to CSR if the server fails.

Unified mental model for developers.

SEO‑friendly.

Disadvantages

Potentially high TTFB for slow data.

Additional Node.js server adds cost.

Requires careful memory‑leak handling.

Typical Use Cases – Vue or React projects that need strong performance and can afford a Node.js backend.

2.2.3 Streaming SSR

Instead of waiting for all data, the server streams HTML chunks as soon as they are ready, reducing white‑screen time.

Timing: Server‑side rendering.

Steps: One‑time rendering with chunked transfer.

Pros & Cons – Similar to isomorphic SSR but with faster perceived load; however, ordering dependencies can cause “bucket‑effect” delays.

2.2.4 SSG (Static Site Generation)

Build‑time rendering using dynamic data to generate static HTML files, which are then served via CDN.

Timing: Build‑time rendering.

Steps: One‑time rendering.

Advantages

Supports dynamic data at build time.

Low implementation cost, same codebase as CSR/SSR.

Excellent performance via CDN.

SEO‑friendly.

Disadvantages

Not ideal for frequently changing data.

First‑screen interactivity still depends on JS.

Large sites may have long build times.

Typical Use Cases – Blogs, documentation, marketing pages with mostly static content.

2.2.5 ISR (Incremental Static Regeneration)

Next.js introduced ISR to combine SSR and SSG: important pages are pre‑generated at build time, while less important pages are rendered on‑demand and cached.

Timing: Either build‑time (SSG) or request‑time (SSR).

Steps: One‑time rendering.

Advantages

Good performance for cached pages.

Low implementation cost with modern frameworks.

Reduces backend load.

SEO‑friendly.

Disadvantages

Reduced data freshness due to caching.

First‑screen interactivity still requires hydration.

Typical Use Cases – Sites mixing many static pages with occasional dynamic content.

2.3 Exploratory Innovation Stage

2.3.1 Edge Side Rendering (ESR)

Splits a page into a CDN‑cached static part and a server‑rendered dynamic part, delivering the static chunk first and then streaming the dynamic content from edge nodes.

Timing: Static part built ahead; dynamic part rendered on the edge.

Steps: Separate static and dynamic rendering.

Advantages

Excellent TTFB and first‑screen performance.

SEO‑friendly.

Disadvantages

Complex architecture and high infrastructure cost.

Depends on edge‑computing platforms.

2.3.2 Native Side Rendering (NSR)

Moves the SSR process to the native client by embedding a JavaScript engine that pre‑renders secondary pages, reducing server load.

Timing: Client‑side pre‑rendering.

Steps: One‑time rendering.

Advantages

Alleviates server load.

Pre‑loading can achieve near‑instant page opens.

Disadvantages

Requires non‑standard client capabilities.

Low hit‑rate pre‑loading wastes resources.

Data freshness concerns.

2.3.3 Selective Hydration

React 18 can wrap non‑critical components with Suspense, streaming placeholders first and hydrating components only when their data is ready, improving first‑screen metrics.

Timing: Server‑side rendering.

Steps: Component‑level independent rendering with chunked transfer.

Advantages

Better first‑screen performance.

Broad applicability across frameworks.

SEO‑friendly.

Disadvantage

Only supported by React 18 currently.

2.3.4 Island Architecture

Static parts are rendered on the server without JavaScript, while interactive “islands” load their own JS and hydrate independently.

Timing: Server‑side rendering.

Steps: One‑time rendering, component‑level hydration.

Advantages

Good performance when interactive components are few.

SEO‑friendly.

Disadvantage

Limited benefit for highly interactive pages.

2.3.5 React Server Components (RSC)

Splits components into server‑only and client‑capable parts; server components render without sending their code to the browser, reducing bundle size.

Timing: Server‑side rendering.

Steps: Component‑level independent rendering with chunked transfer.

Advantages

Excellent performance when combined with selective hydration.

Fits React full‑stack development.

SEO‑friendly.

Disadvantages

Still experimental; not stable.

React‑specific.

2.3.6 Qwik

Qwik postpones most JavaScript execution until the user interacts, using fine‑grained lazy loading and resumable rendering to minimize first‑screen cost.

Timing: Server‑side rendering + client‑side lazy rendering.

Steps: Server renders initial view; client renders non‑critical parts later.

Advantages

Significant first‑screen interactivity improvement.

Ultra‑fine‑grained chunking and lazy loading.

Can offload parsing to WebWorkers.

Disadvantages

Framework maturity and ecosystem are limited.

Potential latency if resources aren’t pre‑fetched.

3. Choosing a Rendering Mode

The continuous evolution of rendering modes is driven by the desire for lower cost, higher performance, and better user experience. Selecting the right mode requires balancing business needs, performance goals, resource and development costs, popularity, stability, and framework dependencies.

For a mobile‑focused, dynamic Vue 3 project with high performance and stability requirements, the author prefers a combination of streaming isomorphic SSR and ISR, supplemented with first‑screen splitting and lazy loading. For React stacks, a similar setup using Next.js with streaming SSR and selective hydration is recommended.

Common optimization ideas include:

Combine streaming SSR with selective hydration to output ready modules early and defer heavy components.

Use ISR for pages where real‑time data isn’t critical.

Apply island architecture or RSC to eliminate JS for read‑only components.

Leverage Qwik‑style fine‑grained lazy loading for non‑critical components.

4. Conclusion

The article introduced web rendering modes, traced their evolution, detailed each mode’s goals, implementation, pros, cons, and suitable scenarios, and finally offered guidance on selecting the most appropriate mode based on business requirements while sharing performance‑optimization insights derived from these patterns.

5. References

Rendering Patterns (https://www.patterns.dev/posts/rendering-patterns)

Rendering on the Web (https://web.dev/rendering-on-the-web/)

New Suspense SSR Architecture in React 18 (https://github.com/reactwg/react-18/discussions/37)

How React server components work: an in‑depth guide (https://www.plasmic.app/blog/how-react-server-components-work)

Do you REALLY need SSR? (https://www.youtube.com/watch?v=kUs-fH1k-aM)

Modern Front‑End Framework Rendering Modes (https://juejin.cn/post/7241027834490437669)

How Edge Rendering Improves Front‑End Performance (https://cloud.tencent.com/developer/article/2142531)