engineering
Why static sites win for long-form writing
For a single-author publication, static generation beats every server-rendered alternative on speed, cost, security, and survival. Here's the case.
Contents
My thesis is simple: if you are one person publishing written articles, a statically generated site is not one reasonable option among several — it is the correct default, and every alternative should have to argue its way past it.
I say this having built the other kinds. I have shipped server-rendered apps with databases, caching layers, and background jobs, and I will again — for products that need them. A blog does not need them. A blog is a set of documents that change when the author changes them, which for most of us is at most weekly. Rendering the same document on every request, forever, is work a computer does because nobody told it to stop.
The reader’s case: speed is the whole experience
A static page is HTML sitting on a CDN edge node near the reader. There is no database round-trip, no template rendering, no cold start. Time to first byte is measured in tens of milliseconds, and the Core Web Vitals targets that most teams sweat over become almost hard to miss.
This matters more than it looks like it should. Most article traffic arrives from search, on phones, often on connections much worse than the one you built the site on. The reader has never heard of you and owes you nothing. Every hundred milliseconds you spend is spent from an account with a low balance and no overdraft.
The author’s case: nothing to babysit
The strongest argument for static sites has nothing to do with readers. It is what isn’t there:
- No server to patch. There is no process running at 3 a.m. that can crash, leak memory, or be found by a vulnerability scanner.
- No database to back up. The content is files in a Git repository. The backup story is
git push, and the version history is better than anything a CMS offers. - No bill that scales with attention. When an article gets ten thousand readers in an hour, a CDN shrugs. A $5 VPS does not.
A publication owned by one person has to survive that person’s busy months. The systems that survive are the ones that require nothing when you are not looking at them. This is the same instinct behind choosing boring technology: total cost of ownership is dominated by the years after launch, not the weeks before it.
The machine’s case: crawlers get finished HTML
Search engines, social preview bots, and feed readers all consume your site as text. A static build hands them complete HTML with every heading, link, and structured-data block already in place — no JavaScript execution required, no rendering queue, no ambiguity. Client-rendered sites make Google do extra work and make lesser crawlers fail outright.
For a publication whose growth strategy is organic search, this is not a nice-to-have. It is the strategy.
What you give up, honestly
Static generation is not free of trade-offs, and pretending otherwise is how people get burned:
Dynamic features need a plan. Search, comments, and forms all need to be solved without a server. In practice each has a good static-era answer — a pre-built search index, a comments widget backed by an external store, a form that posts to a provider — but each is a decision, not a default.
Builds are a step. Publishing means running a build. With a Git-connected host this is invisible — push, wait ninety seconds, live — but it is still a pipeline that can fail, and you want it to fail loudly before deploy rather than silently after.
Truly per-user content is out of scope. If your site needs accounts, personalization, or payments, you have left blog territory and should architect accordingly. The mistake is not needing a server; the mistake is carrying one for years before you need it.
The decision, stated plainly
Every dynamic-looking feature a blog needs can be resolved at build time or pushed to a small, isolated island of JavaScript. What remains is a site that is faster than what a team of engineers maintains at most companies, costs about as much as a coffee per year, and cannot be hacked in any interesting way because there is nothing running.
One person, writing, on a system that never pages you. That is the entire pitch, and for this class of site I have never seen it lose on the merits.
One essay on building for the web, most weeks
No digests, no product updates — the same articles that appear here, in your inbox. Unsubscribe with one click, any time. Or take the RSS feed instead.
Double opt-in — you'll get a confirmation email first. Your address is used for nothing else.