Static Site Generation (SSG)

The defining mechanism of SSG. Every page of a site is rendered to its final HTML, CSS, and JavaScript state during a build process, not on-demand. This occurs in a CI/CD environment where a framework like Next.js, Gatsby, or Hugo fetches data from APIs or markdown files and generates a complete directory of static assets. The output is a 1:1 mapping of routes to pre-built HTML files, eliminating server-side processing at request time.

Since the output is pure static files, the entire site can be served directly from a Content Delivery Network (CDN). The HTML, JavaScript bundles, and assets are pushed to edge nodes globally. A user's request is routed to the nearest edge location, serving the pre-built page with single-digit millisecond latency. This eliminates origin server bottlenecks and makes the site virtually immune to traffic spikes.

SSG enforces a strict separation of concerns. Content is pulled from external sources exclusively at build time via GraphQL, REST APIs, or local files. The live production site has no direct database connection. This decoupling means the content layer (a Headless CMS, Product Information Management (PIM) system, or database) can fail or undergo maintenance without taking the public-facing site offline. The site remains stable, serving its last successfully built state.

Each build produces a complete, self-contained snapshot of the entire site. Deployments are atomic—the new version of every file is uploaded to a new directory on the CDN, and the traffic switch is instantaneous. There is no risk of a partial deploy where some servers have new files and others have old ones. If a build fails, the previous immutable deploy continues serving without interruption, providing a zero-downtime rollback mechanism by default.

A static site has a dramatically reduced attack surface. With no live server, no database, and no server-side code execution, traditional vulnerabilities are eliminated:

• No SQL injection vectors
• No server-side code execution exploits
• No WordPress/PHP plugin vulnerabilities
• No origin server to DDoS The server is effectively a read-only file system on the CDN edge. Authentication and dynamic operations are delegated to third-party APIs and serverless functions accessed client-side.

The entire site becomes a Git repository. Content can be stored as Markdown alongside the code, making every change trackable, reviewable, and revertible via pull requests. The build process runs in a CI/CD pipeline, enforcing automated testing, linting, and Core Web Vitals budgets before deployment. This infrastructure-as-code approach aligns web publishing with standard software engineering best practices, enabling predictable, auditable releases.