Static Site Generation (SSG)

What is static site generation?

Static site generation (SSG) pre-renders an entire website into static HTML files at build time, so that serving a page is just handing out a pre-built file — no server-side computation per request. A build step runs your framework and content through a generator, produces finished HTML (plus CSS/JS), and you deploy those files to a CDN or static host. Because there’s nothing to compute when a request arrives, SSG delivers the fastest, cheapest, and most secure way to serve content that doesn’t need to change on every request. It’s one point on the rendering spectrum alongside server-side rendering (SSR) and client-side rendering.

Why it’s fast, cheap, and secure — and the catch

The three benefits follow directly from “it’s just files.” Fast: static files served from a CDN edge are about as fast as the web gets — no origin server rendering, no database round-trips, cacheable everywhere, excellent Core Web Vitals. Cheap: serving static files costs a fraction of running application servers; there’s no per-request compute to pay for and it scales trivially under traffic spikes (a CDN serving files barely notices a traffic surge that would melt an SSR origin). Secure: with no server-side execution and no database in the request path, the attack surface is minimal — there’s little to inject into or exploit. The catch is the defining constraint: content is fixed at build time, so anything that must be dynamic or personalized per request doesn’t fit pure SSG. Truly dynamic, per-user, or frequently-changing data needs SSR, client-side fetching, or a hybrid. And the second catch scales with size: because the whole site is built up front, build times grow with the number of pages — a site with hundreds of thousands of pages can take a long, painful time to rebuild on every change, which is a real operational pain point for large content sites.

Where it fits, and the modern hybrids that fix its limits

SSG is the ideal choice for content-driven sites that don’t change per request: blogs, documentation, marketing sites, landing pages, portfolios, and any mostly-static content — this is the heart of the Jamstack approach. The dynamic bits (search, comments, forms) are handled with client-side JavaScript calling APIs or serverless functions, keeping the pages themselves static. Importantly, the old “static = can’t be dynamic” limitation has been substantially eroded by hybrid strategies: Incremental Static Regeneration (ISR) serves static pages but regenerates them in the background on a schedule or on-demand, so content stays fresh without a full rebuild; and modern frameworks (Next.js, Astro, Nuxt, SvelteKit, Gatsby, Hugo) let you choose SSG, SSR, or ISR per route, so a single site can be mostly static with a few dynamic pages. The practical guidance: default to SSG for content that can be static (you get speed, cost, and security nearly for free), reach for ISR when static content needs periodic freshness, and use SSR only for the genuinely per-request-dynamic pages. The common mistakes are forcing SSG onto highly dynamic apps (fighting the model) and ignoring build-time cost on very large sites (where incremental/on-demand builds become necessary).

What people get wrong

• Using pure SSG for highly dynamic content — content is frozen at build time; per-user or frequently-changing data needs ISR, SSR, or client-side fetching.
• Ignoring build-time scaling: rebuilding hundreds of thousands of pages on every change is slow — large sites need incremental or on-demand regeneration.
• Assuming static means no interactivity — static pages happily run client-side JS calling APIs/serverless for search, forms, and dynamic features (the Jamstack pattern).

Primary source: Astro: Rendering modes (static/SSG)