Choosing the right rendering strategy — CSR, SSR, SSG, ISR, streaming SSR, or React Server Components — is one of the highest-impact architectural decisions in frontend system design, affecting Time to First Byte, Time to Interactive, SEO, and infrastructure costs.
CSR has fast TTFB but slow First Contentful Paint (blank screen until JS runs); SSR has slower TTFB but fast FCP (full HTML sent) — hydration cost affects both TTI.
SSG pre-renders at build time for fastest serving (CDN static files); ISR adds background revalidation so content stays fresh without full rebuilds.
Progressive HTML delivery using Suspense boundaries — fast parts stream immediately, slow data shows fallbacks that are replaced inline when ready.
Server Components run only on the server and send zero JavaScript to the client — dramatically reducing bundle size while enabling direct database and API access.
Modern applications mix rendering strategies per route — SSG for static pages, ISR for semi-dynamic content, streaming SSR for personalized feeds, CSR for authenticated dashboards.
Rendering strategy determines when and where your HTML is generated. This single decision cascades into SEO performance, perceived load speed, infrastructure requirements, and developer experience. Modern frameworks like Next.js support hybrid approaches where different routes use different strategies.
The browser downloads a minimal HTML shell, a JavaScript bundle, and the JavaScript renders the entire page:
index.html → receives nearly empty HTML with <script> tagsPros: Simple deployment (static files on CDN), rich interactivity, no server needed, good for authenticated dashboards where SEO doesn't matter.
Cons: Slow initial load (blank screen until JS loads and executes), poor SEO (crawlers may not execute JavaScript), large JavaScript bundles, loading waterfall (HTML → JS → data → render).
TTFB: Fast (static HTML). FCP/LCP: Slow (waits for JS). TTI: Slow (same bundle for render + interactivity).
The server executes the application code and sends fully rendered HTML to the browser:
Pros: Fast First Contentful Paint (content visible before JS loads), good SEO (crawlers see full HTML), works without JavaScript for initial view.
Cons: Slower TTFB (server must render before responding), server infrastructure required, hydration cost (JS must download and execute to make page interactive), double rendering (server renders, then client re-renders to hydrate).
TTFB: Slower (server rendering). FCP: Fast (full HTML sent). TTI: Depends on JS bundle size.
Pages are rendered at build time and served as static HTML files:
Pros: Fastest TTFB (CDN-served static files), excellent SEO, no server runtime, highly cacheable, lowest infrastructure cost.
Cons: Requires rebuild for content changes, build time grows with page count, not suitable for user-specific or frequently changing content.
ISR combines SSG's speed with SSR's freshness. Pages are statically generated but can be revalidated after deployment:
Pros: Static performance with dynamic freshness, no full rebuilds needed, scales to millions of pages.
Cons: Users may see stale content for up to the revalidation period, only works with frameworks that support it (Next.js), more complex mental model.
Streaming SSR sends HTML progressively as it's generated, rather than waiting for the entire page:
<head> and page shell immediatelyPros: Faster TTFB (response starts immediately), progressive rendering (user sees content incrementally), Suspense integration, reduces blocking on slow data sources.
Cons: More complex server setup, browser must handle streaming HTML, debugging streaming issues is harder.
RSC is a new paradigm where components run only on the server and send rendered output (not JavaScript) to the client:
'use client'): Run in the browser, handle interactivity (state, effects, event handlers). These components are hydrated normally.Pros: Dramatically smaller client bundles (server-only code stays on server), direct database/API access without API endpoints, automatic code splitting, streaming built-in.
Cons: New mental model (server vs client boundary), can't use hooks or browser APIs in Server Components, requires framework support (Next.js App Router).
Edge rendering runs SSR at CDN edge locations (Cloudflare Workers, Vercel Edge Functions) close to the user:
Pros: Low latency SSR (edge is geographically close to users), no cold start for edge runtimes, combines SSR's SEO benefits with CDN's speed.
Cons: Limited runtime (no Node.js APIs, restricted to Web APIs), cold starts on less-popular edge locations, data source latency (edge is close to user but may be far from database).
| Criteria | Best Strategy | |----------|---------------| | Static content (blog, docs) | SSG | | SEO-critical + dynamic | SSR or ISR | | Authenticated dashboard | CSR | | E-commerce product pages | ISR or SSG with revalidation | | Social feed (personalized) | Streaming SSR + RSC | | Marketing landing page | SSG | | Real-time collaborative app | CSR with WebSockets |
Most modern applications use hybrid rendering — different routes use different strategies. A Next.js app might use SSG for the marketing site, ISR for product pages, streaming SSR for the feed, and CSR for the settings dashboard.
Rendering strategy is not one-size-fits-all — it's a per-route decision balancing TTFB, Time to Interactive, SEO, infrastructure cost, and content freshness. CSR is simplest but slowest to first paint. SSR gives fast first paint but needs a server. SSG is fastest but requires rebuilds. ISR adds freshness to SSG. Streaming SSR improves perceived performance with progressive rendering. RSC moves component code off the client entirely. Modern apps use hybrid approaches where each route picks the optimal strategy.
Fun Fact
Netflix found that switching their landing page from client-side rendering to server-side rendering reduced Time to Interactive by 50% — from 14 seconds on a mid-range mobile device to 7 seconds. The same JavaScript bundle still had to load, but users could see and read content while it loaded.