Rendering Strategies

1The frame — one axis, not six buzzwords

Don't memorize six acronyms as a list. They're all answers to one question: where (browser / server / build machine) and when (build-time / request-time / on-demand) do we turn components + data into the HTML the user first sees — and how much JavaScript do we then ship to make it interactive?

Two responses sit at the extremes, everything else is in between: [web.dev — Rendering on the Web]

• CSR — ship an empty <div id="root"> + a JS bundle. The browser builds the HTML at request time. Fast server, slow first paint, bad SEO without help.
• SSG — build the finished HTML once at deploy time. The server (CDN) just hands over a static file. Fastest possible, but frozen until rebuild.

Between them: SSR (build HTML per request on the server), ISR (static, but regenerate in the background), streaming SSR (send HTML in chunks as it's ready), and RSC (render some components on the server and never ship their JS). The metrics they trade:

2The family — what each optimizes & when to pick it

Critically, these are not mutually exclusive. A modern app mixes them per route and per component: a marketing page is SSG, the search results are streaming-SSR, the filter panel is a client island, the hotel detail page is ISR. Picking one strategy for the whole app is a junior tell. [patterns.dev]

3The hydration tax & why streaming exists

Server rendering has a hidden cost. The server sends HTML, the user sees it fast — but it isn't interactive yet. The browser must download the JS, then hydrate: re-run the component tree on the client to attach event handlers and rebuild state, matching the server HTML. Until hydration finishes, buttons look ready but do nothing — the “uncanny valley.” Hydration roughly re-does the server's work on a weaker device, and it's a top source of poor INP. [web.dev] (Lesson 10 goes deep on hydration; here it's the motivation.)

Classic SSR is also all-or-nothing in two ways: the server can't send any HTML until every data fetch resolves (TTFB held hostage by the slowest query), and the client can't make any part interactive until the whole bundle hydrates. Streaming SSR + <Suspense> breaks both:

<Layout>
  <SearchResults />        // fast — render & flush immediately
  <Suspense fallback={<Skeleton/>}>
    <Reviews />            // slow query — stream in when ready
  </Suspense>
</Layout>

The server flushes the shell + results now with a skeleton in the Reviews slot, keeps the connection open, and pushes the Reviews HTML when its query resolves. React also does selective hydration: it hydrates the streamed-in chunks independently, and prioritises whatever the user interacts with first. Fast first paint without letting one slow widget block the page. [react.dev — Suspense]

4RSC — paying down the JavaScript itself

Streaming fixes when HTML arrives; React Server Components attack the deeper cost — how much JS you ship at all. An RSC renders only on the server and sends its output to the client as a serialized description — but ships zero JavaScript for itself. Data-fetching, markdown rendering, big formatting libs, DB access all live server-side and never enter the bundle. Components that need interactivity (state, effects, event handlers) opt back in with the "use client" directive, marking the server/client boundary. [react.dev — Server Components]

// Server Component (default) — runs on server, 0 KB to client
async function HotelPage({id}) {
  const hotel = await db.hotels.find(id);   // DB access, no API layer
  return <article>{hotel.name} <BookButton id={id} /></article>;
}

// BookButton.tsx
"use client"   // ← this island ships JS & hydrates; the rest doesn't

The payoff is less hydration → better TTI/INP, because most of the tree was never interactive to begin with. RSC is the architectural answer to the hydration tax in §3: don't make hydration faster — have less to hydrate.

5Partial Prerendering (PPR) — the synthesis

Everything above picks a strategy per route. But almost every real page is mixed: a hotel page is ~90% static (layout, description, photos, map) and ~10% dynamic-and-personal (live price, your loyalty discount, “3 people viewing”). The old choice forced a bad trade — render the whole page dynamic (lose the edge-cached static TTFB) or render it static and fetch the dynamic bits client-side (a request waterfall + a flash of empty price). PPR collapses the static-vs-dynamic decision from per-route to per-component, in one page and one HTTP response. [Next.js — PPR]

1. Build time: Next prerenders a static shell — everything outside a <Suspense> boundary.
2. The dynamic parts (inside <Suspense>, reading request data like cookies()/headers()/searchParams) are left as holes, with the fallback baked in.
3. Request time: the static shell ships instantly from the edge/CDN (great TTFB + FCP) and the dynamic holes are streamed into the same response as their data resolves.

export default function HotelPage() {
  return (<>
    <HotelHeader />                       // static → prerendered shell, edge-cached
    <Gallery />                           // static
    <Suspense fallback={<PriceSkeleton/>}>
      <LivePrice />                       // dynamic hole → streamed per request
    </Suspense>
  </>);
}

The model that makes it click: it's islands inverted. Lesson 10's islands are interactive islands in a static client page; PPR is dynamic holes in a static server page. The same <Suspense> boundary you know from streaming SSR (§3) now does double duty as the marker that separates static from dynamic. One response, static's TTFB and dynamic's freshness, no client waterfall — the clean version of the “ISR + streaming” hotel page in §6.

6The platform whiteboard — picking per surface

This is the deep-dive the panel flagged. Don't answer “use SSR.” Walk the surfaces of a hotel search/booking flow and assign each a strategy with a reason: [web.dev]

Then layer the cross-cutting concerns that make it a Lead answer: edge caching the logged-out HTML (Lesson 08), code-splitting per route (Lesson 05), i18n — locale routing + per-locale static/edge variants with hreflang, and a RUM guardrail on p75 LCP/INP across markets.

7Check yourself — scenario quiz

Pick an answer; instant feedback. Push-back style, like the round.