Rendering Strategy
also called SSR, CSR, SSG, ISR
The decision about where and when HTML is produced — build time, server request time, or in the browser — which drives performance, cost and complexity.
Four strategies, and the choice is per route rather than per application, which is the point most teams miss when they adopt one framework setting globally.
Static generation renders at build time. Fastest possible delivery, trivially cacheable at the edge, and unable to show anything personalised or fresher than the last build. Server-side rendering renders per request: fresh, personalised, indexable, and it puts compute in the request path with the cost and latency that implies. Client-side rendering ships a shell and fetches data in the browser: cheap to serve, excellent for highly interactive authenticated applications, and it pays a blank-screen penalty and a search indexing penalty. Incremental regeneration serves static content and refreshes it in the background on a cadence, which covers the large middle ground of content that changes but not per user.
The mapping that usually falls out: marketing and content pages static or incrementally regenerated, catalogue and search server-rendered for indexing and freshness, and authenticated application interiors client-rendered because they are neither indexed nor cacheable.
The question that settles most arguments: is this page indexed by search engines, is it personalised, and how stale may it be? Those three answers pick the strategy without further debate.