React Rendering Architecture: Fiber, SSR, and RSC

React’s rendering architecture has evolved from a synchronous stack-based reconciler to a sophisticated concurrent system built on Fiber’s virtual call stack. This article examines the Fiber reconciliation engine, lane-based priority scheduling, streaming Server-Side Rendering (SSR), and React Server Components (RSC)—now stable as of React 19 (December 2024). Understanding these internals is essential for making informed architectural decisions about rendering strategies, performance optimization, and infrastructure requirements.

Abstract

React’s rendering architecture rests on three interdependent pillars:

Mental model:

1. Fiber as virtual stack: Each component becomes a fiber node linked via child/sibling/return pointers. React can pause mid-tree, yield to the browser, and resume—impossible with the native call stack.

2. Two-phase reconciliation: The render phase builds a work-in-progress (WIP) tree and is interruptible (5ms time slices via MessageChannel). The commit phase applies DOM mutations synchronously—no interruption allowed.

3. Lanes replace expiration times: As of React 18, priority is a 31-bit bitmask. Each update gets a lane bit; the scheduler processes the highest-priority lane set first. User input lanes preempt transition lanes.

4. Rendering location is orthogonal to Fiber: CSR, SSR, and RSC all use Fiber for reconciliation. RSC differs by serializing the component tree into a streamable Flight protocol, sending only UI descriptions—never component code—to the client.

5. RSC is stable in React 19: Server Components ship zero JavaScript to the client, fetch data directly on the server, and integrate with Suspense for progressive streaming.

1. The Fiber Reconciliation Engine

1.1 From Stack to Fiber: The Paradigm Shift

React’s original reconciliation algorithm (pre-React 16) operated synchronously, bound to the JavaScript call stack. A state update would recursively traverse the entire component tree in one uninterruptible pass—blocking the main thread for the duration. Complex trees could cause noticeable jank.

React Fiber (React 16, September 2017) reimplemented reconciliation by replacing the native call stack with a controllable in-memory data structure: a tree of fiber nodes linked via child/sibling/return pointers. This virtual stack allows React’s scheduler to pause work, yield to the browser for user input or paint, and resume later.

Prior to React 16: The “stack reconciler” processed the entire tree synchronously. Once a render started, it had to complete before the browser could respond to input—causing jank on complex updates.

1.2 Anatomy of a Fiber Node

Each fiber node is a “virtual stack frame” holding metadata about a component and its rendering state:

2 collapsed lines
1
// Simplified fiber node structure (React 19)
2
// See ReactFiberLane.js and ReactFiber.js in react-reconciler
3
const fiberNode = {
4
  // Identity
5
  tag: FunctionComponent, // Component type (FunctionComponent, HostComponent, etc.)
6
  type: ComponentFunction, // Reference to component function/class
7
  key: "unique-key", // Stable identity for diffing
8

9
  // Tree pointers
10
  child: childFiber, // First child
11
  sibling: siblingFiber, // Next sibling
12
  return: parentFiber, // Parent (named "return" as in call stack)
13

14
  // Props/state
15
  pendingProps: newProps, // Props for this render
16
  memoizedProps: oldProps, // Props from previous render
17
  memoizedState: hookList, // Linked list of hooks (for function components)
18

19
  // Double buffering
20
  alternate: wipFiber, // Links current ↔ work-in-progress
21

22
  // Effects (React 18+: flags instead of effectTag)
23
  flags: Update | Placement, // Bitmask of side effects
24
  subtreeFlags: flags, // Aggregated child flags
25

4 collapsed lines
26
  // Scheduling (React 18+: lanes instead of expirationTime)
27
  lanes: SyncLane, // Lane bits for this fiber's updates
28
  childLanes: lanes, // Aggregated child lanes
29
}

Double buffering: React maintains two fiber trees—the current tree (displayed UI) and the work-in-progress (WIP) tree (being built). The alternate pointer links corresponding nodes. During reconciliation, React builds the WIP tree; at commit, a pointer swap makes WIP the new current. This technique—borrowed from video game rendering—ensures atomic UI updates without mutating the live interface.

1.3 Two-Phase Reconciliation

Fiber’s reconciliation operates in two distinct phases—a design that directly enables concurrent rendering:

Render Phase (Interruptible)

The render phase determines what changes to apply. It is asynchronous and interruptible, safe to pause mid-tree:

1. Work loop starts at the root fiber, traversing depth-first
2. performUnitOfWork calls beginWork() on each fiber, diffing against the previous state
3. WIP tree builds progressively as new fibers are created and linked
4. Time-slicing pauses after 5ms, yielding to the browser via MessageChannel

2 collapsed lines
1
// Conceptual work loop (actual implementation in ReactFiberWorkLoop.js)
2
// React yields after 5ms to maintain 60fps (16.67ms per frame)
3
function workLoopConcurrent() {
4
  while (workInProgress !== null && !shouldYield()) {
5
    performUnitOfWork(workInProgress)
6
  }
7
}
8

9
function shouldYield() {
10
  return performance.now() >= deadline // deadline = startTime + 5ms
11
}

Why MessageChannel, not requestIdleCallback? requestIdleCallback only fires during idle periods—which may never happen on busy pages. MessageChannel posts to the macrotask queue, guaranteeing React gets CPU time in the next event loop iteration. The 5ms slice leaves ~11ms per frame for browser layout, paint, and user input.

Commit Phase (Synchronous)

Once render completes, React enters the synchronous, non-interruptible commit phase:

1. Tree swap: WIP becomes current via pointer manipulation
2. DOM mutations: React applies changes from the flags bitmask on each fiber
3. Effects execution: useLayoutEffect runs synchronously; useEffect schedules asynchronously

This two-phase architecture is the foundation for Suspense, concurrent transitions, and RSC streaming.

1.4 Lane-Based Priority System

As of React 18, the scheduler uses lanes—a 31-bit bitmask where each bit represents a priority level. This replaced the previous expiration time model.

Why lanes? Expiration times forced React to process updates in order of expiration. Lanes allow batching updates of the same priority (multiple SyncLane updates batch into one render) and preemption (a SyncLane update can interrupt a TransitionLane render).

1
// User clicks button → SyncLane
2
// startTransition → TransitionLane (won't block input)
3
function handleClick() {
4
  setCount((c) => c + 1) // SyncLane - processed immediately
5
  startTransition(() => {
6
    setSearchResults(filterLargeList()) // TransitionLane - can be interrupted
7
  })
8
}

1.5 The Heuristic Diffing Algorithm

React implements an O(n) heuristic diffing algorithm based on two assumptions that hold for typical UI patterns:

1. Different element types produce different trees: Comparing <div> to <span> at the same position tears down the entire subtree and rebuilds—no attempt to diff children.

2. key provides stable identity: In lists, the key prop allows React to track insertions, deletions, and reordering. Without keys, React uses positional comparison—leading to performance degradation and state bugs when items reorder.

1.6 Hooks Integration with Fiber

Each function component’s fiber stores its hooks as a linked list in memoizedState. A cursor tracks the current hook position during render:

2 collapsed lines
1
// Simplified hook object (see ReactFiberHooks.js)
2
// Each hook in a component forms a linked list
3
const hook = {
4
  memoizedState: value, // Current value (state, ref, etc.)
5
  baseState: value, // Base for update calculations
6
  queue: updateQueue, // Pending updates
7
  next: nextHook, // Next hook in list
8
}

Why the Rules of Hooks exist: Hooks rely on call order, not names. React walks the linked list position-by-position. If you call useState conditionally, the cursor misaligns—React reads the wrong hook’s state. The lint rule react-hooks/rules-of-hooks enforces consistent ordering.

2. Client-Side Rendering Architectures

2.1 Pure Client-Side Rendering (CSR)

In CSR, the browser receives a minimal HTML shell; JavaScript constructs the entire DOM:

2 collapsed lines
1
// CSR initialization (React 18+)
2
import { createRoot } from "react-dom/client"
3

4
const root = createRoot(document.getElementById("root"))
5
root.render(<App />)

createRoot establishes the fiber tree foundation:

1. Creates FiberRootNode (top-level container for React’s internal state)
2. Creates HostRoot fiber (root fiber corresponding to the DOM container)
3. Links them bidirectionally

root.render() schedules an update on the HostRoot fiber, triggering two-phase reconciliation.

CSR trade-offs:

CSR suits internal dashboards and SPAs (Single-Page Applications) where SEO is irrelevant and users expect a loading state.

2.2 Server-Side Rendering with Hydration

SSR addresses CSR’s blank-screen problem by pre-rendering HTML on the server. Hydration is the process of attaching React to server-generated HTML—making it interactive.

The Hydration Process

Hydration is not a full re-render. React reconciles existing DOM with its virtual tree:

2 collapsed lines
1
// React 18+ hydration API
2
import { hydrateRoot } from "react-dom/client"
3

4
hydrateRoot(document.getElementById("root"), <App />)

Steps:

1. DOM traversal: React walks existing HTML alongside its virtual component tree
2. Event attachment: Handlers bind to existing DOM elements (no new elements created)
3. State initialization: Hooks initialize; effects schedule
4. Consistency check: React validates server/client output matches

Hydration Mismatches

Mismatches occur when server HTML differs from client render. Common causes:

React 18+ can recover from some mismatches by re-rendering the mismatched subtree, but recovery has costs: slower hydration and potential for event handlers attaching to wrong elements.

Selective Hydration

Suspense enables selective hydration—critical components hydrate immediately; others defer:

3 collapsed lines
1
// Selective hydration with Suspense (React 18+)
2
import { lazy, Suspense } from "react"
3
const HeavyComponent = lazy(() => import("./HeavyComponent"))
4

5
function App() {
6
  return (
7
    <div>
8
      <CriticalHeader />
9
      <Suspense fallback={<Skeleton />}>
10
        <HeavyComponent /> {/* Hydrates when visible or interacted with */}
11
      </Suspense>
12
    </div>
13
  )
14
}

Components inside Suspense boundaries hydrate on demand—when scrolled into view or when the user attempts interaction. This reduces Time to Interactive (TTI) for complex pages.

2.3 Streaming SSR with Suspense

React 18 introduced streaming SSR—progressive HTML delivery through Suspense boundaries:

3 collapsed lines
1
// Server streaming (React 18+)
2
import { renderToPipeableStream } from "react-dom/server"
3
import { App } from "./App"
4

5
const stream = renderToPipeableStream(<App />, {
6
  onShellReady() {
7
    // Shell ready → send immediately
8
    response.statusCode = 200
9
    response.setHeader("content-type", "text/html")
10
    stream.pipe(response)
11
  },
12
  onAllReady() {
13
    // All Suspense boundaries resolved → useful for crawlers
14
  },
15
  onError(error) {
16
    console.error(error)
17
    response.statusCode = 500
18
  },
19
})

How streaming works:

1. React renders until it hits a suspended component (e.g., awaiting data)
2. It sends the shell HTML immediately with a <template> placeholder
3. As Promises resolve, React streams <script> tags containing the resolved HTML
4. Client-side React swaps placeholders with streamed content—no full page reload

React 19 behavior change: In React 19, sibling components inside the same Suspense boundary no longer render in parallel—they render sequentially. This was a deliberate performance optimization that caused controversy. To fetch in parallel, either:

• Use separate Suspense boundaries for each sibling
• Trigger fetches outside the render phase (route loaders, RSC data fetching)

3. Server-Side Rendering Strategies

3.1 Traditional SSR (Page Router Pattern)

In Next.js Pages Router (and similar frameworks), server rendering follows a page-centric data fetching model:

2 collapsed lines
1
// Next.js Pages Router pattern
2
// Data fetching happens before component renders
3
export async function getServerSideProps({ req, res }) {
4
  const products = await fetchProducts()
5

6
  res.setHeader("Cache-Control", "public, s-maxage=10, stale-while-revalidate=59")
7

8
  return { props: { products } }
9
}
10

11
export default function ProductsPage({ products }) {
12
  return (
13
    <div>
6 collapsed lines
14
      {products.map((product) => (
15
        <ProductCard key={product.id} product={product} />
16
      ))}
17
    </div>
18
  )
19
}

This model couples data fetching to routing—server functions execute before rendering, props flow down the tree.

3.2 Static Site Generation (SSG)

SSG renders at build time, producing static HTML:

1
export async function getStaticProps() {
2
  const posts = await fetchPosts()
3
  return {
4
    props: { posts },
5
    revalidate: 3600, // ISR: regenerate every hour
6
  }
7
}

3.3 Incremental Static Regeneration (ISR)

ISR bridges SSG and SSR—static pages update after build:

1. First request serves stale static page
2. Background regeneration triggers if revalidate time exceeded
3. Next request serves updated content
4. On failure, stale content continues serving

Limitation: ISR is a Next.js-specific feature, not a React primitive. Other frameworks implement similar patterns differently.

4. React Server Components

4.1 The RSC Paradigm Shift

React Server Components (RSC), stable as of React 19 (December 2024), address a different problem than SSR. SSR optimizes initial page load; RSC eliminates client JavaScript for non-interactive components.

Key characteristics:

• Zero bundle impact: Server component code never reaches the client
• Direct backend access: Query databases, read files, call internal services
• Streaming-native: Integrates with Suspense for progressive rendering
• Composable: Server components can render client components (not vice versa)

4.2 The Dual Component Model

RSC introduces a clear boundary between component types via module-level directives.

Server Components (Default in React 19)

2 collapsed lines
1
// Server Component - runs only on server
2
// No directive needed - server is the default in RSC environments
3
export default async function ProductList() {
4
  // Direct database access - no API layer needed
5
  const products = await db.query("SELECT * FROM products WHERE active = true")
6

7
  return (
8
    <ul>
9
      {products.map((p) => (
10
        <li key={p.id}>{p.name}</li>
11
      ))}
12
    </ul>
13
  )
14
}

Server component constraints:

• No hooks that use client state (useState, useReducer, useEffect, useLayoutEffect)
• No browser APIs (window, document, event handlers)
• No client-only imports
• Can use: async/await, filesystem, database, environment variables

Client Components (Explicit Opt-in)

1
"use client" // Module-level directive - marks client boundary
2

3
import { useState } from "react"
4

5
export function AddToCart({ productId }) {
6
  const [pending, setPending] = useState(false)
7

8
  return (
9
    <button onClick={() => addToCart(productId)} disabled={pending}>
10
      Add to Cart
11
    </button>
12
  )
13
}

"use client" semantics: This is a module boundary, not a component boundary. All imports from this module (and their transitive imports) become part of the client bundle. Place the directive at the top of the file, before imports.

4.3 The Flight Protocol (RSC Wire Format)

RSC serializes the component tree into a streamable wire format called Flight. Unlike JSON, Flight supports:

• Streaming (chunks arrive progressively)
• Promise references (resolved out-of-order)
• Module references (for client component loading)

Payload Structure

1
0:["$","div",null,{"children":["$","h1",null,{"children":"Store"}]}]
2
1:["$","$L2",null,{"productId":123}]
3
2:I["./AddToCart.js","AddToCart"]
4
3:["$","ul",null,{"children":"$@4"}]
5
4:["$","li",null,{"children":"Product A"}]

Out-of-Order Resolution

Flight enables streaming with out-of-order resolution:

1. Server sends shell immediately: ["$","div",null,{"children":"$@1"}]
2. $@1 is a promise placeholder—client renders fallback
3. When data resolves, server streams: 1:["$","ul",null,{"children":[...]}]
4. Client swaps placeholder with resolved content

This is how RSC achieves progressive rendering without multiple HTTP requests.

4.4 RSC Integration with Suspense

Suspense boundaries define streaming units. Each boundary can resolve independently:

2 collapsed lines
1
// RSC page with Suspense boundaries
2
import { Suspense } from "react"
3

4
export default async function Page() {
5
  return (
6
    <div>
7
      <Suspense fallback={<HeaderSkeleton />}>
8
        <AsyncHeader />
9
      </Suspense>
10
      <Suspense fallback={<ProductSkeleton />}>
11
        <AsyncProductList />
12
      </Suspense>
13
      <AddToCartSidebar /> {/* Client component */}
14
    </div>
15
  )
16
}
17

18
async function AsyncHeader() {
19
  const user = await fetchUserData() // Suspends until resolved
20
  return <Header user={user} />
21
}

Parallel vs. sequential fetching: Each Suspense boundary fetches independently. If AsyncHeader and AsyncProductList are in separate boundaries, they fetch in parallel. If in the same boundary (React 19), they fetch sequentially.

4.5 React 19 RSC Enhancements

React 19 stabilized RSC and added:

1
"use server"
2

3
export async function addToCart(productId) {
4
  await db.cart.add(productId)
5
  revalidatePath("/cart")
6
}

The "use server" directive marks a function as a Server Action—callable from client components, executed on the server.

4.6 RSC Performance Implications

5. React Compiler

React 19 introduced the React Compiler (formerly “React Forget”)—a build-time optimization tool that automatically memoizes components and values.

What It Does

The compiler analyzes your code and inserts optimizations:

• Skips re-renders when props/state haven’t changed
• Memoizes expensive calculations
• Stabilizes function references

What it replaces: Manual useMemo, useCallback, and React.memo. The compiler does this more efficiently through inlining rather than runtime checks.

1
// Before: Manual memoization
2
const filteredList = useMemo(() => items.filter(predicate), [items, predicate])
3
const handleClick = useCallback(() => doSomething(id), [id])
4

5
// After: Compiler handles it automatically
6
const filteredList = items.filter(predicate) // Compiler memoizes
7
const handleClick = () => doSomething(id) // Compiler stabilizes

Limitations

The compiler optimizes how components render, not whether they render. Architectural decisions remain your responsibility:

• Virtualization for long lists
• Code splitting
• Render strategy selection (CSR/SSR/RSC)

6. Architectural Synthesis and Trade-offs

6.1 The Dependency Chain

React’s architecture forms a dependency chain:

1
Fiber → Lanes → Suspense → Concurrent Features → RSC Streaming

1. Fiber enables interruptible rendering
2. Lanes provide priority-based scheduling
3. Suspense provides the async primitive
4. Concurrent features (transitions, deferred values) build on Suspense
5. RSC streaming leverages all of the above

6.2 Decision Framework

RSC + SSR when:

• Optimal performance across all metrics required
• Team can manage server infrastructure
• Mix of static and interactive content

Traditional SSR when:

• Existing SSR infrastructure
• Page-level data fetching sufficient
• Full hydration acceptable

SSG when:

• Content changes infrequently
• Maximum performance required
• CDN-first architecture

CSR when:

• Internal tool / dashboard
• SEO irrelevant
• Simplest deployment

Conclusion

React’s architecture has evolved from a synchronous stack reconciler to a sophisticated concurrent system built on Fiber’s virtual call stack. The lane-based priority system enables responsive UIs under load; Suspense provides the async primitive; RSC—now stable in React 19—eliminates unnecessary client JavaScript while enabling direct server-side data access.

Understanding these internals informs architectural decisions: when to use transitions, how Suspense boundaries affect streaming, why hydration mismatches occur, and when RSC provides meaningful bundle savings. The React Compiler further reduces the cognitive overhead of manual memoization, letting developers focus on architecture rather than micro-optimizations.

The dependency chain—Fiber → Lanes → Suspense → RSC—means each layer builds on the previous. Breaking changes at any level ripple upward. As React continues evolving, these foundational patterns will shape both the framework’s future and the broader landscape of UI frameworks.

Appendix

Prerequisites

• JavaScript async/await and Promises
• React component model (props, state, hooks)
• HTTP request/response cycle
• Basic understanding of browser rendering (layout, paint, composite)

Summary

• Fiber replaces the native call stack with a virtual stack of linked fiber nodes, enabling interruptible rendering
• Lanes (31-bit bitmask) replaced expiration times in React 18; higher-priority lanes preempt lower ones
• Two-phase reconciliation: interruptible render phase (5ms slices via MessageChannel), synchronous commit phase
• Streaming SSR sends HTML progressively through Suspense boundaries; React 19 changed sibling rendering to sequential
• RSC (stable in React 19) serializes UI via Flight protocol; server components ship zero client JavaScript
• React Compiler automates memoization at build time

References

Official Documentation

• React 19 Release Blog - Official release notes (December 2024)
• React Server Components Reference - Official RSC documentation
• Suspense Reference - Official Suspense API docs
• hydrateRoot API - Hydration documentation
• React Compiler Introduction - Official compiler docs

Architecture & Design

• React Fiber Architecture - Andrew Clark’s Fiber design explanation
• React Server Components RFC - Original RFC

Implementation Details

• React GitHub Repository - Source code (ReactFiberWorkLoop.js, ReactFiberLane.js)
• Scheduling in React 16.x - MessageChannel scheduler analysis
• React Lanes Guide - Lane system deep dive

Ecosystem

• Next.js App Router - RSC implementation in Next.js
• Rendering on the Web - Google’s rendering strategy comparison
• React 19 Suspense Analysis - TkDodo on Suspense behavior changes