LearnAI ToolsCareerPractice BuildsPlayContact
Lesson 2617 min read

Static Site Generation (SSG)

Generate HTML once at build time for pages whose content does not depend on the individual request.

How Static Generation Works

When you run next build, Next.js renders every eligible route to plain HTML once, ahead of time. That HTML can then be served instantly from a CDN edge location, with no server computation needed per visitor.

npm run build runs
↓
Next.js renders eligible pages to HTML
↓
HTML + data are cached
↓
Every visitor gets the same pre-built HTML instantly

A Static Page

A page becomes static automatically as long as it doesn't read request-specific data like cookies, headers, or search params, and its fetch calls use the default (cached) behavior.

// app/about/page.tsx — statically generated at build time
async function getCompanyInfo() {
  const res = await fetch('https://api.example.com/company'); // cached by default
  return res.json();
}


export default async function AboutPage() {
  const info = await getCompanyInfo();
  return <p>{info.description}</p>;
}

Static Dynamic Routes with generateStaticParams

A dynamic route like app/blog/[slug]/page.tsx can still be fully static — export generateStaticParams to tell Next.js exactly which slug values exist, and it will pre-render each one at build time.

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map(post => ({ slug: post.slug })); // one page per post, all pre-built
}


export default async function PostPage({ params }) {
  const post = await getPostBySlug(params.slug);
  return <article>{post.title}</article>;
}
A Page Per Value

For a blog with 500 posts, generateStaticParams returning 500 slugs means Next.js pre-renders 500 individual static HTML pages during the build.

Advantages & Tradeoffs

Advantages

  • Fastest possible response — no per-request work
  • Can be served from a CDN close to the visitor
  • Extremely resilient — no server computation to fail

Tradeoffs

  • Content is only as fresh as the last build
  • Build time grows with the number of static pages
  • Not suitable for per-user, personalized content

Common Beginner Mistakes

Expecting a statically generated page to reflect new data instantly

It won't, until the next build (or an ISR revalidation, covered in the next lesson) — this is the fundamental tradeoff of SSG.

Forgetting generateStaticParams for a large dynamic route

Without it, that dynamic route falls back to being rendered on demand instead of pre-built — sometimes desirable, but worth being an intentional choice.

FAQs

Next.js can render that page on demand the first time it's requested and cache the result, depending on your dynamicParams setting for that route.

It's most natural there, but any page with content that doesn't change per visitor — pricing pages, documentation, landing pages — is a good SSG candidate.

Summary

SSG trades content freshness for maximum speed and resilience, by doing all the rendering work once at build time. Next, you'll see the opposite end of the spectrum: rendering fresh on every request with SSR.

Next Lesson →

Server-Side Rendering