Glossary
SSR vs SSG
Server-Side Rendering (SSR) generates HTML per-request; Static Site Generation (SSG) generates HTML once at build time. Both render server-side but at different moments.
Server-Side Rendering (SSR) builds the HTML for a page every time a user requests it. The server runs the rendering logic (React components, template logic, data fetches), sends fully-formed HTML to the browser. Examples: Next.js getServerSideProps / server components without static caching, Remix loaders, SvelteKit page server logic.
Static Site Generation (SSG) builds the HTML for every page once, at deploy time. Every visitor gets the same pre-built HTML from a CDN. Examples: Next.js generateStaticParams / static export, Astro's default, Hugo, Jekyll. The HTML is identical for every request, which makes it cacheable everywhere.
ISR (Incremental Static Regeneration) is a hybrid: pages are statically generated but can be regenerated on a stale interval or on-demand via API. Next.js popularized the pattern. ISR lets a 50K-page site stay mostly static while allowing per-page updates without a full rebuild.
Trade-offs: SSR handles user-specific or rapidly-changing data (dashboards, real-time feeds); SSG handles content that doesn't change per-request (marketing pages, blogs, documentation). SSR adds latency (the request waits for the server to render); SSG is near-zero latency (CDN-served). SSR scales linearly with traffic (more requests = more compute); SSG scales free (CDN-cacheable).
For marketing sites, SSG (or ISR for content-heavy sites) is the right default. SSR is for app-like surfaces with per-user data. The choice is per-route, not per-site: Next.js apps commonly mix SSG for marketing pages, ISR for blog posts, and SSR for the user dashboard — all in the same codebase.
Example
A typical Next.js marketing site uses SSG for /, /pricing, /about (built once, served from CDN), ISR for /blog/[slug] (built once, regenerated every hour or on push), and SSR for /dashboard (rendered per-request with the user's session data).