2.19 — Quick Revision: Rendering Strategies

<< 2.19 Overview

---

One diagram

        SSR                 SSG                ISR
request-time HTML    build-time HTML     cached HTML + refresh
higher origin cost   lowest read cost    middle ground
best freshness*      worst freshness*    bounded staleness
(*for first paint snapshot; client can still update after)

---

2.19.a — SSR (essence)

• Goal: HTML reflects current server-visible data at request time.
• Cost: Origin CPU/IO per visit; TTFB sensitive to waterfalls.
• Mitigations: parallelize IO, indexes, caching where safe, Suspense streaming.

---

2.19.b — SSG (essence)

• Goal: Prebuilt HTML served from CDN/static—cheap reads, great TTFB.
• Risk: Stale public content; never accidentally statically optimize personalized secret pages.

---

2.19.c — ISR (essence)

• Goal: Static delivery + controlled refresh (time-based + on-demand).
• Product language: “Instant for users, bounded staleness, editors can push.”
• Failure modes: missed webhooks, wrong tags/paths, CDN caches longer than expected.

---

App Router memory hooks

• Dynamic signals: cookies(), headers(), searchParams in some patterns, no-store fetch, unstable_noStore() (per version docs)…
• Static paths: generateStaticParams + no accidental dynamic APIs.
• Invalidate: revalidatePath, revalidateTag after mutations or CMS events.

---

Pick in 10 seconds

Signal	Lean
Heavy SEO + volatile data	SSR (or RSC dynamic)
Rarely changing marketing	SSG
Mostly static, editors publish hourly	ISR + on-demand
Auth-only, no SEO	CSR or light SSR shell

---

Self-check: spoken answers

#	Prompt	Answer you should produce
1	Define SSR in one line.	HTML is produced on each request (or dynamic segment) so first paint can include fresh server data—better SEO, higher origin cost.
2	Define SSG in one line.	HTML is generated at build/prerender time and served as static assets—fast and cheap, poor freshness unless rebuilt or augmented.
3	What does ISR buy you?	Mostly-static performance with periodic or on-demand regeneration instead of full rebuilds.
4	Why does SSR raise TTFB risk?	All server work sits on the critical path to first byte unless streamed or optimized.
5	When is ISR wrong?	When any stale snapshot is unacceptable for compliance or pricing truth.
6	App Router static vs dynamic?	Inferred from dynamic APIs + caching; confirm via next build diagnostics.
7	Path vs tag revalidation?	Paths target URL trees; tags target shared data dependencies across routes.
8	Why streaming?	Improves perceived speed by sending ready regions earlier.

---

<< 2.19 Overview