SSG, short for static site generation, is a rendering approach in which every page of a website or web application is rendered to complete HTML files at build time, before any user requests it. The resulting files are deployed to a web server or content delivery network and served as they are, without running application code for each visit.
Among web applications, SSG sits at one end of the rendering spectrum, opposite client-side rendering and alongside SSR, server-side rendering. It offers very fast delivery, high resilience and a small attack surface, at the cost of content that is only as fresh as the last build.
How static site generation works
A static site generator runs a build step that combines three inputs: templates or components, content from Markdown files, a headless CMS or an API, and configuration such as routes and metadata. For each route, the generator renders the final HTML, along with the CSS, JavaScript and optimized images the page needs.
The output is a folder of static files that can be hosted almost anywhere. Because the HTML already exists, the server or CDN only has to return a file, which keeps response times low and predictable. When content changes, the site is rebuilt and redeployed, usually triggered automatically by a content update or a code commit.
| Stage | What happens | Typical output |
|---|---|---|
| Data fetching | Content loaded from files, CMS or APIs | Structured page data |
| Route generation | List of all pages determined | One entry per URL |
| Rendering | Templates or components turned into HTML | One HTML file per route |
| Asset processing | Bundling, minifying, image optimization | Hashed CSS, JS and image files |
| Deployment | Files uploaded to hosting or CDN | Globally cached static site |
SSG compared with other rendering strategies
The defining question for any rendering strategy is when the HTML is produced. SSG produces it once at build time, SSR on every request and client-side rendering in the user’s browser.
| Strategy | When HTML is produced | Content freshness | Server cost per request |
|---|---|---|---|
| SSG | At build time | As of last build | Minimal, file delivery only |
| Incremental regeneration | At build time, refreshed in the background | Minutes or on demand | Low |
| SSR | On each request | Always current | Higher, rendering each time |
| Client-side rendering | In the browser after JavaScript loads | Always current | Low for HTML, API calls remain |
| Hybrid per route | Chosen route by route | Varies by page | Varies by page |
SSG and SSR both send complete HTML to the browser, which benefits search engines and the first contentful paint. Interactive parts of a statically generated page still need hydration, in which JavaScript attaches behavior to the existing markup, so SSG pages can behave like an SPA once loaded.
When SSG is the right choice
SSG fits best when the same content is shown to every visitor and changes less often than it is viewed. Documentation, marketing sites, blogs and product catalogs with moderate update frequency are typical candidates.
| Situation | Recommended approach | Reason |
|---|---|---|
| Documentation or blog | Pure SSG | Content changes rarely and is public |
| Marketing site with campaigns | SSG with rebuild on CMS publish | Fast pages, editors control timing |
| Catalog with tens of thousands of pages | SSG with incremental regeneration | Full rebuilds become too slow |
| Prices or stock that change by the minute | SSG shell with client or server data | Static HTML would go stale |
| Personalized dashboards | SSR or client-side rendering | Content differs per user |
| Content behind login | SSR or client-side rendering | Static files cannot vary by session |
Benefits and trade-offs of SSG
The main benefits come from removing work from the request path. Static files served from a CDN typically reach a low TTFB worldwide, there is no application server or database to overload during traffic spikes, and the attack surface shrinks because no server-side code runs per request.
The trade-offs are build time and freshness. A site with hundreds of thousands of pages can take many minutes or longer to build, and every content change waits for the next deployment. Frameworks address this with incremental static regeneration or on-demand revalidation, which rebuild only affected pages.
| Problem | Cause | Fix |
|---|---|---|
| Builds take too long | Every page rebuilt on each change | Incremental or on-demand regeneration |
| Editors see changes late | Rebuild only on code deploys | Webhook from CMS triggers a build |
| Outdated data on pages | Volatile data baked into HTML | Fetch volatile parts at runtime |
| Large JavaScript bundles | Whole page hydrated | Partial hydration or islands architecture |
Common misconceptions about SSG
- Static does not mean non-interactive: statically generated pages can include forms, search and rich client-side features.
- SSG is not only for small sites: with incremental builds, large catalogs and documentation portals use it successfully.
- SSG does not remove the need for an API: dynamic features such as comments or checkout still call server endpoints.
- Static HTML is not automatically fast: heavy images and scripts can still produce poor LCP and INP values.
The simple explanation
With SSG, a website’s pages are prepared in advance. Instead of building each page at the moment someone visits, the system builds all of them once and stores them as finished files.
It is like a bakery that bakes bread early in the morning instead of starting the oven only when a customer walks in. Customers get their bread immediately, and the shop never gets overwhelmed at rush hour. The downside is that changes need a new batch: if the recipe changes, the bread on the shelf stays the same until the next baking.
How it is used in practice
A software company maintains developer documentation with about 3,000 pages written in Markdown. The previous setup rendered each page from a database on request, and response times rose sharply whenever a new release brought a wave of visitors.
The team moves the documentation to static site generation. Every merge to the main branch triggers a build of roughly four minutes, and the output is deployed to a CDN. The search feature calls a separate API, and code examples remain interactive through hydration. After the change, pages load quickly from edge locations worldwide, release-day traffic spikes cause no server incidents, and hosting costs fall because no application server is needed for the documentation.