What Is Static Site Generation (SSG)?

What is static site generation (SSG)?

Static site generation (SSG) is a rendering approach where a build step turns your content and templates into plain HTML files ahead of time. Those files are uploaded to a host or CDN and served as they are, so no code or database query runs when a visitor requests a page. It is one of several web rendering strategies.

How SSG works

1. Content lives in source files or a CMS. Markdown, JSON, YAML or a headless CMS API.
2. A build tool combines content, templates and data. It writes one HTML file per URL, plus CSS, JavaScript and images.
3. The output is deployed. The files go to object storage or a static host, usually behind a CDN.
4. Each request is a file read. The edge returns the prebuilt file, so the time to first byte is mostly network distance.

Frameworks such as Astro, Hugo, Eleventy, Jekyll, Next.js and Nuxt can all produce static output. Astro, for example, renders components to HTML and CSS and ships JavaScript only for the parts you mark as interactive, according to its islands documentation. In Next.js, setting output: 'export' makes next build write a static folder of HTML, CSS and JavaScript.

When SSG is the right choice

• Marketing sites, blogs and documentation: content changes on a publishing schedule, not per visitor.
• Landing pages that must be fast: prebuilt HTML from a CDN is the shortest path to the first byte.
• Catalog or listing pages with a client-side price or stock call: the shell is static and a small API request fills in live data.
• Sites that need cheap, simple hosting: a static host has no application server to patch or scale.

Where SSG falls short

• Per-user content. A logged-in dashboard cannot be prebuilt for every user. Use server-side rendering or fetch data in the browser.
• Live data. Scores or stock levels that change every few seconds need SSR or a client-side request.
• Very large, fast-changing sites. Rebuilding thousands of pages for every edit gets slow. Incremental static regeneration rebuilds only the pages that changed.
• Server features. Static export has no request-time logic. Next.js lists cookies, redirects, rewrites, headers, server actions and ISR as unsupported with output: 'export', so handle those at the host or CDN.

Example: a documentation site

A docs site has 400 Markdown pages. The build converts them to 400 HTML files in a few seconds to minutes, a CI job uploads them to storage, and the CDN caches them worldwide. When a writer fixes a typo, the pipeline rebuilds and redeploys, and the CDN cache is purged for the changed paths. Search runs through a prebuilt index in the browser or a hosted search API.

Common mistakes

• Forgetting to invalidate the CDN cache after a deploy, so visitors keep seeing the old page.
• Calling a slow third-party API at build time with no timeout, so one outage fails the whole build.
• Treating static as secure by default: the hosting, forms and any APIs still need protecting.
• Loading large client bundles on a static page and losing the speed advantage.
• Hard-coding data that should be fetched at request time, such as prices.

SSG, performance testing and monitoring

Static pages remove most backend variability, so the numbers you watch are CDN cache hit rate, time to first byte from different regions and the size of what you ship. Track page speed and Core Web Vitals after every deploy with LoadFocus Page Speed Monitoring, which runs scheduled Lighthouse audits from 25 cloud regions. The page speed tips article covers the front-end work that still matters on a static site.

If a static site calls APIs for search, forms or live data, those endpoints are where load shows up. Run a load test against them before a traffic spike.

FAQ: static site generation

What is the difference between SSG and SSR?

Timing. SSG builds the HTML once, before any visitor arrives. SSR builds it on the server for every request. SSG is cheaper and faster to serve, SSR can show per-request or live data.

Is a static site the same as a website with no JavaScript?

No. A static site can still run JavaScript in the browser for menus, search or widgets. Static means the HTML is prebuilt, not that the page is non-interactive.

Is SSG good for SEO?

Yes. Crawlers receive complete HTML straight away, and fast pages help Core Web Vitals. SSG does not rank a page by itself, though: content quality and links still decide that.

How do I update content on a static site?

Change the source, run the build and deploy the new files. Most hosts and CI systems can do this automatically on every commit or when your CMS publishes. For very large sites, incremental regeneration rebuilds only what changed.

Can a static site have forms, search or logins?

Yes, by calling APIs from the browser or using hosted services for forms and search. The page itself stays static while the dynamic part runs elsewhere.