Static Site Generation (SSG)
Pages are rendered once at build time into plain HTML files, then served straight from a CDN. No server work per visitor.
See it
What it is
At build time the generator renders every page once, fetches its data once, and writes plain HTML to disk. Requests then hit a file on a CDN edge, which is about as fast and as cheap as the web gets, and it stays up under a traffic spike because nothing is computing anything. Astro, Hugo, Eleventy, Next.js with generateStaticParams, and SvelteKit's prerender option all live here.
Right choice for anything identical for every visitor: marketing pages, docs, blogs, changelogs, glossaries. Interactivity is still on the table and it is opt-in: a static page can ship no script at all, or load JavaScript only for the parts that need it, on top of HTML that was already visible. For the few per-user pieces (a cart count, a greeting) fetch them in the browser after load or keep one small server-rendered region.
Two gotchas: freshness and build time. Content is frozen until the next build, so fixing a typo means a redeploy unless you wire a webhook from your CMS. And build time scales with page count, so ten thousand product pages can become a twenty minute build. That exact pain is why incremental static regeneration and on-demand rendering exist.
Ask AI for it
Prerender this route at build time as static HTML: enumerate every path up front from the data source, fetch each page's content during the build, and emit files servable from a CDN with long cache headers. Keep per-request and per-user data out of the page and move anything personalized to a client-side fetch after load. Add a webhook or scheduled rebuild so content edits ship without a manual deploy, and report the resulting page count and build time.