How it works
At build time the framework fetches the data (from Markdown files, a CMS or an API), renders every page and writes out HTML, CSS and JavaScript files. Those files go to a CDN, which serves them from a location near each visitor with no server work per request. Astro, Next.js, Nuxt, SvelteKit, Hugo and Eleventy can all do this.
The catch is freshness: a change goes live only after a rebuild, and sites with tens of thousands of pages can take a long time to build. Incremental static regeneration and on-demand revalidation solve much of that. Interactive parts such as search or a basket still work through JavaScript and APIs.
Static site generation (SSG) pros and cons
Pros
- Very fast pages, served straight from a CDN
- Cheap or free hosting, with very little that can break
- Strong for SEO and Core Web Vitals
- Small attack surface, since no live server code runs
Cons
- Content updates need a rebuild and a redeploy
- Build times grow with the number of pages
- Per-visitor content needs extra client-side code
When to use Static site generation (SSG)
Pick it when
- Marketing sites, blogs, docs and portfolios
- Content that changes daily or less often
- Landing pages that must load quickly everywhere
Skip it when
- Pages that differ for every visitor or change every minute
- Very large catalogues where full rebuilds take too long (consider ISR)
Static site generation (SSG) vs the alternatives
Related terms
More in Rendering and architecture
Where pages are built