Static site generation (SSG) is a web development approach where HTML pages are pre-built at compile time. Instead of generating HTML on every request, the build process creates all pages in advance. These static files are then deployed to a CDN and served instantly to users.
SSG is the foundation of the Jamstack architecture and powers some of the fastest websites on the internet.
How SSG Works
- Build phase — the framework fetches data from APIs, CMS, databases, or files
- Page generation — HTML is generated for every page at build time
- Deployment — static HTML, CSS, and JS files are uploaded to a CDN
- Serving — users receive pre-built pages from the nearest CDN edge node
No server processing happens at request time. The CDN simply returns a file.
SSG vs Other Approaches
| Approach | When HTML is Created | Speed | Data Freshness |
|---|---|---|---|
| SSG | At build time | Fastest | Stale until rebuild |
| ISR | Build time + revalidation | Fast | Near real-time |
| SSR | On each request | Moderate | Always fresh |
| CSR | In the browser | Slow initial | Always fresh |
Benefits of SSG
Blazing Performance
Pre-built pages are served from CDN edge nodes. No server processing, no database queries, no rendering delay. Time to first byte (TTFB) is measured in milliseconds.
Security
No server to hack, no database to exploit. Static files on a CDN have an extremely small attack surface.
Reliability
CDNs are designed for 99.99% uptime. No origin server means no single point of failure.
Cost
Static hosting is extremely cheap — often free. No server infrastructure to manage or scale.
SEO
Fully rendered HTML with proper meta tags, structured data, and fast load times. Search engines love static pages.
Incremental Static Regeneration (ISR)
The main limitation of pure SSG — stale content — is solved by ISR. With ISR, you get the performance of static pages with the freshness of server rendering:
- Pages are statically generated at build time
- After a set time period (revalidation interval), the page is regenerated in the background
- Users always see a cached version while the new one builds
- New content appears without a full site rebuild
This is the approach we use at Moydus for most content pages.
When to Use SSG
SSG works best for:
- Marketing websites — pages that change infrequently
- Blog posts and articles — content published then rarely edited
- Documentation — reference material with periodic updates
- Landing pages — conversion-optimized pages
- E-commerce product pages — with ISR for price/stock updates
When to Use Alternatives
- Highly personalized pages → SSR for per-user content
- Real-time dashboards → CSR for live data
- Thousands of pages with frequent changes → ISR or SSR
SSG with Next.js
Next.js supports SSG out of the box. In the App Router, pages are statically generated by default:
// This page is statically generated at build time
export default async function BlogPost({ params }) {
const post = await getPost(params.slug);
return <article>{post.content}</article>;
}
// Tell Next.js which pages to generate
export async function generateStaticParams() {
const posts = await getAllPosts();
return posts.map(post => ({ slug: post.slug }));
}
ISR: the best of both worlds
Next.js Incremental Static Regeneration (ISR) lets you set revalidate: 60 to regenerate a page every 60 seconds — giving you static performance with near-real-time content. No full rebuild needed.
How Moydus Uses SSG
At Moydus, we use SSG with ISR as our default rendering strategy:
- All content pages are statically generated for maximum performance
- ISR keeps content fresh without full rebuilds
- Cloudflare CDN delivers pages globally in under 50ms
- Dynamic features are layered on top with client-side JavaScript
This gives our clients the fastest possible websites while maintaining content freshness. See our web development services.