The Case for Static Sites in 2025

Every few years, the web rediscovers static sites. The tools change — Jekll, then Hugo, then Eleventy, then Astro — but the underlying argument stays the same: for most content, you don't need a database query on every request.

This sounds obvious. It's also, apparently, counterintuitive enough that the industry spends considerable energy forgetting it.

What Static Actually Means

A static site is one where the HTML is generated before a user requests it. The server's job is simple: return a file. No computation, no database, no framework overhead.

The tradeoff is that content must be generated ahead of time. This works perfectly for anything that doesn't change per-user or per-request — blogs, documentation, marketing pages, portfolios.

For content that does need to be dynamic (user accounts, e-commerce, real-time data), static generation can still handle most of the page, with dynamic islands hydrated on the client. The line has blurred considerably.

Why It Keeps Winning

Performance is intrinsic, not achieved. A static site is fast by design, not because someone tuned it. There's no optimization work to undo when a new feature ships. The default is fast.

Hosting is trivially cheap. Files served from a CDN cost fractions of a cent. You can host a personal site for free indefinitely. This matters at scale too — a static CDN can handle traffic spikes that would require significant infrastructure for a server-rendered app.

Security surface is minimal. No server, no server-side vulnerabilities. The attack surface for a static site is mostly the CDN and any client-side JavaScript you include.

Deployment is reliable. You can preview an exact copy of production locally. The artifact you deploy is the artifact users receive. There are no environment-specific bugs, no database migration gotchas, no secret configuration drift.

The Honest Cost

Static sites don't work for everything. Real-time applications, personalized feeds, commerce with inventory — these need server computation.

And the build step introduces its own complexity for very large sites. Rebuilding a million-page site on every content change is slow. (Incremental builds exist, but they add complexity.)

The framework ecosystem can also be disorienting. What started as "just files" has evolved into elaborate compilation pipelines with their own abstractions to learn.

A Personal Heuristic

My rule of thumb: if the page is substantially the same for all users, generate it statically. If it varies meaningfully per user, render it dynamically. Everything else is premature optimization.

For this site, every page is static. The words don't change based on who's reading them. Generating them at build time — rather than on every request — is simply correct.

That the technology to do this has gotten significantly better is a pleasant bonus.