Rendering Strategies Overview

Over the years, the React and Next.js ecosystem has accumulated several distinct rendering strategies, each solving a different trade-off between performance, freshness of data, and infrastructure cost. This lesson is a map of the territory before we go deep on each strategy individually.

The Strategies at a Glance

Strategy	One-line Description
SSR (Server-Side Rendering)	HTML is generated on the server for every single request.
SSG (Static Site Generation)	HTML is generated once at build time and reused for every request.
ISR (Incremental Static Regeneration)	Static HTML that automatically regenerates in the background after a set time interval.
CSR (Client-Side Rendering)	The browser downloads a mostly empty HTML shell and JavaScript builds the UI in the browser.
PPR (Partial Prerendering)	A single response mixes a static, prerendered shell with dynamic content streamed in around it.

Why So Many Strategies?

Every strategy answers the same underlying question differently: when is the HTML for this page actually created, and how often does that need to happen again? Content that never changes shouldn't be regenerated on every request; content that's personalized per-user can't be generated ahead of time at all.

Unchanging marketing pages, blog posts, docs -> SSG is nearly always the right default.
Content that changes periodically but doesn’t need to be instantaneous -> ISR.
Personalized dashboards, content behind auth, request-specific data -> SSR.
Highly interactive, client-heavy apps where SEO doesn’t matter -> CSR (often paired with SSR for the initial shell).
Pages that are mostly static but have one or two genuinely dynamic widgets -> PPR.

The App Router's Static vs Dynamic Mental Model

Note

The App Router mostly retires the old getStaticProps/getServerSideProps vocabulary in favor of a simpler mental model: each route is either static or dynamic, and Next.js determines this automatically based on what the route actually does — whether it reads cookies or headers, uses a dynamic function like searchParams, or calls fetch with caching disabled. You opt into dynamic behavior implicitly, by using dynamic APIs, rather than choosing a data-fetching function name up front.

How This Maps to the Old Names

Pages Router Concept	App Router Equivalent
getStaticProps	A Server Component with no dynamic data sources (static by default)
getServerSideProps	A Server Component that reads cookies/headers, or uses no-store fetch
getStaticPaths	generateStaticParams()
Incremental Static Regeneration config (revalidate)	The revalidate export or the revalidate option on fetch

Tip

Default to letting Next.js infer static vs dynamic automatically. Reach for explicit controls — the revalidate export, dynamic = 'force-dynamic', or PPR — only once you understand why the default behavior isn't giving you what you want.

The next several lessons walk through SSR and SSG in detail — the two foundational strategies that most routes ultimately fall into — before we revisit ISR, CSR, and PPR with the same depth.