Rendering Strategies

Choosing between CSR, SSR, SSG, and hybrid rendering is not a binary decision—it’s about matching rendering strategy to content characteristics. Static content benefits from build-time rendering; dynamic, personalized content needs request-time rendering; interactive components need client-side JavaScript. Modern frameworks like Next.js 15, Astro 5, and Nuxt 3 enable mixing strategies within a single application, rendering each route—or even each component—with the optimal approach.

Rendering strategies span build-time, request-time, and client-time—modern applications mix these based on content characteristics.

Abstract

Rendering strategy selection reduces to three questions:

When is content known? Build-time (SSG) vs request-time (SSR) vs client-time (CSR)
How fresh must it be? Static (cache forever) vs stale-while-revalidate (ISR) vs always-fresh (SSR)
How interactive is it? None (static HTML) vs partial (islands) vs full (SPA hydration)

The 2025 consensus:

Server-first rendering dominates—React Server Components, Astro, and streaming SSR prioritize HTML delivery over JavaScript execution
Islands architecture wins for content sites—ship zero JavaScript by default, hydrate only interactive components
Streaming SSR replaces blocking SSR—send HTML progressively as data resolves, improving perceived performance
Bundle size determines INP—Interaction to Next Paint (the new Core Web Vital) correlates directly with JavaScript shipped

The framework landscape has converged: Next.js 15 defaults to Server Components, Astro 5 ships zero JavaScript, and Nuxt 3 enables per-route rendering modes. The choice is no longer “which framework” but “which rendering mode for this content.”

The Rendering Spectrum

Client-Side Rendering (CSR)

CSR (Client-Side Rendering) ships a minimal HTML shell and builds the DOM entirely in the browser via JavaScript. The classic SPA (Single-Page Application) approach.

How it works:

Server sends near-empty HTML with <script> tags
Browser downloads, parses, and executes JavaScript bundle
JavaScript fetches data and constructs DOM
User sees content only after JavaScript completes


4 collapsed lines
1
<!DOCTYPE html>
2
<html>
3
  <head>
4
    <title>App</title>
5
  </head>
6
  <body>
7
    <div id="root"></div>
4 collapsed lines
8
    <!-- User sees blank page until this executes -->
9
    <script src="/bundle.js"></script>
10
  </body>
11
</html>

Core Web Vitals impact:

Metric	Impact	Why
FCP	Poor	No content until JS executes
LCP	Poor	Largest element delayed by JS
INP	Poor	Large bundles block main thread
CLS	Variable	Depends on implementation

Design rationale: CSR simplifies deployment (static files only) and enables rich interactivity without server infrastructure. The trade-off is initial load performance—users wait for JavaScript before seeing content.

When CSR makes sense:

Internal dashboards where SEO is irrelevant
Highly interactive tools (Figma, Notion, Slack)
Behind authentication (crawlers can’t access anyway)
Apps where subsequent navigation speed matters more than initial load

When CSR is wrong:

Marketing sites, blogs, e-commerce (SEO-critical)
Content-heavy pages (slow LCP hurts engagement)
Mobile users on slow networks (large bundles timeout)

Server-Side Rendering (SSR)

SSR (Server-Side Rendering) executes rendering logic on the server per-request, returning complete HTML. The browser displays content immediately, then hydrates for interactivity.

How it works:

Browser requests page
Server executes component code, fetches data, renders HTML
Server sends complete HTML response
Browser paints content immediately (FCP)
Browser downloads JavaScript and hydrates


3 collapsed lines
1
// Next.js 15 App Router - Server Component by default
2
import { db } from '@/lib/db'
3

4
interface Product { id: string; name: string; price: number }
5

6
// This runs on the server every request
7
export default async function ProductPage({ params }: { params: { id: string } }) {
8
  const product = await db.products.findUnique({ where: { id: params.id } })
9

10
  return (
11
    <main>
12
      <h1>{product.name}</h1>
13
      <p>${product.price}</p>
14
    </main>
2 collapsed lines
15
  )
16
}

Core Web Vitals impact:

Metric	Impact	Why
FCP	Good	HTML arrives ready to paint
LCP	Good	Content visible before JS
INP	Good	Smaller bundles (RSC)
TTFB	Variable	Depends on server/data latency

Design rationale: SSR prioritizes content visibility. Users see meaningful content while JavaScript loads in the background. The trade-off is server load—every request requires compute.

TTFB considerations:

SSR’s TTFB depends on the slowest data fetch. If a page needs data from three APIs, TTFB = max(api1, api2, api3) + render time. Streaming SSR addresses this by sending HTML progressively.

When SSR makes sense:

SEO-critical dynamic content (search results, product pages)
Personalized content that can’t be pre-rendered
Pages with fast data sources
When server infrastructure is available

Static Site Generation (SSG)

SSG (Static Site Generation) renders pages at build time, producing static HTML files served from CDN. No server compute at request time.

How it works:

Build process fetches all data
Framework renders every page to HTML
HTML files deployed to CDN edge
Users receive pre-built HTML instantly
Optional: hydration for interactivity


2 collapsed lines
1
---
2
// Astro - runs at build time only
3
const posts = await fetch('https://api.example.com/posts').then(r => r.json())
4
---
5

6
<html>
7
  <body>
8
    <h1>Blog Posts</h1>
9
    <ul>
10
      {posts.map(post => (
11
        <li><a href={`/posts/${post.slug}`}>{post.title}</a></li>
12
      ))}
13
    </ul>
14
  </body>
15
</html>

Core Web Vitals impact:

Metric	Impact	Why
FCP	Excellent	CDN serves pre-built HTML
LCP	Excellent	No server processing
INP	Excellent	Minimal/no JavaScript
TTFB	Excellent	Edge-cached responses

Design rationale: SSG maximizes performance by eliminating request-time compute. Content is determined at build time and cached globally. The trade-off is staleness—updates require rebuilds.

Astro’s approach:

Astro exemplifies modern SSG. It renders pages at build time and ships zero JavaScript by default. Interactive components (“islands”) opt-in to client-side JavaScript.

“Astro is designed to be fast. Astro websites load 40% faster and use 90% less JavaScript than sites built with other popular web frameworks.” — Astro Documentation

When SSG makes sense:

Documentation sites
Marketing pages
Blogs with infrequent updates
E-commerce product catalogs (with ISR for freshness)

When SSG is wrong:

Highly personalized content
Real-time data (stock prices, live scores)
Sites with thousands of pages and frequent updates

Incremental Static Regeneration (ISR)

ISR combines static performance with dynamic freshness. Pages are pre-rendered but regenerate in the background after a configurable interval.

How it works (Next.js 15):

First request: serve pre-built static page
After revalidate period expires: serve stale, trigger background regeneration
Next request: serve freshly regenerated page
Repeat


3 collapsed lines
1
// Next.js 15 App Router - Time-based revalidation
2
import { db } from '@/lib/db'
3

4
// Regenerate this page every 60 seconds
5
export const revalidate = 60
6

7
export default async function ProductPage({ params }: { params: { id: string } }) {
8
  const product = await db.products.findUnique({ where: { id: params.id } })
9

10
  return (
11
    <main>
12
      <h1>{product.name}</h1>
13
      <p>${product.price}</p>
14
      <p>Last updated: {new Date().toISOString()}</p>
15
    </main>
16
  )
17
}

On-demand revalidation:

For immediate updates (CMS publish, inventory change), trigger revalidation explicitly:


2 collapsed lines
1
"use server"
2
import { revalidatePath, revalidateTag } from "next/cache"
3

4
// Revalidate specific path
5
export async function publishPost(slug: string) {
6
  await db.posts.publish(slug)
7
  revalidatePath(`/posts/${slug}`)
8
}
9

10
// Revalidate by cache tag
11
export async function updateInventory(productId: string) {
12
  await db.inventory.update(productId)
13
  revalidateTag("products")
14
}

Design rationale: ISR solves the staleness problem of SSG without SSR’s per-request compute. Most requests hit cache; regeneration happens asynchronously. The trade-off is complexity—cache invalidation requires explicit management.

When ISR makes sense:

E-commerce with frequent price/inventory changes
News sites with editorial workflow
Content sites with thousands of pages
Any SSG use case that needs freshness

Streaming and Progressive Rendering

Streaming SSR

Traditional SSR blocks until all data is ready, then sends the complete HTML. Streaming SSR sends HTML progressively as data resolves.

How renderToPipeableStream works (React 18+):


4 collapsed lines
1
import { renderToPipeableStream } from 'react-dom/server'
2
import { createServer } from 'http'
3

4
createServer((req, res) => {
5
  const { pipe } = renderToPipeableStream(<App />, {
6
    bootstrapScripts: ['/main.js'],
7
    onShellReady() {
8
      // Shell (layout, navigation) ready - start streaming
9
      res.setHeader('Content-Type', 'text/html')
10
      pipe(res)
11
    },
12
    onShellError(error) {
13
      // Error before any HTML sent - can redirect/show error page
14
      res.statusCode = 500
15
      res.end('Error')
16
    },
17
    onAllReady() {
18
      // All Suspense boundaries resolved - useful for crawlers
19
    },
2 collapsed lines
20
  })
21
}).listen(3000)

Progressive rendering with Suspense:


5 collapsed lines
1
import { Suspense } from "react"
2

3
async function SlowComponent() {
4
  const data = await fetch("https://slow-api.example.com/data")
5
  return <div>{data.json().content}</div>
6
}
7

8
export default function Page() {
9
  return (
10
    <html>
11
      <body>
12
        {/* Shell streams immediately */}
13
        <header>Site Header</header>
14
        <nav>Navigation</nav>
15

16
        {/* Content streams as ready */}
17
        <Suspense fallback={<p>Loading...</p>}>
18
          <SlowComponent />
19
        </Suspense>
20

21
        <footer>Site Footer</footer>
22
      </body>
23
    </html>
24
  )
1 collapsed line
25
}

What the user sees:

Instant: Header, navigation, footer, “Loading…” placeholder
When data ready: Placeholder replaced with actual content (no page refresh)

Design rationale: Streaming decouples TTFB from slowest data fetch. Users see the page structure immediately; content fills in progressively. The browser can start parsing and rendering before the response completes.

Shopify Hydrogen results:

Shopify’s Hydrogen framework (React Server Components + Streaming) achieves:

Sub-50ms TTFB on Oxygen CDN (V8 Isolates)
Progressive hydration reduces TTI
No client round-trips—data embedded in streaming HTML

Out-of-Order Streaming

Suspense boundaries can resolve in any order. The browser receives placeholder slots and fills them as data arrives:

1
<!-- Initial stream -->
2
<html>
3
  <body>
4
    <header>Header</header>
5
    <!--$?--><template id="B:0"></template>
6
    <p>Loading...</p>
7
    <!--/$-->
8
    <footer>Footer</footer>
9
  </body>
10
</html>
11

12
<!-- Later stream (injected at end of document) -->
13
<script>
14
  // React replaces placeholder with resolved content
15
  $RC("B:0", "<div>Actual content from slow API</div>")
16
</script>

Design rationale: Out-of-order streaming maximizes parallelism. Fast data sources render immediately; slow sources don’t block the page. The technique uses inline scripts to swap placeholders after they stream.

Hydration Deep Dive

Full Hydration Process

Hydration attaches React’s event handlers and state management to server-rendered HTML. The browser receives static HTML, then React “hydrates” it to make it interactive.

The hydration sequence:

Server renders HTML → complete DOM structure
Browser receives HTML → displays immediately (FCP)
Browser downloads JavaScript → React bundle loads
hydrateRoot called → React attaches to existing DOM
Event handlers attached → page becomes interactive


2 collapsed lines
1
import { hydrateRoot } from 'react-dom/client'
2
import App from './App'
3

4
// React expects DOM to match what it would render
5
const root = document.getElementById('root')
6
hydrateRoot(root, <App />)

Critical constraint: Server and client must produce identical HTML. React compares the server-rendered DOM against what it would render; mismatches cause errors and visual glitches.

Hydration Mismatches

Mismatches occur when server and client render different content. Common causes:

1. Browser-only APIs:

1
// ❌ Mismatch: window doesn't exist on server
2
function Component() {
3
  return <div>{window.innerWidth}px</div>
4
}
5

6
// ✅ Fixed: defer to client
7
function Component() {
8
  const [width, setWidth] = useState<number | null>(null)
9

10
  useEffect(() => {
11
    setWidth(window.innerWidth)
12
  }, [])
13

14
  return <div>{width ?? "Loading..."}px</div>
15
}

2. Date/time rendering:

1
// ❌ Mismatch: server and client have different times
2
function Component() {
3
  return <span>{new Date().toLocaleString()}</span>
4
}
5

6
// ✅ Fixed: render on client only
7
function Component() {
8
  const [time, setTime] = useState<string | null>(null)
9

10
  useEffect(() => {
11
    setTime(new Date().toLocaleString())
12
  }, [])
13

14
  return <span suppressHydrationWarning>{time ?? ""}</span>
15
}

3. Conditional rendering:

1
// ❌ Mismatch: typeof window differs
2
function Component() {
3
  if (typeof window !== "undefined") {
4
    return <ClientOnlyFeature />
5
  }
6
  return null
7
}
8

9
// ✅ Fixed: state-based detection
10
function Component() {
11
  const [mounted, setMounted] = useState(false)
12

13
  useEffect(() => {
14
    setMounted(true)
15
  }, [])
16

17
  if (!mounted) return null
18
  return <ClientOnlyFeature />
19
}

Debugging mismatches:

Check browser console for hydration warnings (React 18+ provides detailed messages)
Compare server HTML (view-source:) with client render
Search for typeof window, navigator, document in render paths
Check timezone-dependent formatting

React 18 Selective Hydration

React 18 enables selective hydration—components wrapped in Suspense can hydrate independently:


3 collapsed lines
1
import { Suspense } from "react"
2

3
function Page() {
4
  return (
5
    <div>
6
      <header>Always hydrates first</header>
7

8
      <Suspense fallback={<p>Loading sidebar...</p>}>
9
        <Sidebar /> {/* Hydrates when ready */}
10
      </Suspense>
11

12
      <Suspense fallback={<p>Loading content...</p>}>
13
        <MainContent /> {/* Hydrates independently */}
14
      </Suspense>
15
    </div>
16
  )
17
}

How it works:

React prioritizes hydrating components the user interacts with
Clicking a not-yet-hydrated component triggers priority hydration
Other Suspense boundaries continue hydrating in background

Design rationale: Selective hydration improves perceived interactivity. The header becomes interactive immediately; heavy components hydrate progressively without blocking the page.

Islands Architecture

The Islands Model

Islands architecture renders most of the page as static HTML and hydrates only interactive “islands.” Each island is independent—different frameworks can coexist.

Core concept:

1
┌─────────────────────────────────────────────┐
2
│  Static HTML (no JavaScript)                │
3
│  ┌─────────┐     ┌──────────────┐           │
4
│  │ Island  │     │   Island     │           │
5
│  │ (React) │     │   (Vue)      │           │
6
│  │ 3KB JS  │     │   5KB JS     │           │
7
│  └─────────┘     └──────────────┘           │
8
│                                             │
9
│  More static content...                     │
10
│                                             │
11
│  ┌────────────────────────────┐             │
12
│  │       Island (Svelte)      │             │
13
│  │          8KB JS            │             │
14
│  └────────────────────────────┘             │
15
└─────────────────────────────────────────────┘
16

17
Total JS: 16KB (vs 200KB+ for full hydration)

Astro Islands

Astro implements islands with the client:* directives:


5 collapsed lines
1
---
2
import Header from "./Header.astro" // Static, no JS
3
import Search from "./Search.tsx" // Interactive island
4
import Footer from "./Footer.astro" // Static, no JS
5
---
6

7
<html>
8
  <body>
9
    <Header />
10

11
    <!-- Hydrates on page load -->
12
    <Search client:load />
13

14
    <!-- Hydrates when visible in viewport -->
15
    <Newsletter client:visible />
16

17
    <!-- Hydrates on first interaction -->
18
    <Comments client:idle />
19

20
    <!-- Never hydrates (server-only) -->
21
    <Analytics />
22

23
    <Footer />
24
  </body>
25
</html>

Hydration directives:

Directive	When Hydrates	Use Case
`client:load`	Immediately	Above-fold interactivity
`client:idle`	Browser idle	Below-fold, non-critical
`client:visible`	In viewport	Lazy components
`client:media`	Media query matches	Responsive features
`client:only`	Client-only (no SSR)	Browser-only components

Design rationale: Islands invert the default. Instead of “hydrate everything, optimize later,” islands are “hydrate nothing, add JavaScript where needed.” This produces dramatically smaller bundles.

Fresh (Deno)

Fresh implements islands without a build step:


2 collapsed lines
1
// Route - server-rendered
2
import Counter from "../islands/Counter.tsx"
3

4
export default function Home() {
5
  return (
6
    <div>
7
      <h1>Welcome</h1>
8
      <p>This is static HTML</p>
9

10
      {/* Island - hydrates on client */}
11
      <Counter start={3} />
12
    </div>
13
  )
14
}
15

16
// islands/Counter.tsx - client-side JavaScript
17
import { useState } from "preact/hooks"
5 collapsed lines
18

19
export default function Counter({ start }: { start: number }) {
20
  const [count, setCount] = useState(start)
21
  return <button onClick={() => setCount((c) => c + 1)}>{count}</button>
22
}

Design decisions:

No build step—TypeScript compiled on-demand via Deno
Islands in islands/ directory automatically hydrated
Uses Preact (3KB) instead of React (40KB)
Zero JavaScript by default

Partial Hydration vs Islands

Partial hydration: Framework hydrates a subset of components, but all components come from the same framework. React’s selective hydration is partial hydration.

Islands: Each island is independent. Different frameworks can coexist. No shared runtime overhead between islands.

The distinction matters for bundle size. Partial hydration still loads React for the entire page; islands load only what each component needs.

React Server Components

RSC vs SSR

React Server Components (RSC) and Server-Side Rendering (SSR) are complementary, not alternatives.

Aspect	SSR	RSC
Runs on	Server (per-request)	Server (can be cached)
Output	HTML string	React element tree (serialized)
Client bundle	Full app code	Only Client Components
Hooks allowed	All	None (`useState`, `useEffect` forbidden)
Data fetching	`getServerSideProps` / fetch	Direct `async` functions
Interactivity	After hydration	Client Components only

How RSC works:

Server renders Server Components into serialized React tree
Tree includes references to Client Components (not their code)
Client receives serialized tree + Client Component bundles
Client renders tree, loading Client Components as needed


4 collapsed lines
1
// Server Component - NOT shipped to client
2
import { db } from "@/lib/db"
3
import { formatMarkdown } from "@/lib/markdown" // 50KB library stays on server
4
import LikeButton from "./LikeButton" // Client Component
5

6
async function BlogPost({ id }: { id: string }) {
7
  const post = await db.posts.findUnique({ where: { id } })
8
  const html = formatMarkdown(post.content) // Heavy library, zero client cost
9

10
  return (
11
    <article>
12
      <h1>{post.title}</h1>
13
      <div dangerouslySetInnerHTML={{ __html: html }} />
14

15
      {/* Client Component - this code ships to client */}
16
      <LikeButton postId={id} />
17
    </article>
18
  )
19
}
20

21
// Client Component - marked explicitly
7 collapsed lines
22
;("use client")
23
import { useState } from "react"
24

25
export default function LikeButton({ postId }: { postId: string }) {
26
  const [liked, setLiked] = useState(false)
27
  return <button onClick={() => setLiked(!liked)}>{liked ? "❤️" : "🤍"}</button>
28
}

Bundle size impact:

Traditional React: marked (50KB), sanitize-html (25KB), and every component ship to client.

RSC: Only LikeButton (and its dependencies) ship to client. Markdown processing happens on server.

Server Actions

RSC enables Server Actions—functions that execute on the server, called from the client:


2 collapsed lines
1
"use server"
2
import { db } from "@/lib/db"
3

4
export async function addComment(postId: string, content: string) {
5
  await db.comments.create({
6
    data: { postId, content, createdAt: new Date() },
7
  })
8
  // Revalidate the post page
9
  revalidatePath(`/posts/${postId}`)
10
}
11

12
// Client Component using Server Action
13
;("use client")
14
import { addComment } from "./actions"
15

16
function CommentForm({ postId }: { postId: string }) {
17
  return (
18
    <form action={addComment.bind(null, postId)}>
19
      <input name="content" />
4 collapsed lines
20
      <button type="submit">Post</button>
21
    </form>
22
  )
23
}

Design rationale: Server Actions eliminate the need for API routes in many cases. Form submissions call server functions directly, with automatic serialization and error handling.

RSC Constraints

Server Components cannot:

Use useState, useReducer, useEffect, or other client hooks
Access browser APIs (window, document)
Use event handlers (onClick, onChange)
Be rendered conditionally based on client state

These constraints enable the zero-bundle benefit. If a component needs interactivity, mark it 'use client'.

Resumability: Beyond Hydration

Qwik’s Approach

Qwik eliminates hydration entirely through “resumability.” Instead of replaying component logic on the client, Qwik serializes execution state and resumes exactly where the server left off.

Hydration vs Resumability:

Aspect	Hydration	Resumability
Client startup	Re-execute all components	Resume from serialized state
JavaScript loaded	Entire app (or chunks)	Only for triggered interactions
Time to Interactive	After hydration completes	Near-instant
Memory at load	Full React tree	Minimal

How Qwik works:

Server renders HTML with serialized state in attributes
Client loads minimal Qwik runtime (~1KB)
On interaction, Qwik lazy-loads only the relevant event handler
Component state resumes from serialized data


2 collapsed lines
1
import { component$, useSignal } from "@builder.io/qwik"
2

3
export const Counter = component$(() => {
4
  const count = useSignal(0)
5

6
  return <button onClick$={() => count.value++}>Count: {count.value}</button>
7
})
8

9
// Rendered HTML includes serialized state:
10
// <button on:click="q-abc123">Count: 0</button>
11
// On click, Qwik fetches only the click handler code

Design rationale: Hydration assumes the client must understand the component tree before interactivity. Resumability questions this assumption—why re-execute code that already ran on the server? By serializing execution state, Qwik achieves near-instant interactivity.

Trade-offs:

✅ Sub-second TTI on mobile
✅ Minimal initial JavaScript
❌ Different mental model from React/Vue
❌ Smaller ecosystem
❌ Serialization overhead for complex state

Framework Comparison

Next.js 15

Default behavior: Server Components (RSC) in App Router

Rendering modes:

Mode	Config	Use Case
Static	`export const dynamic = 'force-static'`	Build-time rendering
Dynamic	`export const dynamic = 'force-dynamic'`	Per-request rendering
ISR	`export const revalidate = 60`	Cached with background refresh
Streaming	Suspense boundaries	Progressive rendering

Partial Prerendering (PPR):

Next.js 15 introduces PPR—combining static shells with dynamic content:


3 collapsed lines
1
import { Suspense } from "react"
2

3
// next.config.ts: cacheComponents: true
4
export default function ProductPage({ params }) {
5
  return (
6
    <main>
7
      {/* Static shell - prerendered at build */}
8
      <Header />
9
      <ProductInfo id={params.id} />
10

11
      {/* Dynamic content - streams at request time */}
12
      <Suspense fallback={<PriceSkeleton />}>
13
        <LivePrice id={params.id} />
14
      </Suspense>
15

16
      <Footer />
17
    </main>
18
  )
19
}

Astro 5

Default behavior: Zero JavaScript, static output

Rendering modes:

1
export default defineConfig({
2
  output: "static", // Full SSG (default)
3
  // output: 'server',   // Full SSR
4
  // output: 'hybrid',   // Per-page control
5
})

Hybrid rendering:

1
---
2
// Force server rendering for this page
3
export const prerender = false
4
---
5

6
<html>
7
  <body>
8
    <UserDashboard />
9
  </body>
10
</html>

Strengths:

Fastest static sites (40% faster than React equivalents)
Framework-agnostic islands (React, Vue, Svelte, Solid)
Content-first architecture

Nuxt 3

Default behavior: Universal rendering (SSR + hydration)

Rendering modes per route:

1
export default defineNuxtConfig({
2
  routeRules: {
3
    "/": { prerender: true }, // Static
4
    "/blog/**": { isr: 60 }, // ISR
5
    "/admin/**": { ssr: false }, // Client-only
6
    "/api/**": { cors: true }, // API routes
7
  },
8
})

Strengths:

Vue 3 Composition API
Nitro server engine (edge-deployable)
Mature hybrid rendering

Decision Matrix

Factor	Next.js 15	Astro 5	Nuxt 3	Qwik
Default JS	RSC (minimal)	Zero	Full hydration	Zero (resumable)
Framework lock-in	React	None	Vue	Qwik
SSG	✅	✅ (primary)	✅	✅
SSR	✅	✅	✅	✅
Streaming	✅	✅	✅	✅
Islands	Via RSC	Native	Nuxt Islands	Native
Learning curve	Moderate	Low	Moderate	High
Ecosystem	Largest	Growing	Large (Vue)	Small

Real-World Implementations

Shopify Hydrogen

Challenge: E-commerce storefronts with dynamic pricing, inventory, personalization

Approach:

React Server Components for product pages
Streaming SSR for progressive rendering
Edge deployment on Oxygen (V8 Isolates)
Cache at CDN, invalidate on inventory changes

Results:

Sub-50ms TTFB from edge
Zero client-side data fetching for product info
Progressive hydration reduces TTI

Key insight: RSC eliminates the “client-side fetch waterfall” problem. Product data embeds directly in the streamed HTML.

Vercel Commerce

Challenge: Reference e-commerce implementation showcasing Next.js

Approach:

Next.js App Router with RSC
ISR for product catalog (revalidate on webhook)
Streaming for search results
Edge middleware for geolocation/personalization

Architecture:

1
Request → Edge Middleware (geo, A/B) → ISR Cache → Origin (if miss)
2
                                           ↓
3
                                    Streaming Response

The Guardian

Challenge: News site with millions of pages, real-time updates

Approach:

Server-rendered articles
Incremental regeneration for breaking news
Islands for interactive elements (comments, live blogs)
Aggressive caching at CDN

Key insight: News content is mostly static with pockets of interactivity. Islands architecture matches this perfectly—static article body, interactive comment section.

Performance Optimization

Core Web Vitals Alignment

As of 2025, Core Web Vitals are:

Metric	Target	Rendering Impact
LCP	< 2.5s	SSG/ISR > SSR > CSR
INP	< 200ms	Less JS = better INP
CLS	< 0.1	Streaming can help/hurt

INP optimization:

INP (Interaction to Next Paint) replaced TTI as the interactivity metric. It measures responsiveness to user interactions, not initial load. Large JavaScript bundles degrade INP because they compete for main thread time.

Strategies:

Ship less JavaScript — RSC, islands, code splitting
Defer non-critical JS — client:idle, client:visible
Avoid layout thrashing — batch DOM reads/writes
Use Web Workers — offload computation

Measuring Real-World Impact


3 collapsed lines
1
import { onLCP, onINP, onCLS } from "web-vitals"
2

3
function sendToAnalytics(metric) {
4
  // Send to your analytics endpoint
5
  fetch("/api/vitals", {
6
    method: "POST",
7
    body: JSON.stringify({
8
      name: metric.name,
9
      value: metric.value,
10
      id: metric.id,
11
    }),
12
  })
13
}
14

15
onLCP(sendToAnalytics)
16
onINP(sendToAnalytics)
17
onCLS(sendToAnalytics)

Strategy Selection by Use Case

Use Case	Primary Strategy	Fallback
Marketing site	SSG + Islands	ISR for dynamic sections
E-commerce catalog	ISR	On-demand revalidation
Dashboard	CSR	—
Blog	SSG	ISR for comments
News site	SSR + Streaming	ISR for archive
SaaS app	RSC + Streaming	CSR for complex widgets

Conclusion

Rendering strategy selection is no longer framework-constrained—modern tools support multiple modes. The decision reduces to content characteristics:

Static content → SSG (Astro, Next.js static export)
Dynamic but cacheable → ISR (Next.js, Nuxt)
Personalized/real-time → SSR + Streaming
Highly interactive → CSR or RSC with Client Components
Mixed → Islands (Astro) or RSC (Next.js)

The trend is server-first: render on the server, ship minimal JavaScript, hydrate selectively. React Server Components and islands architecture represent convergent evolution toward this model.

For new projects: start with the minimal JavaScript approach (Astro for content, Next.js RSC for apps) and add interactivity where needed. The performance benefits of shipping less JavaScript compound—better Core Web Vitals, lower hosting costs, broader device support.

Appendix

Prerequisites

HTML/CSS fundamentals and DOM understanding
JavaScript execution model (event loop, main thread)
React component model (or equivalent framework knowledge)
HTTP caching basics (Cache-Control, CDN concepts)

Terminology

Term	Definition
CSR	Client-Side Rendering—building DOM in browser via JavaScript
SSR	Server-Side Rendering—generating HTML on server per-request
SSG	Static Site Generation—pre-rendering HTML at build time
ISR	Incremental Static Regeneration—SSG with background refresh
Hydration	Attaching JavaScript interactivity to server-rendered HTML
Islands	Independent interactive components in otherwise static pages
RSC	React Server Components—components that run only on server
TTFB	Time to First Byte—server response latency
FCP	First Contentful Paint—when first content appears
LCP	Largest Contentful Paint—when main content is visible
INP	Interaction to Next Paint—responsiveness to user input
Resumability	Continuing server execution on client without replay

Summary

Match strategy to content: static → SSG, dynamic → SSR, personalized → CSR
Server-first wins: RSC and islands ship less JavaScript, improving INP
Streaming improves perceived performance: send HTML progressively, don’t block on slowest data
Hydration has costs: consider islands or resumability for content-heavy sites
ISR bridges static and dynamic: cache-first with background refresh
INP is the new TTI: JavaScript bundle size directly impacts interactivity metrics

References

React Server Components - React Documentation — Official RSC specification and patterns
renderToPipeableStream - React DOM Server — Streaming SSR API reference
hydrateRoot - React DOM Client — Hydration API and constraints
Next.js App Router Documentation — RSC, streaming, and rendering modes
Next.js ISR Documentation — Incremental regeneration patterns
Astro Documentation — Islands architecture and zero-JS approach
Astro: Why Astro? — Performance philosophy and benchmarks
Nuxt 3 Rendering Modes — Hybrid rendering configuration
Qwik Resumability — Alternative to hydration
Rendering on the Web - web.dev — Google’s rendering strategy guide
Shopify Hydrogen Best Practices — Production RSC patterns
Core Web Vitals - web.dev — LCP, INP, CLS definitions and targets

Read more