React Server Components vs Client Components

Why React Grew Beyond the Browser

React began as a purely client-side rendering library. The browser downloaded a JavaScript bundle, React mounted the component tree in memory, and the DOM was populated. This model worked well for small interactive apps, but as applications scaled, three compounding problems emerged.

Bundle bloat. Every component, utility, and third-party dependency you import is shipped to the browser. A product listing page that displays data from a database ends up including the database client, date formatters, markdown parsers, and every other library the page touches: none of which the user needs to run in their browser.

Waterfall data fetching. Client-side data fetching is inherently sequential. A component renders, discovers it needs data, fires a request, waits, then renders children that discover they also need data. Each round trip adds perceptible latency at a time when the user is already waiting for the page to load.

Hydration overhead. Server-side rendering (SSR) solved the blank-page problem by sending pre-rendered HTML on the first load. But to make the page interactive, the browser had to re-execute all component JavaScript to attach event listeners: a process called hydration. For large pages, this added hundreds of milliseconds before the UI was responsive.

The Evolution of React Rendering

Understanding RSC requires tracing the progression of React rendering models:

• CSR (2013–2018): Everything in the browser. Fast dev experience, poor initial load performance, bad SEO without extra tooling.
• SSR + Hydration (2018–2022): Server renders HTML for the first load; browser hydrates the page. Better initial load, but hydration cost and waterfall fetching remained.
• RSC (2023–present): Components run on either the server or the client based on their declared capabilities. Server components produce HTML and never hydrate. Client components hydrate only the interactive parts.

RSC was introduced as an experimental feature in React 18 and reached mainstream production readiness with React 19 and Next.js 13+ (App Router). As of 2026 it is the default rendering model in Next.js and the direction all major React frameworks are moving toward.

Server vs Client: A Strict Division of Labour

The most important shift with RSC is not a new API: it is a new default. In the traditional model, every React component ran in the browser. In the RSC model, every component runs on the server unless you explicitly opt into browser execution with "use client".

Think of the server and client as two separate execution environments with clearly defined responsibilities:

The Boundary is Explicit

The division between server and client is marked with the "use client"directive at the top of a file. Everything in that file and everything it imports transitively becomes "client territory." The server/client boundary is a one-way gate: server components can render client components, but client components cannot import server components.

What Are Server Components

A Server Component is a React component that executes on the server: either at request time (dynamic rendering) or at build time (static rendering). It never runs in the browser. No component code is included in the JavaScript bundle shipped to the client.

What They Can Do

• Be declared as async functions: await works directly
• Call databases, ORMs, and file systems without any client exposure
• Read environment variables and secrets safely
• Import large backend-only libraries without bundle impact
• Render other server components and client components
• Pass serializable data as props to child client components

What They Cannot Do

• Use useState, useReducer, useEffect, useCallback, useMemo, or useRef
• Use useContext for client-side context providers
• Use browser APIs: window, document, localStorage, navigator
• Use event handlers: onClick, onChange, onSubmit, etc.
• Use class components

// No "use client" directive: this is a server component by default
// This component never runs in the browser.

import { db } from "@/lib/db";
import { AddToCartButton } from "./AddToCartButton"; // client component

export default async function ProductsPage() {
  // Direct database access: no fetch(), no useEffect, no loading state
  const products = await db.product.findMany({
    where: { published: true },
    orderBy: { createdAt: "desc" },
    take: 20,
  });

  return (
    <main>
      <h1>Products</h1>
      <ul>
        {products.map((p) => (
          <li key={p.id}>
            <h2>{p.name}</h2>
            <p>{p.price}</p>
            {/* Client component island inside server-rendered list */}
            <AddToCartButton productId={p.id} />
          </li>
        ))}
      </ul>
    </main>
  );
}

// Layouts in Next.js App Router are server components by default.
// They can fetch data, check auth, and pass it to children.

import { auth } from "@/lib/auth";
import { redirect } from "next/navigation";
import { Sidebar } from "@/components/Sidebar"; // server component

export default async function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const session = await auth();

  if (!session) {
    redirect("/login");
  }

  return (
    <div className="dashboard-shell">
      <Sidebar user={session.user} />
      <main>{children}</main>
    </div>
  );
}

What Are Client Components

Client Components are React components that run in the browser. They are marked with "use client" at the top of the file. Despite the name, they are also pre-rendered as HTML on the server (standard SSR) and then hydrated in the browser: the JavaScript is re-executed to attach event listeners and activate interactivity.

What They Can Do

• Use all React hooks: useState, useEffect, useRef, useCallback, custom hooks
• Attach event handlers: onClick, onChange, onSubmit, etc.
• Access browser APIs: window, document, localStorage, navigator
• Use useContext with client-side context providers
• Integrate third-party interactive libraries
• Use React 19 hooks: useActionState, useFormStatus, useOptimistic

"use client";

import { useState, useTransition } from "react";
import { useRouter } from "next/navigation";

export function SearchBox({ placeholder }: { placeholder: string }) {
  const [query, setQuery] = useState("");
  const [isPending, startTransition] = useTransition();
  const router = useRouter();

  const handleSearch = () => {
    startTransition(() => {
      router.push(`/search?q=${encodeURIComponent(query)}`);
    });
  };

  return (
    <div>
      <input
        value={query}
        onChange={(e) => setQuery(e.target.value)}
        onKeyDown={(e) => e.key === "Enter" && handleSearch()}
        placeholder={placeholder}
      />
      <button onClick={handleSearch} disabled={isPending}>
        {isPending ? "Searching..." : "Search"}
      </button>
    </div>
  );
}

The "use client" Boundary

When you add "use client" to a file, it marks the boundary. That file and all modules it imports become part of the client bundle. This means: if a client component imports a 50KB library, that library is in the bundle. Keep client components small and push the boundary as deep in the tree as possible.

Server vs Client: The Detailed Comparison

Defaulting to the Server

The principle is simple: start with a server component and only add "use client" when you have a specific reason to. Most components in a well-designed RSC app are server components.

Ideal use cases

• Data-fetching pages: product listings, blog posts, dashboards with read-only metrics, user profiles: anything that reads from a database or API and displays results without user interaction.
• Layouts and shells: navigation menus that read auth state, sidebars that fetch user permissions, page wrappers. Layouts in Next.js are server components by default and should stay that way.
• SEO-critical pages: landing pages, product pages, and blog articles, where HTML must be fully rendered before delivery.
• Content-heavy apps: documentation sites, CMS-driven pages, marketing sites: where interaction is minimal but content is rich.
• Secure data access: any component that reads user-specific data behind an auth check. The check runs on the server; no credentials reach the client.

Opting Into the Browser

Use a client component when your component needs to respond to user interaction or access browser-only capabilities. These are the non-negotiable requirements for "use client".

Requires "use client"

• Interactive forms: controlled inputs, field-level validation, submission state
• Modals and dialogs: open/close state, focus management
• Dropdown menus and autocomplete: keypress/click handlers, focus tracking
• Drag and drop: pointer events, position tracking
• Real-time UI: WebSocket subscriptions, Server-Sent Events, live counters
• Browser API access: geolocation, clipboard, localStorage, canvas, Web Audio
• Third-party interactive libraries: chart libraries with hover/zoom, rich text editors, date pickers, map components
• Optimistic UI: useOptimistic for immediate feedback before server confirmation

Server and Client Working Together

In practice, most pages are a mix. Understanding the rules for composition is critical: get them wrong and you will either ship too much JavaScript to the client or hit runtime errors.

Rule 1: Server can render Client

A server component can import and render a client component. This is the most common pattern: the server handles data and structure, the client handles the interactive parts.

// app/products/[id]/page.tsx: Server Component
import { db } from "@/lib/db";
import { AddToCartButton } from "@/components/AddToCartButton"; // "use client"
import { ReviewList } from "@/components/ReviewList"; // server component

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

  return (
    <article>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <AddToCartButton productId={product.id} price={product.price} /> {/* ✓ */}
      <ReviewList productId={product.id} /> {/* server component ✓ */}
    </article>
  );
}

Rule 2: Client cannot import Server

A client component cannot import a server component. If it does, the imported module is treated as a client component: losing all server-only capabilities and potentially exposing server-only code to the client.

"use client";

// ✗ This will not work as intended.
// ServerWidget will be treated as a client component.
// If it accesses DB directly, that code will break in the browser.
import { ServerWidget } from "./ServerWidget";

export function ClientShell() {
  return <ServerWidget />;
}

Rule 3: Pass Server Components as Children

You canpass a server component's rendered output to a client component via the children prop. This works because <ServerContent /> is rendered by the server before being passed to the client component. The client component receives finished HTML/React elements, not the server function.

// app/page.tsx: Server Component
import { ClientShell } from "@/components/ClientShell"; // "use client"
import { ServerContent } from "@/components/ServerContent"; // server component

export default function Page() {
  return (
    // ClientShell wraps ServerContent: valid!
    // ClientShell receives the rendered output, not the server function.
    <ClientShell>
      <ServerContent />
    </ClientShell>
  );
}

Prop Serialization Constraints

Props passed from server components to client components must be serializable. React serializes these props to transmit them from the server to the client.

• Allowed: strings, numbers, booleans, null, arrays, plain objects, Date (serialized to ISO string)
• Not allowed: functions (except event handlers passed within client components), class instances, Map, Set, Symbol, undefined in objects

How Data Moves Through RSC Architecture

RSC introduces a specific rendering and data flow. Understanding it helps explain why the performance characteristics are so different from traditional SSR.

1. Request arrives: a route is accessed (navigation, reload, or initial load).
2. Server executes the component tree: Next.js walks the component tree starting from the root layout. Server components run their async operations, fetch data, and render.
3. RSC payload is generated: React serializes the rendered tree into the RSC payload: a compact representation of the component tree that includes rendered HTML and instructions for client component hydration boundaries.
4. Streaming begins: with React Suspense and Next.js streaming, parts of the tree that are ready stream to the browser immediately. Sections wrapped in <Suspense> send their fallback first, then the real content when the async operation resolves.
5. HTML arrives and renders progressively: the browser renders chunks as they arrive. The page becomes visually complete before all data is done loading.
6. Client components hydrate: React hydrates only the client component boundaries, attaching event listeners and activating interactivity. Server-rendered parts are not re-executed.

import { Suspense } from "react";
import { DashboardMetrics } from "@/components/DashboardMetrics"; // async server component
import { MetricsSkeleton } from "@/components/MetricsSkeleton";

export default function DashboardPage() {
  return (
    <main>
      <h1>Dashboard</h1>

      {/* This renders immediately */}
      <QuickStats /> {/* fast server component */}

      {/* This streams in when the slow query resolves */}
      <Suspense fallback={<MetricsSkeleton />}>
        <DashboardMetrics /> {/* slow server component: streams */}
      </Suspense>
    </main>
  );
}

The Performance Model

RSC delivers performance improvements across several dimensions. These are not marginal gains: for data-heavy applications, the differences are measurable in real user metrics.

Zero JS for Server Components

A product page that was 80KB of React component code becomes 0KB of component JS for the parts rendered on the server. Only client component code ships. In practice, this can reduce JS bundle size by 40–70% for content-heavy applications.

Reduced Hydration Cost

Hydration was one of SSR's biggest costs: the browser had to re-execute all component code to make the page interactive. With RSC, only client components hydrate. A page that is 80% server-rendered only needs to hydrate 20% of the tree, directly reducing Time to Interactive (TTI).

No Client-Side Data Waterfalls

Server components fetch data before the HTML is sent. The client never sees a loading flash for initial page data. Multiple parallel async server components resolve concurrently on the server before a single byte of HTML is sent.

Streaming Improves Perceived Performance

Streaming with Suspense means fast parts of the page arrive and render while slower parts are still loading. Users see a progressively-completing page rather than a blank screen followed by a complete page.

Next.js Caching Layers

• Request Memoization: fetch calls with the same URL/options are deduplicated within a single render pass
• Data Cache: fetch results persist across requests; controlled via cache: "force-cache" or next.revalidate
• Full Route Cache: statically-rendered routes are cached as HTML+RSC payload at build time
• Router Cache: client-side cache of RSC payloads for previously-visited routes, enabling instant back/forward navigation

RSC in the Next.js App Router

Next.js 13+ with the App Router is the primary production environment for RSC. The App Router is built entirely around the RSC model: every file in the app/ directory is a server component by default.

File Conventions

Rendering Modes

• Static (default): rendered at build time if no dynamic functions are used (cookies(), headers(), searchParams). Result is cached as HTML.
• Dynamic: rendered on every request when dynamic functions are called, or when export const dynamic = "force-dynamic" is set.
• Incremental Static Regeneration (ISR): static rendering with time-based or on-demand revalidation via next.revalidate orrevalidatePath() / revalidateTag().

Mutations Without API Routes

Server Actions are async functions marked with "use server"that run on the server but can be called from client components. They complete the RSC architecture by handling writes the same way server components handle reads: server-side, with no API route required.

// app/posts/new/page.tsx
import { redirect } from "next/navigation";
import { revalidatePath } from "next/cache";
import { db } from "@/lib/db";
import { auth } from "@/lib/auth";

export default function NewPostPage() {
  async function createPost(formData: FormData) {
    "use server"; // This function runs on the server

    const session = await auth();
    if (!session) throw new Error("Unauthorized");

    const title = formData.get("title") as string;
    const body = formData.get("body") as string;

    await db.post.create({
      data: { title, body, authorId: session.user.id },
    });

    revalidatePath("/posts"); // Invalidate cached post list
    redirect("/posts");
  }

  return (
    <form action={createPost}>
      <input name="title" placeholder="Post title" required />
      <textarea name="body" placeholder="Content..." required />
      <button type="submit">Publish</button>
    </form>
  );
}

"use client";

import { useActionState } from "react";
import { updateProfile } from "@/app/actions/profile"; // "use server" action

export function ProfileForm({ user }: { user: { name: string; bio: string } }) {
  const [state, action, isPending] = useActionState(updateProfile, null);

  return (
    <form action={action}>
      <input name="name" defaultValue={user.name} />
      <textarea name="bio" defaultValue={user.bio} />
      {state?.error && <p className="error">{state.error}</p>}
      <button type="submit" disabled={isPending}>
        {isPending ? "Saving..." : "Save Changes"}
      </button>
    </form>
  );
}

Security Model

• Server Actions are exposed as POST endpoints automatically by Next.js
• Next.js validates the request origin to prevent CSRF by default
• You are still responsible for input validation (use Zod or similar) and authorization checks inside the action
• Never trust form data: validate everything server-side

Server Actions vs REST API Routes

Common Mistakes to Avoid

1. Adding "use client" to everything

This turns your Next.js app into a client-side SPA with none of the RSC benefits. A common sign: "use client" appears in app/layout.tsx or at the top of most page files. The result is a large JS bundle, slow initial loads, and no server-side data fetching.

2. Fetching data in client components unnecessarily

If data does not change in response to user actions, fetch it in a server component. Reaching for useEffect + fetch when an async server component await would work causes an extra round trip, a loading flash, and adds client JS.

"use client";
// ✗ Don't do this for data that doesn't need to be dynamic

import { useEffect, useState } from "react";

export function ProductList() {
  const [products, setProducts] = useState([]);

  useEffect(() => {
    fetch("/api/products").then(r => r.json()).then(setProducts);
  }, []);

  return <ul>{products.map(p => <li key={p.id}>{p.name}</li>)}</ul>;
}

// ✓ No "use client", no useEffect, no loading state
export default async function ProductList() {
  const products = await db.product.findMany();
  return <ul>{products.map(p => <li key={p.id}>{p.name}</li>)}</ul>;
}

3. Breaking prop serialization

Passing non-serializable values (functions, class instances, Map, Set) as props from a server component to a client component will cause a runtime error. Keep props simple and serializable.

4. Importing server-only code into client components

If a file accesses a database or reads environment secrets and a client component imports it, those imports could be inadvertently bundled for the client: exposing secrets or crashing in the browser. Use the server-only package to guard critical modules:

import "server-only"; // Throws a build-time error if imported by a client component

import { PrismaClient } from "@prisma/client";
export const db = new PrismaClient();

5. Giant client context providers at the root

Wrapping the entire app in a single client context provider (e.g. <AppProvider> with "use client") that passes server-fetched data down the tree defeats the purpose. Fetch data at the server component level and pass it as props where it's needed, or use small, targeted context providers only where they add value.

Real-World Composition Patterns

Pattern: Server-First

The default and recommended pattern. Start every component as a server component. Add "use client" only when you reach a specific requirement that demands it. The result: the server tree is large and rich; client islands are small and focused.

Pattern: Leaf-Level Client Components

Push "use client" as far down the component tree as possible. Instead of making a whole card component client-side because it has one interactive button, extract just the button:

// ProductCard.tsx: Server Component (the structure)
import { AddToCartButton } from "./AddToCartButton"; // only the button is "use client"

export async function ProductCard({ id }: { id: string }) {
  const product = await db.product.findUnique({ where: { id } });
  return (
    <div>
      <img src={product.imageUrl} alt={product.name} />
      <h2>{product.name}</h2>
      <p>{product.price}</p>
      <AddToCartButton productId={id} /> {/* isolated client island */}
    </div>
  );
}

App Patterns by Type

Full Feature Comparison

How to Choose Every Time

Apply this decision framework at the component level. When in doubt, start with a server component and only move to client if a rule requires it.

Hybrid Decision Matrix

Production Patterns in 2026

Recommended Stack (Next.js 15 + React 19)

Where the Ecosystem Is Heading

The trajectory is clear: React is becoming a hybrid server-client framework, not just a browser library. The boundaries between "frontend" and "backend" are blurring: a server component is a React component that talks directly to a database, and that is now considered conventional. Other frameworks (Remix, SolidStart, SvelteKit, Astro) have converged on similar hybrid models. The direction is toward less JavaScript in the browser, more server-side rendering, and streaming UI that arrives progressively.

React 19 has deepened this with native async component support, improved Suspense semantics, and first-class Server Actions. The engineers who understand this model in 2026: who know instinctively which part of a problem belongs on the server and which belongs on the client: will build faster, more secure, and more maintainable applications.