What is Static Site Generation (SSG)?

What is Static Site Generation (SSG)?

Static Site Generation (SSG) is where you build HTML pages once, at build time, then serve them from a CDN until you build again. Your build process runs templates against data sources — CMS, markdown files, APIs — and spits out plain HTML, CSS, and JavaScript. No server renders anything at request time. Just static files on a CDN.

This is why SSG sites hit TTFB under 100ms globally. We've measured 47ms average on Vercel's Edge Network. Google's "good" threshold is 800ms. You're beating that by 8x.

The technique isn't new. Jekyll shipped in 2008. But Gatsby, Hugo, and later Next.js and Astro turned it into the default for content sites. We've shipped SSG on 50+ projects at Social Animal. It's our starting point for any site where content updates are measured in hours, not seconds — marketing pages, docs, blogs.

How it works

Three phases: fetch data, render templates, deploy to CDN.

1. Data fetching at build time

Your framework pulls content from whatever you've wired up. Headless CMS like Sanity or Contentful, local markdown, a database, external APIs. In Next.js (App Router, v14+), you export generateStaticParams:

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await fetchAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await fetchPost(params.slug);
  return <Article content={post} />;
}

In Astro, every .astro page is static by default. You have to opt into server rendering.

2. Template rendering

The framework executes each page's component tree, resolves all data dependencies, writes fully-formed HTML to a build output directory (.next/ or dist/). No server-side logic remains.

3. Deployment to CDN

You push the output directory to Vercel Edge Network, Cloudflare Pages, Netlify. Every request hits a cached file. No cold starts. No compute costs per request. No database connections.

The trade-off is build time. A 10,000-page site can take several minutes. That's where Incremental Static Regeneration (ISR) and on-demand revalidation come in — you update individual pages without rebuilding everything.

When to use it

SSG works for more use cases than people assume. Here's our decision framework:

Use SSG when:

• Content changes infrequently (blogs, docs, landing pages, marketing sites)
• You need maximum performance and lowest possible TTFB
• SEO is critical and you want guaranteed crawlable HTML
• You want near-zero hosting costs (CDN-only serving)
• Security matters — there's no server to attack at runtime

Don't use SSG when:

• Content is user-specific or requires authentication for the initial render
• You have millions of pages and build times become unacceptable (though ISR helps)
• Data changes every few seconds (stock tickers, live scores)
• You need request-time logic like A/B testing at the HTML level (edge runtime is better)

Our stack at Social Animal: Astro for pure content sites. Next.js App Router when we need a mix of static and dynamic pages in the same project.

Static Site Generation vs alternatives

SSG and ISR are closely related. ISR is SSG with a cache revalidation layer. The jump from SSG to SSR is where you pay the real performance and cost penalty. For most content websites, SSG or ISR covers 90%+ of pages.

Real-world example

We built a SaaS documentation site with 1,200 pages using Astro 4 and Starlight. Full build: 38 seconds on Vercel's infrastructure. Every page scores 99-100 on Lighthouse Performance. TTFB averages 47ms globally.

The content team edits markdown in GitHub. A push to main triggers a rebuild. The whole thing deploys in under 2 minutes. Monthly hosting cost: $0 on Vercel's free tier.

Compare that to server-rendered equivalent. You'd need persistent compute, cold start mitigation, database connections. For content that updates a few times per week, SSG is the obvious answer.