Server Components vs Client Components, Explained

React Server Components are the most consequential change to React in a decade, and also the one that trips up the most experienced engineers — precisely because they have a decade of instinct that says "components run in the browser." In the Next.js App Router that instinct is wrong by default, and unlearning it is the whole job.

This post is the deep version of the boundary question we touch on in our Next.js 16 App Router guide. We draw this line on every web application we build, and getting it right is the difference between a 40 KB page and a 400 KB page. If you are new to the framework, start with what Next.js is.

The boundary is the 'use client' directive. Everything in that file and everything it imports becomes part of the client bundle. The skill is placing it as deep in the tree as possible so the smallest amount of code crosses over.

Consider a product page with a static description and an interactive "add to cart" button. The wrong instinct is to make the whole page a client component. The right move is to keep the page on the server and isolate just the button:

// src/app/products/[id]/page.tsx  (server component)
import { getProduct } from "@/lib/products";
import { AddToCartButton } from "./AddToCartButton";

export default async function ProductPage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;
  const product = await getProduct(id);   // server-side, no client JS

  return (
    <article>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      {/* only this leaf becomes client JS */}
      <AddToCartButton productId={product.id} />
    </article>
  );
}

// src/app/products/[id]/AddToCartButton.tsx
'use client';

import { useState } from "react";

export function AddToCartButton({ productId }: { productId: string }) {
  const [added, setAdded] = useState(false);
  return (
    <button onClick={() => setAdded(true)}>
      {added ? "Added" : "Add to cart"}
    </button>
  );
}

The product name, description, and markup ship as zero-JS HTML. Only the tiny button hydrates. On a page with dozens of products that is the difference between a snappy load and a janky one.

The boundary is one-directional: a client component cannot import a server component. But you constantly need a client wrapper — a theme provider, an accordion, a tab panel — around server-rendered content. The answer is composition through children.

// Client wrapper that accepts server-rendered children
'use client';
import { useState } from "react";

export function Collapsible({ children }: { children: React.ReactNode }) {
  const [open, setOpen] = useState(false);
  return (
    <div>
      <button onClick={() => setOpen((o) => !o)}>Toggle</button>
      {open && children}
    </div>
  );
}

// Server component fills the children slot — ServerHeavyPanel
// never enters the client bundle.
import { Collapsible } from "./Collapsible";
import { ServerHeavyPanel } from "./ServerHeavyPanel";

export default function Page() {
  return (
    <Collapsible>
      <ServerHeavyPanel />   {/* stays on the server */}
    </Collapsible>
  );
}

The client component controls the interactivity; the server component it wraps is rendered on the server and passed in as an already-rendered tree. This pattern is how you keep providers and interactive shells thin while the bulk of the page stays server-side.

1. 'use client' at the top of a layout or page. This is the cardinal sin. It marks the entire subtree as client, so every child — even static content — ships as JavaScript. Move the directive to the interactive leaf.
2. Wrapping the app in a client provider directly. If your root layout renders a client <Providers> component that wraps children, that is fine — but only if Providers uses the children prop rather than importing the page tree. Keep providers as thin client shells.
3. Pulling in a heavy library at the client boundary. A date picker, a charting library, or a markdown renderer imported into a client component drags its whole weight into the bundle. Render static output on the server where you can; lazy-load heavy client widgets with next/dynamic.
4. Using useEffect to fetch first-paint data. If the data is needed to render, fetch it in a server component and pass it down. Client-side fetching adds a round-trip and a loading flash.
5. Passing non-serializable props across the boundary. Functions, class instances, and Dates-as-methods do not serialize. The build will warn you; respect it and pass plain data plus a Server Action for behavior.
6. Marking a whole UI-kit barrel file as client. If you re-export both server-safe and client-only components from one index.ts with 'use client' at the top, you force everything client. Split the barrel.

The reason the default-server posture matters is hydration. Every client component that renders on first paint must be re-executed in the browser to attach event handlers — that is hydration, and it is CPU work that blocks interactivity, especially on mid-range phones.

• Server component: ships HTML, ships zero JS for itself, costs nothing to hydrate.
• Client component: ships HTML plus its JS plus its dependencies, and pays hydration CPU on load.
• Net effect: moving a 60 KB interactive tree to a 6 KB leaf cuts both transfer size and main-thread hydration time by roughly 90% for that subtree.

For a content-heavy marketing page, going server-first routinely takes Time to Interactive from multiple seconds on a throttled mobile connection down to under a second. For a dashboard that is mostly interactive, the win is smaller because the interactivity is real — but even then, the static chrome, headers, and read-only panels belong on the server. The broader rendering background lives in our explainer on server-side rendering.

When you are unsure which type a component should be, run it through these questions in order. The first "yes" in the client column decides it.

1. Does it need useState, useReducer, or useEffect? If yes, client.
2. Does it attach an event handler like onClick or onChange? If yes, client.
3. Does it use a ref to a DOM node or a browser API? If yes, client.
4. Does it depend on a third-party library that touches the DOM? If yes, client (and consider lazy-loading it).
5. Does it only display data, read server resources, or compose other components? If yes, server.
6. Default: server.

This is the same heuristic we apply when scoping SaaS platform builds and the internal tools covered in our platform engineering guide.