06 — Rendering Strategies — When and Where the HTML Is Made

The conceptual heart of Next.js flattened into one question for me. The model that finally tamed the acronym soup: every rendering strategy is just an answer to one question — when, and on which machine, does the HTML get generated? [1][2] The options are build time, request time, or in the browser. Everything else — SSR, SSG, CSR, SPA, ISR — is a label for a specific combination of those.

Once I stopped memorizing the acronyms and started asking "build, request, or browser?" the whole framework's rendering model became navigable.

The decision, on one axis

The roadmap's rendering-strategies node frames it cleanly: different strategies trade off performance, SEO, and data freshness, and choosing the right one depends on each page's content [1]. Here's the same trade-off as a timeline:

Static Site Generation (SSG)

SSG generates the HTML once, at build time [5]. When a user requests the page, the server hands back a pre-rendered file — no runtime work. This is the fastest possible strategy (CDN-cacheable, instant) and gives perfect SEO, at the cost of freshness: content goes stale until the next build. SSG is the right call for content that rarely changes — marketing pages, documentation, blog posts published in batches.

Server-Side Rendering (SSR)

SSR generates the HTML on the server per request [2][3]. The page is always fresh, SEO is good because real HTML reaches the crawler, but the server does work on every hit. SSR suits personalized or frequently-updated content where staleness is unacceptable — a logged-in dashboard, real-time data.

Client-Side Rendering (CSR) and SPA

CSR sends a minimal HTML shell from the server; the browser downloads JavaScript and renders the UI itself [4]. A SPA takes this to its conclusion — one HTML page, all rendering in-browser, navigation without reloads [3]. The trade-off: fluid UX after the initial load, but a slow first paint (nothing meaningful renders until JS runs) and poor SEO (the crawler sees an empty shell). CSR is the choice for highly interactive apps behind auth, where SEO doesn't matter and the initial load is a one-time cost.

Incremental Static Regeneration (ISR)

ISR is the hybrid that makes SSG viable for content that updates: the page is statically generated, but Next.js regenerates it in the background at a configurable interval or on-demand. Users see the cached version instantly; the next request after the interval triggers a fresh build. ISR is what lets a blog or news site stay mostly-static without rebuilding on every publish — the best of SSG's speed with something close to SSR's freshness.

The App Router's rendering model

In the App Router, the default is Server Components, which render on the server [6]. The framework decides per route whether it can be statically prerendered (no request-time data) or must render dynamically (uses request-time data like cookies or search params). This is sometimes called "static-first with dynamic when needed" — the compiler figures out the strategy from the code, rather than me declaring it per page. Partial Prerendering pushes this further by letting a single route mix a static shell with dynamic holes streamed in via Suspense, though it remains experimental [6].

Choosing per page

The whole point is that no single strategy is correct for an entire app. A typical Next.js site combines them:

• Marketing home → SSG (static, fast, SEO-critical).
• Blog post → SSG with ISR (static, but regenerates on edit).
• User dashboard → SSR (personalized, always fresh).
• In-app editor → CSR (highly interactive, behind auth).

How I use this

For every route I build, I ask the one question — when should this HTML be generated? If the content is the same for everyone and rarely changes, SSG. If it updates on a cadence, ISR. If it's personalized or real-time, SSR. If it's a behind-auth interactive surface, CSR. The framework lets me mix these per route, which is precisely its value over committing to one strategy globally.

References

[1] Vercel, "Rendering strategies," Next.js Learn, 2024. [Online]. Available: https://nextjs.org/learn/seo/rendering-strategies

[2] Vercel, "Server-side rendering (SSR)," Next.js Docs, 2024. [Online]. Available: https://nextjs.org/docs/pages/building-your-application/rendering/server-side-rendering

[3] "SSR vs. SPA showdown: choosing the right rendering approach for your web app," dev.to, 2024. [Online]. Available: https://dev.to/santhanam87/ssr-vs-spa-showdown-choosing-the-right-rendering-approach-for-your-web-app-4439

[4] Vercel, "Client-side rendering (CSR)," Next.js Docs, 2024. [Online]. Available: https://nextjs.org/docs/pages/building-your-application/rendering/client-side-rendering

[5] Vercel, "Static site generation (SSG)," Next.js Docs, 2024. [Online]. Available: https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation

[6] Vercel, "Partial prerendering," Next.js Docs, 2024. [Online]. Available: https://nextjs.org/docs/app/getting-started/partial-prerendering

[7] HybridHeroes, "Next.js rendering strategies: SSR, SSG, and ISR compared," 2023. [Online]. Available: https://hybridheroes.de/blog/2023-05-31-next-js-rendering-strategies/