Rendering Strategy as a System Design Decision

The plain-language idea

The Frontend Practices track's rendering-strategies lesson already covers what SSR, SSG, and CSR mechanically are — the server, the build step, and the browser doing the rendering work respectively. This lesson assumes that's known and focuses on something different: choosing between them as part of a system design answer, for a specific prompt, from a specific set of requirements — not from framework habit or personal preference.

Three questions do almost all of the work in that choice:

• Does this page need to rank in search results? If yes, a crawler needs real content in the initial HTML — that rules out pure CSR and points toward SSR or SSG.
• Is the content the same for every visitor, or personalized per user? Content that's identical for everyone can be built once (SSG); content that depends on who's asking (a logged-in dashboard, a personalized feed) has to be generated per-request (SSR) or fetched client-side after load (CSR).
• How interactive does the page need to be, and how soon? A page that's mostly static text with light interactivity tolerates any strategy; a page that's essentially an application (drag-and-drop, real-time updates, heavy client state) leans CSR for the interactive parts regardless of how the initial shell was rendered.

See it in a real thing: two prompts, worked through the same framework

Prompt one: an e-commerce product listing page. It needs to rank in search ("running shoes size 10" should find this page), and its content — prices, descriptions, stock status — is the same for every visitor at a given moment, not personalized per user. That combination points at SSG with periodic regeneration (or SSR if prices change too often for a build-time snapshot to stay accurate): crawlers get real HTML immediately, and there's no per-user reason it needs to be computed fresh on every single request.

Prompt two: an internal analytics dashboard. It's behind a login, never indexed by a search crawler, and every user sees data scoped to their own account, their own filters, their own date range — content that's fundamentally personalized and interactive, not something that could be built once and served to everyone. SEO is entirely irrelevant here, which removes the main reason to reach for SSR or SSG in the first place; CSR is the sensible default; the login gate itself already means no crawler will ever see this content regardless of rendering strategy.

Naming why each answer follows from the requirements — not just stating the answer — is what a strong response sounds like: "this page needs to be crawlable and isn't personalized, so SSG fits" is a complete piece of reasoning; "I'd use Next.js SSR for everything" is a framework habit, not a decision.

What people usually miss

Watch out

• "Which one is fastest" is the wrong first question. SEO need, personalization, and interactivity determine which strategies are even viable candidates; raw speed is a tiebreaker among the viable ones, not the starting filter.
• A login gate is itself a strong signal. If a page is never reachable by an unauthenticated crawler, the SEO argument for SSR/SSG disappears entirely — that's often reason enough to default to CSR for logged-in, personalized surfaces.
• Personalization is what actually rules out SSG, not just "the content changes." Content that changes over time but is the same for every visitor (a product's price updating daily) can still work with SSG plus regeneration; content that differs per visitor at the same moment is the real SSG blocker.
• Defaulting to one strategy for an entire application is a common shortcut that a strong answer avoids — naming which pages get which strategy, and why each one differs, is the actual signal this prompt is testing for.

Why this matters in interviews

A prompt like "how would you render this page" is testing whether a candidate can translate specific product requirements (crawlability, personalization, interactivity) into a rendering choice and explain the reasoning — not just recite what SSR, SSG, and CSR are.