What Is Static Site Generation? HTML Built At Build Time

Static site generation (SSG) renders all your pages to HTML during the build, so a CDN can serve plain files with no server work per request.

Instead of rendering pages on every request like SSR, SSG renders them once at build time. The output is a folder of static HTML, CSS, JS, and assets that any CDN can serve. It is fast, cheap, and secure, and it maps cleanly onto a CI pipeline whose whole job is to turn source into deployable files.

How SSG works

During the build, the generator runs your page code for every route, fetches any needed data, and writes finished HTML to disk. There is no app server at runtime; the CDN just returns files.

SSG vs SSR

SSR renders per request, so content is always current but each request costs server time. SSG renders once at build, so serving is free and instant but content is frozen until the next build. SSG fits content that does not change every second.

Strengths of static output

Served by any CDN with no running server.
Very fast and cheap, with a tiny attack surface.
Trivially cacheable and globally distributable.

The freshness limit

Because pages are baked at build time, new content requires a rebuild and redeploy. For sites with thousands of pages, full rebuilds can get slow, which is exactly the problem incremental approaches address.

SSG in CI/CD

SSG is the most CI-native rendering mode: the pipeline runs the generator, produces a static folder, and uploads it to a CDN or static host. Build time grows with page count, so caching data fetches and only rebuilding changed pages keeps pipelines fast.

Key takeaways

SSG renders all pages to static HTML at build time, with no per-request server.
It is fast, cheap, and secure, but content is frozen until the next build.
It is the most CI-native mode: build to a folder, upload to a CDN.