Static Site Generation (SSG)

With SSG, the work of building a page happens once, when you deploy, not every time someone visits. A build process runs your templates and data through a generator, and the output is a folder of static files: one HTML file per route, plus the CSS, JavaScript, and images they need.

Compare this to the two alternatives. Server-side rendering (SSR) builds the HTML on the server for every single request, so it can show the latest data but adds compute and latency to each visit. Client-side rendering (CSR) ships an empty HTML shell and a JavaScript bundle that fetches data and draws the page in the browser, which delays the first meaningful paint. SSG sidesteps both by having the finished page ready before anyone asks for it.

The catch is that the content is frozen at build time. If your data changes, you have to rebuild and redeploy, or use a hybrid approach that re-renders specific pages on a schedule or on demand.

A static site generator runs in three steps. First it loads your content, which can be Markdown files, MDX, JSON, or data pulled from a headless CMS or an API. Second it passes that content through page templates or React components to produce HTML strings. Third it writes those strings to disk as .html files, alongside a manifest of assets.

Frameworks like Next.js and Astro let you control which pages get generated. In Next.js you export a function such as generateStaticParams that returns the list of dynamic routes, for example every blog slug or every product id, and the build loops over that list and emits one HTML file per entry. A site with 754 pages produces 754 HTML files in a single build.

Because the output is just files, deployment is trivial. You upload the folder to a CDN such as Cloudflare, Vercel's edge network, or Amazon CloudFront backed by S3. The CDN caches every file at edge locations near users, so a request in Tokyo is served from a Tokyo node without ever reaching your origin. Time to first byte typically lands under 100ms because there is nothing to compute.

SSG is the right call for content that changes rarely and is the same for every visitor: marketing pages, documentation, blogs, course material, and product catalogs. These benefit most from the speed, the low cost, and the strong SEO that comes from shipping complete HTML that crawlers can read without running JavaScript.

It is a poor fit for highly personalized or real-time content. A user dashboard, a stock ticker, or a shopping cart that differs per session cannot be baked in at build time. For those you reach for SSR or CSR, or you statically generate the shell and hydrate the dynamic parts on the client.

The main trade-off is build time and staleness. A site with tens of thousands of pages can take many minutes to build, and any content edit means a rebuild. Modern frameworks soften this with Incremental Static Regeneration, where a page is generated on the first request after its cache window expires and then served statically again, so you get fresh content without rebuilding the whole site.

Consider a documentation site with 500 articles written in Markdown. At build time the generator reads all 500 files, renders each through a shared layout, and writes 500 HTML files plus a search index. The whole build might take 90 seconds and run once per content update in CI.

When a reader opens an article, the CDN returns the prebuilt HTML in tens of milliseconds. There is no database, no server process, and no cold start. The same setup serves ten readers or ten million readers at nearly the same cost, because the CDN absorbs the traffic and the origin is barely touched.

This is exactly why developer docs, learning platforms, and JAMstack sites lean on SSG. You trade a little build complexity and the need to redeploy on changes for pages that are fast, cheap to host, resilient to traffic spikes, and easy for search engines to index.