A Next.js App Router app has three pages: a marketing landing page, a news index that must be at most a minute out of date, and a signed-in account dashboard. Which rendering mode would you choose for each, and what drives each decision?

## The decision procedure Interviewers hand you page descriptions because they want the reasoning, not a recital of three mode names. A defensible answer runs a short decision procedure and says out loud what each step rules out. **Question 1 — does the output depend on this request?** If the HTML must differ per user, per cookie, per geo, or per search parameter, no amount of caching helps: there is no single correct document to store. That route renders per request. This is the only hard constraint in the list; the rest are tradeoffs. **Question 2 — how stale may it be?** For request-independent pages, staleness is a product decision measured in time. "Only changes at deploy" points at a plain build-time prerender. "Changes constantly but a minute of lag is fine" points at a prerender with a revalidation window. "Must be correct to the second" pushes you back to per-request rendering even though the page is the same for everybody. **Question 3 — does the URL space fit in a build?** A route with a bounded, known set of URLs can be fully prerendered. A route with a very large or unknowable set has to prerender a subset, or nothing, and fill in the rest later. ## Applying it to the three pages ### Marketing landing page Same for every visitor, changes when marketing ships new copy, and it is the page most likely to be hit by a traffic spike from a campaign. Prerender it at build. The output is a file, so a spike costs you nothing, the page survives an outage of whatever CMS produced it, and time to first byte is delivery latency. The cost is that a copy change requires a rebuild or an explicit invalidation — acceptable, because copy changes are already tied to a deploy workflow. ### News index Also identical for every visitor — everyone sees the same headline list — so it is not a dynamic page. But it changes many times an hour, and rebuilding the site per story is absurd. This is exactly what incremental regeneration exists for: prerender it, attach a revalidation window of about 60 seconds, and let the first request after the window expires trigger a background regeneration while the visitor still gets an instant response. You keep the static-file economics and bound your staleness to roughly the window length. ```tsx // app/news/page.tsx export const revalidate = 60 // regenerate at most about once a minute export default async function NewsIndex() { const stories = await getTopStories() return <StoryList stories={stories} /> } ``` ### Account dashboard The content is the signed-in user's own data. There is no shared document to cache, and caching one by accident is a security incident, not a performance bug. Render per request. Accept the server cost and the upstream latency, and if the page feels slow, the fix is not a different mode — it is streaming the slow parts so the shell arrives early, or moving work off the critical path. ## Saying the tradeoffs, not just the verdicts What separates a middle answer from a junior one is naming what each choice costs. - **Build-time prerender**: cheapest per request, best time to first byte, immune to upstream outages at serve time — but the data ages until a rebuild, and the build itself grows with the number of pages. - **Revalidated prerender**: nearly the same economics, with staleness bounded by the window instead of by the deploy cadence — but somebody is always seeing a page up to one window old, and you must decide whether that is acceptable for this content. - **Per-request render**: always correct, can personalize — but every visit costs a server invocation, your time to first byte inherits the slowest upstream call, and a traffic spike hits your backend directly rather than a cache. ## Common traps The two failure modes are symmetrical. Making everything dynamic "to be safe" throws away the cheapest, most resilient tier for pages that never needed it. Making something static that is actually request-dependent is worse: it risks one user's page being served to another. When in doubt, prove the page is identical for all visitors before you make it static, and prove staleness is intolerable before you make it dynamic. Finally, note that the choice is per route. A single app happily mixes all three, and a good answer says so explicitly rather than picking one mode for the application.