Mastering Static Site Generation (SSG) in Next.js

Previously in this course, we explored performance monitoring to track how our site behaves under real-world conditions. While server-side rendering (SSR) is excellent for dynamic data, it introduces a "time-to-first-byte" (TTFB) delay because the server must compute the page on every request.

Static Site Generation (SSG) solves this by shifting that computation to your build time. Instead of waiting for a user to click a link, we generate the HTML once during deployment and serve it instantly from a CDN.

Understanding SSG vs. SSR

In a standard SSR setup, Next.js executes your page.js code every time a request hits your server. If that page fetches data from a database, the user waits for the database query, the component rendering, and the network latency.

With SSG, the output is a static HTML file. The server doesn't "run" anything; it just delivers a pre-written file.

Using generateStaticParams

For our blog, we have dynamic routes like /blog/[slug]. By default, Next.js renders these on-demand (SSR). To convert these to SSG, we use the generateStaticParams function. This function tells Next.js, "Here are the IDs I want you to pre-render during the build."

If you haven't yet mastered dynamic routes, review our introduction to dynamic routes before proceeding.

The Worked Example

Open your app/blog/[slug]/page.js file. We will update it to pre-render our posts:

JAVASCRIPT
import { getPostBySlug, getAllPosts } from CE9178">'@/lib/db'; // Your data fetching logic

// 1. Tell Next.js which paths to pre-render
export async function generateStaticParams() {
  const posts = await getAllPosts();
  
  return posts.map((post) => ({
    slug: post.slug,
  }));
}

// 2. The page component remains mostly the same
export default async function Page({ params }) {
  const { slug } = params;
  const post = await getPostBySlug(slug);

  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </article>
  );
}

When you run npm run build, Next.js will call generateStaticParams, receive an array of slugs, and generate an individual HTML file for every single post. This is a powerful SSG pattern for performance.

Hands-on Exercise

1. Open your app/blog/[slug]/page.js file.
2. Implement generateStaticParams to fetch all your post slugs from your database or local files.
3. Run npm run build in your terminal.
4. Observe the output: You should see a list of routes being "staticly generated" (marked with a lambda/static symbol) in the build logs.

Common Pitfalls

• Large Datasets: If you have 100,000 blog posts, generateStaticParams will make your build time extremely long. Use SSG for your "long tail" of content and consider ISR (Incremental Static Regeneration) for larger datasets.
• Missing Params: If you don't include all possible parameters in generateStaticParams, those pages will fall back to SSR (or 404, depending on your configuration), which might surprise you if you expected them to be static.
• Database Connections: Ensure your build environment has access to your database during the generateStaticParams step. If your DB is behind a VPN or firewall, the build will fail.

FAQ

Can I mix SSG and SSR in the same app? Yes, absolutely. Next.js is "hybrid." You can have some pages rendered statically and others rendered on-demand.

Does SSG mean my site is stuck in the past? Not necessarily. You can redeploy your site whenever content changes, or use Incremental Static Regeneration to update pages in the background.

How does this affect my SEO? SSG is excellent for SEO. Because the HTML is ready before the user requests it, search engine crawlers receive the full content immediately, leading to better indexing.

Recap

Static Site Generation (SSG) allows us to pre-render pages at build time. By using generateStaticParams, we explicitly tell Next.js which dynamic routes should be pre-compiled into static HTML files. This drastically improves performance, making your blog faster and more resilient to traffic spikes.

Up next: We will explore Incremental Static Regeneration (ISR), which allows us to update our static pages without rebuilding the entire site.