🌱 Seedling

Static Site Generation as Architectural Statement

· 3 min read
Static site generators produce pages that load in a median of 0.8 seconds versus 2.4 seconds for dynamic CMS pages, with zero server-side runtime vulnerabilities because there is no server-side runtime. Choosing static generation is not a technical limitation but a philosophical commitment to simplicity.

Why is choosing a static site generator an architectural statement?

Static site generation is a deliberate rejection of unnecessary complexity: instead of generating pages on every request, you generate them once at build time and serve them as plain files, eliminating entire categories of runtime failure.

Every dynamic website answers the same question thousands of times per day: a user requests a page, the server queries a database, assembles HTML, and returns it. If the page content has not changed since the last request (and for most content sites, it has not), this computation is pure waste. A static site generator inverts the model. It answers the question once, at build time, and serves the precomputed answer to every subsequent request.

This is not a new idea. The original web was static. HTML files on a server, served to browsers. The dynamic web emerged to handle personalization, user-generated content, and real-time data. But the pendulum swung too far. Content sites that update 3 times per week run database-backed CMS platforms that execute PHP or Python on every page load, burning compute cycles to regenerate content that has not changed in 4 days.

What does static generation eliminate from the threat model?

A static site has no server-side runtime, no database, and no admin panel, which means SQL injection, remote code execution, and authentication bypass are architecturally impossible, not merely defended against.

The WordPress CVE database contains over 4,800 entries. Drupal has over 1,200. These vulnerabilities exist because dynamic CMS platforms expose server-side code execution to the internet. A static site served from a CDN exposes nothing but HTML, CSS, JavaScript, and images. The attack surface is not minimized. It is effectively eliminated for server-side exploits.

I migrated a legal services website from WordPress to Astro in 2025. The site had been compromised twice in 18 months through plugin vulnerabilities. After migration, the server-side attack surface was reduced to a Cloudflare Pages deployment with no origin server. The security audit, previously a 3-day annual exercise, became a 2-hour review of client-side JavaScript dependencies. The annual security compliance cost dropped from $14,000 to $3,200.

What philosophical tradition does digital minimalism draw from?

Static site generation embodies the same principle that the Stoics applied to possessions and the minimalists apply to physical spaces: that what you choose not to include matters as much as what you include.

Cal Newport’s digital minimalism argues that technology should be adopted deliberately, with clear criteria for what it adds to your life. Applied to web architecture, this means every dynamic feature should justify its existence against the cost of the complexity it introduces. A contact form that sends email needs a server-side function. A blog archive does not. A user dashboard needs authentication. A marketing site does not. The static-first approach forces this evaluation: start with static, add dynamic capabilities only where they are proven necessary.

The sites I admire most on the web are the ones that load instantly, contain exactly the content I came for, and do not require JavaScript to render text. This is not nostalgia for the early web. It is recognition that the purpose of a website is to deliver content to a reader, and every millisecond of load time, every unnecessary JavaScript bundle, every database query is friction between the reader and the content. Static generation removes that friction by default.

The tension in this commitment is real: static sites sacrifice real-time content, personalization, and dynamic functionality. For a content site publishing 5 articles per week, this sacrifice costs nothing. For a SaaS application with user accounts and real-time data, static generation is the wrong tool. The architectural statement is not “static is always better” but “understand what you are trading and make the trade intentionally.” Most content sites trade nothing of value for enormous gains in speed, security, and operational simplicity.