The rendering spectrum: Static, ISR, SSR, and Edge

Each point trades freshness for cost and speed differently — moving right means fresher data and more compute spent per request; moving left means cheaper, faster responses at the cost of staleness risk.

A statically generated page is rendered into plain HTML at build time, once, and every subsequent request simply serves that same HTML from the Edge Network's cache — the fastest possible option, and the cheapest, since no server-side work happens per request at all. The cost: the content is exactly as fresh as the last deployment, and nothing updates it until a new build runs.

Incremental Static Regeneration serves the cached static version instantly (same speed as pure Static Generation) but, after a configured time window, regenerates the page in the background on the next request — that request still gets the (slightly stale) cached version instantly, while the regeneration happens behind the scenes for the request after that. This is exactly the lazy-rendering pattern this very curriculum's own app uses for lesson pages, and exactly the mechanism behind this curriculum's own, real Vercel usage incident (lesson 11 covers it directly): every production deploy invalidates the ISR cache for every page built this way, so the next visitor to each page triggers a fresh, expensive regeneration — fine for occasional deploys, a genuine cost multiplier for frequent ones.

Server-Side Rendering re-runs the render on every request, guaranteeing the response always reflects current data — no staleness window at all — at the cost of real compute spent on every single request, with no caching benefit for that page's HTML. This is the right choice specifically for pages where "could be a few minutes stale" is genuinely unacceptable (a live dashboard showing real-time data, a page whose content depends on the specific logged-in user), and the wrong choice for anything that could tolerate ISR's staleness window, since SSR pays a real, ongoing cost for freshness many pages don't actually need.

Edge rendering runs the same "fresh on every request" model as SSR, but executes on Vercel's Edge Network (lesson 3) rather than in one fixed region — trading a more restricted runtime (lesson 5 covers exactly what that restriction means) for lower latency to users far from wherever a traditional server would otherwise be centrally located.

Choosing SSR for content that barely ever changes burns real, ongoing compute cost for freshness nobody needed. Choosing pure Static Generation for content that genuinely needs to reflect frequent updates serves stale data indefinitely until the next manual deploy. ISR sits in the middle specifically to avoid both failure modes — but, as this curriculum's own incident demonstrated, ISR's own cost (a regeneration storm across every page, triggered by every deploy) is real too, and choosing it correctly means understanding that cost, not just reaching for it as a safe default.