Server Rendering per Request

Your task is a mailbox page: it shows "you have 3 unread messages" — your messages, from your session. There is no build-time trick that can produce this HTML. The value depends on who is asking, and the request is the only place that information exists. This is the case dynamic rendering answers: the page's HTML is built on the server during the request, from data that request alone provides.

Follow one request through the machinery, because every rendering-strategy question in an interview reduces to "when was the HTML built?" The browser's request hits the Next.js server (Node runtime by default), the matched route's components run as Server Components, their awaits resolve against your database, React renders the tree to an HTML string, and that is what goes on the wire — followed later by the JavaScript needed to hydrate the interactive parts. Nothing was cached ahead of time; nothing will be reused for the next visitor.

Contrast the two timelines for the same route:

That last row is the trade-off people forget. A render that burns 150 ms of CPU on one core caps a single instance at roughly 6–7 requests per second; serving 200 RPS of the same page means ~30 instances (or aggressive caching of the parts that can be cached). Dynamic rendering is not "free freshness" — it is freshness paid for on every single request, forever. When an interviewer asks "why not make everything dynamic?", that capacity math is the answer, and the escape hatches — caching data, static segments, Static Generation with generateStaticParams — are what this whole phase is about.

The Pages Router solved this same problem with a page-level function:

// Pages Router (legacy): pages/mailbox.tsx
export async function getServerSideProps(context: GetServerSidePropsContext) {
  const session = await getSession(context.req);
  const unread = await countUnread(session.userId);
  return { props: { unread } };       // fetched BEFORE the component renders
}

The App Router deletes the special function. The component itself is async and fetches during render:

// app/mailbox/page.tsx — Server Component by default
import { cookies } from "next/headers";
import { countUnread } from "@/lib/mail";

export default async function MailboxPage() {
  const token = (await cookies()).get("session")?.value;
  const userId = await verifySession(token);
  const unread = await countUnread(userId);   // direct DB access, no API layer
  return <MailboxView unread={unread} userId={userId} />;
}

Same request-time execution, fewer moving parts: no props serialization boundary, no getServerSideProps ordering rules, and the query runs in the same process as the render instead of a round trip through an HTTP endpoint. If the concept of async server data access is new to you, Server Components by Default is where that model is established; this topic is about when that render happens, not where the component runs.

One important non-goal: dynamic rendering does not mean "the page is JavaScript." The HTML you send is complete server-rendered markup — the mailbox reads fine with JS disabled (interactivity hydrates on top). Dynamic describes the timing of the build, not the side it runs on. Server versus client, and static versus dynamic, are two independent axes, and mixing them up is the most common conceptual error in this area.

Two pages can show identical UI. One sends finished HTML and hydrates; the other sends an empty <div id="root"> plus 250 KB of JavaScript that fetches data, then renders. On a mid-range phone over 4G, the first shows readable text in 300–600 ms; the second shows a blank screen for 2–4 seconds while JS downloads, parses, executes, and its useEffect fetches complete. Server rendering sends usable markup before JavaScript, which is why first contentful paint — and everything gated on it — improves.

The mechanism behind that advantage is the browser's preload scanner. The moment the HTML arrives, the scanner discovers <img>, fonts, and stylesheet links without waiting for the main thread — so the hero image's download starts in parallel with JS execution instead of after it. That is also why the Largest Contentful Paint element usually wins under SSR: its URL is in the first packet, not the fifth JavaScript chunk. In a single-page app, the LCP image URL often does not exist until React runs, which forfeits 1–2 seconds on mobile before the image even enters the request queue.

Be precise about what "hydrates" means in the App Router, because the old model no longer fully applies. Yes, interactive pieces still need their JavaScript and a client-side mount. But with Server Components, the components that produced the static markup ship zero of their code — the browser receives HTML plus the serialized RSC payload, not a duplicate of the render logic. Dynamic SSR pages therefore weigh less on the client than Pages Router SSR pages of the same UI, where every component downloaded twice: once to render on the server, once to hydrate in the browser. Measured first-load JS is the number to quote; next build prints it per route.

The cost ledger must be kept honest, because SSR's weaknesses are real and interviewers probe them:

The availability row deserves emphasis. A prerendered page lives in a CDN; if your database hiccups, the cached copy keeps serving. A dynamic page has no such buffer — every request needs a healthy render path. That is why teams put static shells, stale-while-revalidate data caches, and rate limits in front of dynamic routes rather than letting raw queries face the internet.

SEO benefits from the same property, with a caveat. Crawlers receive the final HTML immediately — no render queue, no budget spent executing your bundle. Google can execute JavaScript, but link previews and many smaller crawlers cannot, and Googlebot's second-wave JS rendering is not guaranteed within a crawl window. For anything you need indexed reliably, server-rendered HTML is the safe default. The other half of the SEO story — titles, descriptions, social cards — is The Metadata API, which rides on the same server render.

So when is per-request rendering the right answer? When the data is per-user, when it changes on every write and staleness is unacceptable (live pricing, seat availability), or when the page has no meaningful key to cache by. When the answer is "per-user only sometimes," the interesting designs split the page — static shell, dynamic islands — which is where Forcing Dynamic Rendering and streaming come in.

You prerender a marketing page. It works. Then a teammate adds a personalized greeting to the shared layout — const name = (await cookies()).get("user") — and suddenly a route you believed was static is rebuilt on every request. No warning, no error; you discover it when the server bill doubles. This is the defining behavior of the App Router's rendering model: reading a request-time API anywhere in a route's tree opts that route into dynamic rendering, automatically.

The opt-in list, in full:

The trigger propagates upward in the only direction that matters for surprises: a dynamic API used in a layout makes every page under that layout dynamic, because the layout's HTML must be rebuilt per request to compose the page. A dynamic API confined to one page's leaf component affects just that page. This is why the auth-layout pattern — reading the session cookie in app/(app)/layout.tsx to render the avatar — quietly dynamizes entire sections, and why the fix (splitting session lookup into a client component, or accepting dynamic rendering consciously) is a design decision rather than a bug fix.

The build output is where you find out what actually happened. Read the route table after every next build:

Route (app)                              Size     First Load JS
┌ ○ /                                    1.2 kB        98.4 kB
├ ○ /pricing                             0.9 kB        97.2 kB
├ ƒ /dashboard                           2.4 kB       101.3 kB
├ ƒ /mailbox                             1.8 kB       100.7 kB
└ ● /blog/[slug]                         1.1 kB        98.1 kB

○ means statically prerendered (HTML generated at build, served from cache — the subject of the next topic), ƒ means rendered on demand per request, ● means some paths were prerendered via generateStaticParams with the rest rendered on demand. Seeing ƒ next to a route you expected to be ○ is the signal: trace which API in its tree requested per-request rendering. On the Pages Router the same table used λ for serverless-rendered pages — if a codebase you are interviewing about still shows λ, it predates the App Router.

You can also force the state explicitly rather than inherit it, with a segment config export:

export const dynamic = "force-dynamic";   // always render this segment per request

The two directions exist for different reasons. Implicit opt-in protects correctness — it is never safe to serve cookie-derived HTML from cache, so the router dynamizes by default. Explicit force-dynamic covers the cases the API scan cannot see: data you read through a non-fetch path (a direct Prisma query with time-dependent results) that must not be prerendered even though no request API touched it. The full option set, and how static and dynamic segments coexist in one tree, is Forcing Dynamic Rendering.

A last calibration for interviews: "server-side rendering" as a term covers both timing regimes — this topic's per-request rendering and build-time prerendering are both server rendering. The App Router's default is to prerender when it can and go dynamic when an API demands it. Your job as the engineer is to know which one each route landed on, verify it in the build table, and defend that choice with the freshness-versus-capacity math from the first chapter — not to treat the distinction as trivia. The next topic, Static Generation with generateStaticParams, is what happens when you choose the other side on purpose.