What is Static Site Generation (SSG)?

What is Static Site Generation (SSG)?

Static Site Generation (SSG) is the practice of pre-rendering an entire website's pages to plain HTML files at build time, then serving those files directly from a CDN with no runtime database queries or server-side rendering. The result: page-loads complete in tens of milliseconds because the server (the CDN edge) just hands over a finished HTML file. No backend logic runs per request. No database connection. No template engine. Just bytes in → bytes out.

SSG is one of three main rendering strategies for web pages. The others are SSR (Server-Side Rendering — HTML generated per-request on the server) and CSR (Client-Side Rendering — empty HTML shell with JavaScript that fetches and renders data in the browser). SSG sits at the fast-cheap-secure end of the spectrum: page-loads are unbeatably fast, hosting costs trend toward zero, and the attack surface is minimal because there's no runtime server logic to exploit.

How SSG works

The build step:

1. Source content lives in files. Markdown, YAML, JSON, or a headless CMS. Designers/writers edit content in a friendly format.
2. A build tool reads content + templates + data. Next.js, Astro, Hugo, Jekyll, Gatsby, 11ty, Nuxt — all compete in this space. The build tool merges templates with data to produce HTML.
3. Pages render to HTML files. One HTML file per URL. /blog/post-1.html, /products/widget-x.html, etc.
4. Output uploads to S3 / CDN. CloudFront, Cloudflare, Netlify, Vercel — the CDN serves the pre-built files.

The serve step (per-request):

1. Browser requests /blog/post-1.
2. CDN edge serves post-1.html. Cached at the nearest edge, 50 KB transferred, 10-50 ms total.
3. Page is interactive immediately. No waiting for backend round-trips. JavaScript hydrates if needed for interactivity.

When SSG is the right choice

• Marketing sites and blogs. Content updates are infrequent (daily at most). Build-once, serve-cheap fits the access pattern.
• Documentation sites. Stripe Docs, Tailwind Docs, Stack Overflow's documentation are all SSG. Search may use a separate API; the docs themselves are pre-rendered.
• E-commerce product catalogs (mostly). Product pages render once per build. Real-time data (inventory, pricing) loads via separate API calls. Major e-commerce sites use this hybrid pattern.
• SaaS landing pages. The marketing site is SSG; the app behind login is something else (SSR or CSR).
• Sites that prioritize Core Web Vitals. SSG produces the fastest LCP and TTFB possible. CrUX-driven SEO favors this.

Where SSG falls short

• Content that changes per-user. A logged-in dashboard with user-specific data can't be SSG (without dynamic client-side fetching). The marketing pages CAN be; the dashboard CAN'T.
• Real-time content (stock prices, live scores). SSG would require rebuilds every few seconds. Use SSR or client-side WebSockets instead.
• Very large sites with frequent updates. A site with 1 million pages where 10K change daily is hard to do as pure SSG — full rebuilds take too long. Incremental Static Regeneration (ISR — Next.js term) addresses this by rebuilding pages on-demand within a SLA.
• Search functionality. Static sites can't run server-side search; you'll need either a third-party search API (Algolia, Typesense) or client-side fuzzy search on a pre-built index.
• Forms and mutations. SSG can't accept form submissions directly. Pair with a separate form-handling API endpoint or use a service like Formspree.

The big SSG frameworks (2026 landscape)

• Next.js (React). Hybrid SSG/SSR. Most popular React-based framework. Vercel-native but works elsewhere. Heavy but feature-complete.
• Astro. Component-agnostic (React, Vue, Svelte all in one project). Ships zero JavaScript by default — exceptional Core Web Vitals out of the box.
• Hugo (Go). Compiled binary, incredibly fast builds (1000+ pages per second). Limited dynamic capabilities but unmatched build speed.
• 11ty (Eleventy, Node). Minimal, flexible. Popular for simple sites that don't need a JavaScript framework on the client.
• Gatsby (React). Mature, plugin-rich. Largely overtaken by Next.js but still maintained.
• Nuxt (Vue). Vue's answer to Next.js. SSG/SSR hybrid.
• Jekyll (Ruby). The original SSG. Powers GitHub Pages by default. Aging but still works.

SSG and Core Web Vitals

SSG produces the best CWV metrics on the market:

• LCP: Pre-rendered HTML + critical CSS inlined typically gives sub-1.5s LCP from any region with CDN coverage.
• FCP: Sub-1s in most cases. The HTML arrives in the first packet.
• CLS: Same constraints as any other rendering strategy — depends on the markup, not the build approach. SSG doesn't make CLS bad or good.
• INP: If the site is mostly static (no heavy JavaScript), INP is excellent. If the site uses heavy client-side hydration, INP can be the same as a CSR site.
• TTFB: Best in class. CDN-cached HTML serves in milliseconds, well under 200 ms even from distant regions.

FAQ: Static Site Generation

What's the difference between SSG and SSR?

Timing of HTML generation. SSG generates all pages at build time; SSR generates each page per-request on the server. SSG is faster (no per-request work) but stale (content fixed at build time). SSR is fresher (live data) but slower per request.

Can SSG sites be dynamic?

Yes — the static HTML can include JavaScript that fetches dynamic data after page load. The base content is pre-rendered (good for SEO), and dynamic features (cart count, personalization) load after. This is the dominant pattern for modern e-commerce.

What about SSG with millions of pages?

Build times become a problem. Solutions: Incremental Static Regeneration (Next.js) builds pages on first request and caches; distributed builds across CI workers (Vercel, Netlify); or accepting that some pages live as SSR while popular ones stay SSG.

Is SSG always faster than SSR?

For first byte and overall page load, almost always yes. For data freshness, no — SSR can show data updated seconds ago, SSG shows data from the last build. The right answer depends on your use case.

Does SSG work with personalization?

Yes, via client-side data loading. The shared HTML is SSG; user-specific elements (their name, their cart, their recommendations) load via JavaScript after page load. Same pattern as Stripe checkout pages, Notion docs, etc.

What's the catch with SSG?

Build times scale linearly with content size. Sites with 100K+ pages need careful build strategies. Content updates require a deploy (or ISR). And dynamic features (forms, search, comments) need separate infrastructure.

How LoadFocus measures SSG performance

LoadFocus runs Lighthouse-based speed tests from 25+ regions, capturing TTFB, LCP, INP, and CLS. SSG sites typically show in the top decile of CWV scores — but you should verify across regions because CDN coverage varies. Load testing with JMeter/k6 also confirms that your CDN handles spike traffic well — SSG with a strong CDN is one of the few stacks that handles 10x traffic spikes gracefully.