SSG – Static Site Generation

Understanding Static Site Generation (SSG)

Static Site Generation (SSG) is a rendering method where the HTML for your pages is generated at build time, rather than on every request. This means when you run your build command (e.g., npm run build), the framework fetches data, renders the components, and outputs static HTML files.

These static files are then deployed to a Content Delivery Network (CDN) and served to users instantly. It's the modern equivalent of writing raw HTML files, but with the power of React and dynamic data fetching during the build process.

The SSG Execution Flow

The magic of SSG happens before the user even visits the site:

1. Build Time: You run the build command. The framework (like Next.js) fetches data from your CMS or database.
2. HTML Generation: The framework generates a dedicated HTML file for every route (e.g., /about, /blog/post-1).
3. Deployment: These static files are uploaded to a global CDN (like Vercel Edge Network or Cloudflare).
4. Request & Response: When a user visits a page, the CDN serves the pre-built HTML file immediately. No server computation is required.
5. Hydration: Just like SSR, the browser downloads the JavaScript bundle to make the page interactive.

When Should You Use SSG?

SSG is widely considered the "gold standard" for performance and should be your default choice whenever possible.

1. Maximum Performance

Since the HTML is pre-generated and served from a CDN close to the user, the Time to First Byte (TTFB) is virtually instantaneous. There is no faster way to deliver web content.

2. Unbeatable Security

Because there is no database connection or server-side code running for each request, the attack surface is drastically reduced. You are essentially just serving static files, making it incredibly difficult for attackers to exploit vulnerabilities like SQL injection.

3. Cost Efficiency

Serving static files is extremely cheap. You don't need expensive servers running 24/7 to render pages. A simple CDN setup can handle massive traffic spikes without breaking a sweat (or your bank account).

When Should You Avoid SSG?

The main limitation of SSG is data freshness and build times.

1. Highly Dynamic Data

If your content changes every second (like a stock ticker or a live sports score), SSG is not suitable because you would need to rebuild your entire site every second to reflect those changes.

2. Massive Websites (Build Time)

If you have a website with 100,000 pages (e.g., a massive e-commerce store), building all of them statically can take hours. While Incremental Static Regeneration (ISR) helps solve this, pure SSG can become unwieldy at extreme scales.

🛠️ Implementing SSG in Next.js

Next.js is famous for its first-class support for SSG.

SSG Example: Pages Router

In the Pages Router, you use getStaticProps to fetch data at build time.

// pages/ssg-page.tsx
import type { InferGetStaticPropsType, GetStaticProps } from "next";
 
type Post = {
  id: number;
  title: string;
};
 
// This function runs ONLY at build time
export const getStaticProps = (async () => {
  const res = await fetch("https://api.example.com/posts/1");
  const post: Post = await res.json();
 
  return {
    props: {
      post,
    },
  };
}) satisfies GetStaticProps<{ post: Post }>;
 
export default function BlogPost({
  post,
}: InferGetStaticPropsType<typeof getStaticProps>) {
  return (
    <article>
      <h1>{post.title}</h1>
      <p>This page was statically generated at build time.</p>
    </article>
  );
}

SSG Example: App Router (Modern)

In the App Router, SSG is the default behavior. If you fetch data in a Server Component without specifying cache options (or using force-cache), Next.js will automatically cache the result and statically generate the page during the build.

// app/blog/[slug]/page.tsx
 
// 1. Generate Static Params: Tell Next.js which routes to build
export async function generateStaticParams() {
  const posts = await fetch("https://api.example.com/posts").then((res) =>
    res.json()
  );
 
  return posts.map((post: any) => ({
    slug: post.slug,
  }));
}
 
async function getPost(slug: string) {
  // By default, fetch requests are cached, enabling SSG
  const res = await fetch(`https://api.example.com/posts/${slug}`);
  return res.json();
}
 
export default async function Page({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
 
  return (
    <main className="p-8">
      <h1 className="text-4xl font-bold">{post.title}</h1>
      <div className="mt-4 text-gray-600">{post.content}</div>
    </main>
  );
}

Conclusion: The Foundation of the Modern Web

Static Site Generation is the bedrock of the "Jamstack" architecture. It offers the best possible performance, security, and reliability for content-driven websites like blogs, documentation, and marketing pages.

While it's not a silver bullet for highly dynamic apps, modern frameworks like Next.js allow you to use SSG as your default and opt-in to SSR or CSR only when necessary, giving you a perfectly optimized application.