The case for boring static sites

There is a particular kind of engineering pleasure in over-solving a problem. A blog with four posts a year does not need a runtime, a database, or a cache invalidation strategy. It needs files.

What you give up

Honestly: not much, for content. No personalisation, no per-request logic, no live data. If your site needs those, you need a server, and no amount of cleverness with build hooks will change that.

What you get

Everything else gets simpler. There is no server to patch, no cold start, no region to pick. A CDN serves bytes it already has. The failure mode of a static site is “the CDN is down”, which is a much shorter list of things to worry about than the alternative.

Performance stops being work. You are not optimising a render path; there is no render path. The page was finished before the request arrived.

Where it stops being true

Search across thousands of pages. Anything gated behind a login. Content that changes faster than you can rebuild — though “rebuild on publish” covers more cases than people assume.

The honest boundary is this: static until you have a specific reason not to be, and then only for the part that needs it.