Comparisons
Pairs that get conflated in real conversations, and in real pull requests. Neither column wins — what decides is the requirement. Each record leads with the confusion, because the confusion is the reason the record exists.
Server-side rendering vs Static generation
The pair is treated as a performance choice when it is a freshness-and-personalisation choice with performance as a consequence. Pre-rendered HTML on a CDN is close to the fastest thing the web can do — it is a cached file served from near the user, with no server render and no origin round trip — so if the content permits it, SSG wins on delivery without any cleverness. The real question is what happens when the content changes: SSR is fresh by construction and pays a render per request, while SSG is stale until something rebuilds it, and the rebuild time scales with the number of pages. Incremental strategies blur the line by rebuilding pages lazily on request, which is genuinely useful and genuinely harder to reason about, because a given user may be served the previous version while the new one is generated.
Content that differs per visitor or changes faster than you can rebuild: dashboards, personalised feeds, anything reflecting a write that just happened.
Content that is the same for everyone and changes on a human timescale: documentation, marketing, blog posts, catalogues that a build or an incremental revalidation can keep current.
| Dimension | SSR — HTML built per request | SSG — HTML built once, at deploy or on a schedule |
|---|---|---|
| Rendered | Per request | At build time (or lazily, once, on first request) |
| Freshness | Always current | As current as the last build or revalidation |
| Personalisation | Natural — the request has the user on it | Not in the HTML; anything per-user comes after, on the client |
| Delivery | Origin or edge render, then transfer | A static file from a CDN edge |
| Scaling | Cost grows with traffic | Cost grows with the number of pages, not with traffic |
| Failure mode | Slow or failing origin becomes a slow or failing page | Stale content nobody noticed, or a build that takes an hour |
| Rebuild story | None needed | A deploy, a webhook, or incremental revalidation with its own staleness window |