SSG — Explained with Examples

Static Site Generation (SSG) pre-builds HTML pages at compile time, serving them as static files for fast load speeds and simple hosting.

SSG generates all HTML pages during the build process, producing a directory of static files (HTML, CSS, JS, assets). These files can be served directly from a CDN or web server without any server-side processing at request time. Popular SSG tools include Hugo, Jekyll, Next.js static export, Gatsby, and Astro. SSG works well for content that does not change on every request.

Think of SSG like printing a newspaper. All articles are written, edited, and laid out the night before (build time). In the morning, newspapers are delivered to newsstands (CDN). Readers get the complete paper instantly. Updates require a new edition (rebuild). This contrasts with SSR, which is like a custom news briefing written after you request it.

SSG excels for blogs, documentation sites, marketing pages, and e-commerce product catalogs. It provides the fastest possible Time To First Byte (TTFB) and works without JavaScript.

# Hugo build (static site generator)
hugo new site my-site
hugo new posts/my-post.md
hugo --minify
# Output in ./public/

// Next.js SSG (static generation)
export async function getStaticProps() {
    // Runs at build time
    const res = await fetch('https://api.example.com/docs');
    const docs = await res.json();

    return {
        props: { docs },  // Injected into page component
    };
}

SSG limitations: longer build times for large sites and no dynamic per-request content. ISR and SSR complement SSG for dynamic needs.

SSR, ISR, SPA, MPA, DOM

SSR vs SSG