Rendering Strategies, SSR & Server Components

Every React app has to turn components into HTML at some point. The rendering strategies differ in where that happens (browser or server) and when (per request, at build time, or on a schedule):

• CSR — client-side rendering. The server sends an almost empty HTML page and a JavaScript bundle; the browser downloads the JS, runs React, fetches data and builds the page. Classic Vite or Create React App SPAs.
• SSR — server-side rendering. On every request the server runs React, produces the full HTML for that URL and sends it. The browser shows it immediately, then downloads the same JS and hydrates it to make it interactive.
• SSG — static site generation. The same render as SSR, but done once at build time for every known page; the HTML files are served from a CDN like any static file.
• ISR — incremental static regeneration. SSG with an expiry: pages are generated at build time (or on first request), served from the cache, and re-generated in the background after a set time or when you invalidate them. A Next.js term; other frameworks call it stale-while-revalidate caching of rendered pages.

The mental model is a restaurant. CSR hands you the ingredients and a recipe (the JS bundle) and you cook at your table. SSR cooks each dish to order in the kitchen. SSG cooks everything before opening and keeps it warm. ISR is SSG where the kitchen quietly replaces a dish when it's been out too long. The diner (user) sees food soonest with SSG, then SSR; with CSR they wait for their own cooking, but once the kitchen is at the table every later dish (client-side navigation) is fast.

import { useState } from "react";

export function App({ products }) {
  const [cart, setCart] = useState(0);
  return (
    <main>
      <h1>Shop</h1>
      <ul>
        {products.map((p) => (
          <li key={p.id}>
            {p.name}: ${p.price}
          </li>
        ))}
      </ul>
      <button onClick={() => setCart((c) => c + 1)}>Cart: {cart}</button>
    </main>
  );
}

// CSR: what the server sends for every URL
// <!doctype html><html><head><title>Shop</title></head>
//   <body><div id="root"></div><script type="module" src="/assets/index-a1b2c3.js"></script></body></html>

// SSR: renderToString(<App products={products} />) on the server gives
// <main><h1>Shop</h1><ul><li>Keyboard<!-- -->: $<!-- -->80</li><li>Mouse<!-- -->: $<!-- -->25</li></ul>
//   <button>Cart: <!-- -->0</button></main>

From my notes, when to use each, with my corrections inline:

• Use CSR when you're building a highly interactive SPA where the experience is mostly client-side after the first load; when SEO isn't a concern, such as dashboards and apps used by logged-in users; and when initial load time matters less than interactivity afterwards. All still true.
• Use SSR when SEO is crucial — blogs, e-commerce, any content-heavy site you want indexed. True, but SSG is just as good for SEO and cheaper when the content doesn't depend on the request (see SEO for React apps).
• Use SSR for a faster initial load on slow networks, because users don't wait for JavaScript to see content. Mostly true, with a caveat my notes don't mention: content is visible sooner, but the page isn't interactive until the same JavaScript has downloaded and hydrated, and every request now waits for the server to render (a slower time to first byte). A page that looks ready but ignores clicks is its own kind of bad experience.
• "Static content: SSR (with caching) can be a good fit." Correcting my notes: content that rarely changes is the case for SSG or ISR, not per-request SSR. Rendering the same HTML on every request just to cache it is what SSG does once at build time.

Modern frameworks don't make you pick one for the whole app. Next.js, React Router's framework mode and TanStack Start choose per route (static for the marketing pages, server-rendered for the account page) and even per component (a static shell with dynamic parts streamed in — see Streaming SSR and Next.js App Router in brief).

From my notes: SSR can be done with a framework like Next.js, or manually with react-dom/server's renderToString on a Node server, sending the resulting HTML to the client. My notes have a "full fledged" Express example and add that "you also need webpack and babel".

The mental model: renderToString is React with a string as the output device instead of the DOM. It calls your components once, with no effects, no state updates and no event handlers (none of that can happen on a server), and concatenates the result. The client then has to run the same components with the same data so React can adopt that HTML (hydration).

Here is my notes' server, updated (ES modules instead of require, Express 5 routing syntax, the data embedded for the client, and a hydrating client entry). It runs with Express 5.2 and supertest in the sandbox:

import express from "express";
import { renderToString } from "react-dom/server";
import { App } from "./App.jsx";

const getProducts = async () => [
  { id: 1, name: "Keyboard", price: 80 },
  { id: 2, name: "Mouse", price: 25 },
];

// Data goes into a <script>; escape "<" so a product named "</script>" can't break out.
export const serialize = (data) => JSON.stringify(data).replace(/</g, "\\u003c");

export function createServer() {
  const app = express();

  // Built client assets (index-[hash].js, CSS) from the client build
  app.use("/assets", express.static("dist/client/assets"));

  // Express 5 wildcard syntax: "/{*splat}" (Express 4 accepted "*")
  app.get("/{*splat}", async (req, res) => {
    const products = await getProducts(); // 1. fetch data on the server
    const appHtml = renderToString(<App products={products} />); // 2. render to HTML

    res.send(`<!doctype html>
<html>
  <head><title>My SSR App</title></head>
  <body>
    <div id="root">${appHtml}</div>
    <script>window.__INITIAL_DATA__ = ${serialize(products)}</script>
    <script type="module" src="/assets/client.js"></script>
  </body>
</html>`);
  });

  return app;
}

// main: createServer().listen(3000, () => console.log("Server is running on port 3000"));

import { hydrateRoot } from "react-dom/client";
import { App } from "./App.jsx";

// Same component, same data as the server used -> React can adopt the existing DOM.
hydrateRoot(document.getElementById("root"), <App products={window.__INITIAL_DATA__} />);

The server APIs in React 19.3, from the installed react-dom package:

Hydration is how server-rendered HTML becomes a working React app. The browser has already painted the server's HTML; hydrateRoot then renders the same components in the browser, but instead of creating DOM nodes it walks the existing ones, checks that they match what it would have created, and attaches event handlers and state to them. After hydration the page behaves exactly like a client-rendered app.

The mental model: the server ships a photograph of the UI. Hydration is React walking through the photographed room and wiring every light switch to real electricity, matching each switch in the photo to one it would have installed. If the photo shows a switch where React would have put a socket, it can't wire it — that's a hydration mismatch.

import { act } from "react";
import { hydrateRoot } from "react-dom/client";
import { renderToString } from "react-dom/server";
import { App } from "./App";

const products = [{ id: 1, name: "Keyboard", price: 80 }];

// 1. What the server sent (rendered here with the server renderer)
const container = document.createElement("div");
container.innerHTML = renderToString(<App products={products} />);
document.body.append(container);

const buttonBefore = container.querySelector("button");
buttonBefore.click(); // before hydration: plain HTML, no handler

// 2. The client entry
await act(async () => {
  hydrateRoot(container, <App products={products} />);
});

const buttonAfter = container.querySelector("button");
buttonAfter.click(); // after hydration: React's handler runs

Hydration only works if the first client render produces exactly the server's output. When it doesn't, React 19 reports a recoverable error and re-renders that part of the tree on the client, discarding the server HTML:

import { useEffect, useState, useSyncExternalStore } from "react";

// ❌ Different output on server and client
export function BadGreeting() {
  const where = typeof window === "undefined" ? "server" : "browser";
  return <p>Rendered on the {where}</p>;
}

// ✅ Two-pass: render the server's version first, switch after hydration
export function GoodGreeting() {
  const [hydrated, setHydrated] = useState(false);
  useEffect(() => setHydrated(true), []); // effects never run on the server
  return <p>Rendered on the {hydrated ? "browser" : "server"}</p>;
}

// ✅ Or useSyncExternalStore: getServerSnapshot is used on the server AND during hydration
const subscribe = () => () => {};
export function useIsClient() {
  return useSyncExternalStore(subscribe, () => true, () => false);
}
export function Width() {
  const isClient = useIsClient();
  return <p>Width: {isClient ? window.innerWidth : "unknown"}</p>;
}

// ✅ For a single unavoidable difference (timestamps)
export function Stamp({ date }) {
  return <time suppressHydrationWarning>{date.toLocaleTimeString()}</time>;
}

Common causes of mismatches: typeof window checks in render, Date.now()/Math.random()/crypto.randomUUID() in render (use useId for ids), locale-dependent formatting (server and user in different time zones), reading localStorage during render, invalid HTML nesting (a <div> inside a <p>, which the browser's parser "fixes" so the DOM no longer matches), and browser extensions that inject elements. React 19 also tolerates unexpected tags that third-party scripts and extensions insert in <head> and <body>, which used to cause spurious mismatches.

function Price() {
  return (
    <p>
      Price: <div className="amount">$80</div>
    </p>
  );
}

renderToString has two problems on a real page: the server can't send anything until the slowest data on the page has been fetched, and the client can't hydrate anything until all the JavaScript has loaded. Streaming SSR fixes both by using <Suspense> boundaries as seams: the server sends the HTML outside the boundaries (the shell) right away, with fallbacks in place of slow parts, then keeps the connection open and streams each part's HTML when its data is ready.

The mental model is a newspaper delivered in sections: the front page arrives first, and the sports results are slipped through the letterbox later, already laid out, along with a note saying which page they replace. The reader starts reading straight away.

import { Suspense, use } from "react";

export function Reviews({ reviewsPromise }) {
  const reviews = use(reviewsPromise); // suspends until the promise resolves
  return (
    <ul>
      {reviews.map((r) => (
        <li key={r}>{r}</li>
      ))}
    </ul>
  );
}

export function ProductPage({ reviewsPromise }) {
  return (
    <html>
      <head>
        <title>Keyboard</title>
      </head>
      <body>
        <h1>Keyboard</h1>
        <p>$80 — in stock</p>
        <Suspense fallback={<p>Loading reviews…</p>}>
          <Reviews reviewsPromise={reviewsPromise} />
        </Suspense>
      </body>
    </html>
  );
}

import { renderToPipeableStream } from "react-dom/server";

app.get("/{*splat}", (req, res) => {
  const reviewsPromise = fetchReviews(); // starts now, resolves in ~50 ms
  const { pipe } = renderToPipeableStream(<ProductPage reviewsPromise={reviewsPromise} />, {
    bootstrapScripts: ["/assets/client.js"],
    onShellReady() {
      res.setHeader("content-type", "text/html");
      pipe(res); // start streaming as soon as the shell is ready
    },
    onShellError() {
      res.status(500).send("<h1>Something went wrong</h1>");
    },
    onAllReady() {
      // everything rendered; for crawlers, wait for this before piping instead
    },
    onError(error) {
      console.error(error); // errors inside Suspense boundaries
    },
  });
});

For static generation, prerender from react-dom/static is the "wait for everything" version: a test passes a reviews promise that resolves after 20 ms and gets one finished document, <!DOCTYPE html><html>…<h1>Keyboard</h1><p>$80 — in stock</p><!--$--><ul><li>Great keys</li></ul><!--/$--></body></html>, with no fallbacks and no inline scripts — ready to write to a file at build time. (Its prelude is a Web ReadableStream; prerenderToNodeStream returns a Node stream instead.)

import { resumeToPipeableStream } from "react-dom/server";
import { prerender } from "react-dom/static";

// Build time: abort before the reviews resolve, so they become a "hole".
const controller = new AbortController();
const p = prerender(<ProductPage reviewsPromise={new Promise(() => {})} />, { signal: controller.signal });
setTimeout(() => controller.abort(), 10);
const { prelude, postponed } = await p;
// prelude: the static shell (store it on a CDN)
// postponed: JSON-serialisable state describing the holes (store it next to the shell)

// Request time: send the stored shell, then resume with real data.
const { pipe } = resumeToPipeableStream(<ProductPage reviewsPromise={fetchReviews()} />, postponed, {
  onShellReady: () => pipe(res),
});

From my notes: you improve the SEO of a React application by implementing SSR, or using a framework like Next.js, which generates HTML on the server so search engines can index the page easily. That's the core answer, and it's right. The rest of this topic is the detail behind it.

The mental model: a search engine (or a link-preview bot for Slack, LinkedIn or WhatsApp) is a visitor in a hurry with JavaScript often switched off. Googlebot does run JavaScript, but rendering is queued separately from crawling, so JS-only content can be indexed later and less reliably; many other crawlers and almost every social preview bot don't run JavaScript at all. Whatever matters for discovery must be in the HTML the server sends: the content, the title and description, the links, and the structured data.

export function ProductSeo({ product }) {
  const url = `https://shop.example.com/products/${product.slug}`;
  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "Product",
    name: product.name,
    offers: { "@type": "Offer", price: product.price, priceCurrency: "CAD" },
  };
  return (
    <article>
      {/* React 19: these are hoisted into <head>, wherever they're rendered */}
      <title>{`${product.name} | Shop`}</title>
      <meta name="description" content={product.summary} />
      <link rel="canonical" href={url} />
      <meta property="og:title" content={product.name} />
      <meta property="og:image" content={product.image} />

      <h1>{product.name}</h1>
      <p>{product.summary}</p>
      {/* Structured data for rich results; escape < like any inline JSON */}
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c") }}
      />
    </article>
  );
}

export function Document({ children }) {
  return (
    <html lang="en">
      <head>
        <meta charSet="utf-8" />
      </head>
      <body>{children}</body>
    </html>
  );
}

// renderToString(<Document><ProductSeo product={product} /></Document>)

The checklist interviewers expect, beyond "use SSR":

• Render content and metadata on the server (SSR or SSG). Per-page <title>, <meta name="description">, Open Graph/Twitter tags for link previews, <link rel="canonical"> to avoid duplicate URLs (?sort= variants). Frameworks have APIs for this: Next.js metadata/generateMetadata, React Router meta exports, or React 19's built-in tags.
• Real links. Navigation must be <a href> elements (React Router's <Link> renders one); crawlers follow hrefs, not onClick handlers.
• Correct status codes. A missing product must return 404, not a 200 page that says "not found" (a "soft 404"). That's only possible when the server renders the route — a CSR app always returns 200 with index.html.
• Semantic HTML. One <h1>, headings in order, <nav>, <main>, <article>, alt text on images.
• Sitemap and robots.txt, so crawlers find every page and skip the ones that don't matter.
• Performance. Core Web Vitals (LCP, INP, CLS) are a ranking signal: SSR/SSG for fast LCP, reserved image sizes to avoid layout shift, less JavaScript for a good INP.
• Stable URLs per piece of content, not state hidden in memory — the router's job (see Route params and useLocation).

My notes mention "server rendered component although no tooling yet… so better to use Next.js". That was the situation in late 2024. Server Components are now stable in React 19, and the tooling exists, but the advice still holds in spirit: you use them through a framework or bundler integration (Next.js App Router is the most complete; React Router has RSC support marked unstable; there are Vite and Parcel integrations), not by calling an API yourself. Nothing in this topic could run in the sandbox, which has no RSC bundler; the code follows the Next.js 16 and react.dev docs and wasn't executed.

A Server Component is a component that runs only on the server (at request time or at build time) and is never sent to the browser as JavaScript. It can be async, it can read a database or the file system directly, and it can import large libraries (a Markdown parser, a syntax highlighter) at zero cost to the bundle. What reaches the browser is its output — a serialised description of the rendered tree, called the RSC payload — not its code. Client Components are the components you already know: they're also server-rendered to HTML, then shipped as JS and hydrated, and they're the only ones that can use state, effects and event handlers.

The mental model: a Server Component is like a PHP template that outputs React elements instead of HTML strings. It runs where the data is, does its work, and hands the browser a finished description with holes in it, and the holes are Client Components ("put an interactive <LikeButton count={12} /> here"). This is not the same as SSR: SSR is about producing HTML for a first paint, for any component; RSC is about where a component's code lives and runs at all. They're used together: server components produce the RSC payload, and SSR turns the whole tree (server output plus client components) into HTML for the first load.

// A Server Component (the default in the Next.js App Router): no directive needed.
import { db } from "@/lib/db";
import { formatPrice } from "@/lib/format"; // runs on the server only; never in the bundle
import { LikeButton } from "./LikeButton";
import { Reviews } from "./Reviews";

export default async function ProductPage({ params }) {
  const { id } = await params; // Next.js 15+: params is a Promise
  const product = await db.product.findUnique({ where: { id } }); // direct DB access

  return (
    <article>
      <h1>{product.name}</h1>
      <p>{formatPrice(product.price)}</p>
      <LikeButton productId={product.id} initialLikes={product.likes} />
      <Reviews productId={product.id} /> {/* another Server Component */}
    </article>
  );
}

"use client"; // this file and everything it imports run in the browser too

import { useState } from "react";

export function LikeButton({ productId, initialLikes }) {
  const [likes, setLikes] = useState(initialLikes);
  return <button onClick={() => setLikes((n) => n + 1)}>♥ {likes}</button>;
}

The rules, as you'd state them in an interview:

• Server Components can't use state, effects, refs, context or browser APIs, and can't take event handler props — there's no browser and no re-render on the server. Those need Client Components.
• Client Components can't import Server Components (an import from a "use client" file makes the imported module client code too). But they can receive them as props, typically children: <ClientTabs>{<ServerList />}</ClientTabs> works because the server renders ServerList and passes its output in.
• Props from server to client must be serialisable. Passing a function fails with an error telling you only Server Functions ('use server') can be passed.
• Server Components are the default in the App Router; you opt into the client per module with 'use client', and you push that boundary as far down the tree as possible, to the interactive leaves.
• Server-only code should say so: import "server-only" at the top of a module (a small package Next.js supports) makes the build fail if a Client Component ever imports it, so secrets can't leak into the bundle by accident.

React's two directives are string literals at the top of a module or function, and both mark a boundary between the server and client module graphs — not "where this code runs" in the simple sense. 'use client' says: from this module down, code can also run in the browser — ship it, and let the server reference it. 'use server' says: these async functions stay on the server — give the client a way to call them over the network.

The mental model is two doors in the wall between server and browser. 'use client' is the door the server uses to hand the browser an interactive component ("render this, here are its props"). 'use server' is the door the browser uses to ask the server to do something ("run addTodo with this form data"). Everything else stays on its own side.

"use server"; // every export is a Server Function the client can call

import { updateTag } from "next/cache";
import { db } from "@/lib/db";
import { getSession } from "@/lib/auth";

export async function addTodo(prevState, formData) {
  const session = await getSession(); // a Server Function is a public endpoint: check who's calling
  if (!session) return { error: "Please log in" };

  const title = String(formData.get("title") ?? "").trim(); // and never trust the input
  if (!title) return { error: "Title is required" };

  await db.todo.create({ data: { title, userId: session.userId } });
  updateTag("todos"); // Next.js 16: expire cached todo data so the next render reads fresh data
  return { error: null };
}

"use client";

import { useActionState } from "react";
import { addTodo } from "./actions";

export function AddTodoForm() {
  const [state, formAction, isPending] = useActionState(addTodo, { error: null });
  return (
    <form action={formAction}>
      <input name="title" aria-label="Title" />
      <button disabled={isPending}>{isPending ? "Adding…" : "Add"}</button>
      {state.error && <p role="alert">{state.error}</p>}
    </form>
  );
}

import { db } from "@/lib/db";
import { AddTodoForm } from "./AddTodoForm";

export default async function TodosPage() {
  const todos = await db.todo.findMany(); // Server Component: reads directly
  return (
    <>
      <ul>
        {todos.map((t) => (
          <li key={t.id}>{t.title}</li>
        ))}
      </ul>
      <AddTodoForm />
    </>
  );
}

Things people get wrong:

• 'use client' doesn't mean "client-only". Client Components are still rendered to HTML on the server during SSR. Code that touches window still has to go in effects or event handlers.
• 'use client' is needed only at the boundary, the entry file the server imports. Modules imported by a client module are client code automatically; putting the directive in every file is unnecessary.
• 'use server' isn't for Server Components. Server Components need no directive. 'use server' marks Server Functions — functions callable from the client. React's docs call them Server Functions in general and Server Actions when they're used as a form action or inside a transition.
• Server Functions are for mutations, not data fetching. React's docs note that frameworks typically process them one at a time and can't cache their results; read data in Server Components (or loaders), write with Server Functions.
• Arguments and return values of Server Functions must be serialisable (FormData, plain objects, primitives…), for the same reason props to client components must be.

Next.js is the most widely used React framework, and since version 13 it has two routers. The App Router (app/ directory) is the modern one, built on React Server Components, streaming and Suspense; the Pages Router (pages/ directory) is the original, still supported, and still in many codebases. This topic covers the App Router in Next.js 16 (current release 16.4), with the Pages Router equivalents for comparison. Next.js isn't installed in the sandbox, so the examples follow the official docs and weren't executed.

The mental model: folders are routes, special files are their parts. app/blog/[slug]/page.jsx is the page at /blog/:slug; the layout.jsx, loading.jsx and error.jsx files next to it wrap it in a shared layout, a Suspense boundary and an error boundary. Everything is a Server Component unless a file says 'use client'.

import { notFound } from "next/navigation";
import { getPost, getAllSlugs } from "@/lib/posts";

// SSG for known posts: Next.js prerenders these at build time
export async function generateStaticParams() {
  const slugs = await getAllSlugs();
  return slugs.map((slug) => ({ slug }));
}

// Per-page SEO metadata, rendered into <head> on the server
export async function generateMetadata({ params }) {
  const { slug } = await params;
  const post = await getPost(slug);
  return { title: post?.title, description: post?.summary };
}

export default async function BlogPost({ params }) {
  const { slug } = await params; // params is a Promise in Next.js 15+, and must be awaited in 16
  const post = await getPost(slug);
  if (!post) notFound(); // renders not-found.jsx with a 404 status

  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.html }} />
    </article>
  );
}

The special files, from the outside in for one route segment:

Folder conventions: [slug] (dynamic segment), [...slug] (catch-all), (marketing) (a route group: organises files and layouts without adding a URL segment), @sidebar (parallel route slot; every slot needs a default.js in Next.js 16), _components (private folder, never a route).

What changed in Next.js 16, from the release notes:

• Cache Components. Caching is now opt-in and explicit: with cacheComponents: true in next.config, everything is dynamic by default, and you cache a page, component or function by adding 'use cache' (with cacheLife('hours') and cacheTag('posts') from next/cache). Next.js prerenders a static shell and streams the uncached, request-specific parts — partial prerendering, built on React's prerender/resume. The old route segment options export const revalidate, dynamic and fetchCache are replaced (and error) when it's on.
• Invalidation APIs: updateTag(tag) in Server Actions for read-your-writes; revalidateTag(tag, 'max') now requires a cache profile as its second argument for stale-while-revalidate; refresh() re-renders uncached data.
• proxy.ts replaces middleware.ts (rename the file and export a proxy function); it runs on the Node.js runtime.
• Turbopack is the default bundler for next dev and next build (--webpack to opt out); React Compiler support is stable (reactCompiler: true, off by default).
• Async request APIs only: params, searchParams, cookies(), headers() and draftMode() must be awaited.
• Removed: AMP, the next lint command, serverRuntimeConfig/publicRuntimeConfig. Minimum Node.js 20.9.

import { Suspense } from "react";
import { cacheLife, cacheTag } from "next/cache";

async function getPost(slug) {
  "use cache"; // the result is cached; slug is part of the cache key
  cacheLife("hours"); // was: export const revalidate = 3600
  cacheTag(`post-${slug}`); // lets a Server Action call updateTag(`post-${slug}`) after an edit
  const res = await fetch(`https://cms.example.com/posts/${slug}`);
  return res.json();
}

export default function Page({ params }) {
  return (
    <Suspense fallback={<p>Loading…</p>}>
      <Post params={params} />
    </Suspense>
  );
}

async function Post({ params }) {
  const { slug } = await params;
  const post = await getPost(slug);
  return <h1>{post.title}</h1>;
}

App Router vs Pages Router, for codebases that have both: