A few months ago I started a text file called sites.txt. Nothing organised about it, just a URL per line and sometimes a word about why I kept it. It’s at sixty-one entries now.

Almost none of them are on a platform. There’s a man in Utrecht who writes about bridges. Someone’s twelve-year log of every bird seen out of one kitchen window, with counts. A woodworker who posts once a month, bad photos, very good writing. A retired air traffic controller taking apart old incidents in a level of detail no publication would ever pay for.

I wasn’t collecting personal sites on purpose. That’s just what the file filled up with.

This gets announced every eighteen months

I should say up front that people have been calling the return of the personal website since about 2010, and have been wrong nearly every time. RSS is back. Blogs are back. The indie web is back. Usually it isn’t.

So take what follows with some salt. Something does feel different to me, but the reasons are less romantic than the usual version of this argument.

Search stopped doing the job

The practical change is that search stopped surfacing this kind of thing, so I started finding it other ways. Links from other small sites, a couple of aggregators, people sending me stuff directly.

That’s mostly a downgrade and I’d rather have working search. But it does mean anything I find now arrives with a recommendation attached, which turns out to be a better filter than a ranking algorithm losing an arms race with the SEO industry.

The economics broke first

For a long time the deal was reasonable. You put your work on a platform and the platform gave you reach.

What broke wasn’t the idea, it was the arithmetic. Reach became something you rent. Publishers hit the same wall at a much larger scale and a few of them nearly died of it. If half your traffic comes from one referrer, you don’t have an audience, you have an arrangement, and the other party can change it on a Tuesday.

Running your own site doesn’t fix any of that. It just makes the number honest.

Building one got easy, which nobody mentions

Here’s the part I don’t see written about much. Making a decent website is significantly less work than it was in 2012.

A lot of that is just the browser catching up. clamp() scales type from a phone to a monitor in one line. Grid does layouts that used to need a library. prefers-color-scheme turns dark mode into a media query instead of a feature. loading="lazy" replaced most of what image plugins existed for. None of it needs a build step or a framework.

This site is the demonstration. Markdown files go through a Python script, the script writes HTML, nginx serves the HTML:

content/posts/*.md   →   build.py   →   dist/**.html   →   nginx

No database, no framework, nothing running per request. The only JavaScript on the page is about fifteen lines that remember whether you picked dark mode. It’s a few hundred lines of CSS and one Python file I’ll still be able to read in six months, which is the real test.

If half your traffic comes from one referrer, you don’t have an audience, you have an arrangement.

The thing I actually care about

I lost a few years of writing once. Nothing dramatic. A service announced it was shutting down, I told myself I’d export everything, I didn’t, and the export tool broke before the domain did. I still remember two or three of those posts and I’d like to read them again and I can’t.

Everything I’ve put on my own domain since 2015 is still sitting at the same address. That isn’t an achievement, it’s just what happens when nobody else is in charge of the URL. You don’t really notice it as a feature until you’ve lost it once.

What it’s bad at

Worth saying, because posts like this tend to oversell. One person with a static site is not going to run an investigations desk, or cover an election night, or fight a libel case. That takes a newsroom, newsrooms cost money, and a lot of that money currently comes from exactly the ad machinery I’d rather not have on my own pages. I don’t have a clean answer to that and I’m suspicious of people who do.

Small sites are good at something narrower. One person, one subject, no deadline, and enough room to get it right.

If you want one

The technical barrier isn’t the barrier. Buy a domain, put files on a server. A few things I’d tell myself if I were starting over:

• Pick a URL shape you can live with for ten years, then leave it alone. /posts/slug/ is fine. Anything with a date in the path you’ll eventually regret.
• Write for the version of you from before you knew the subject.
• Ship it unfinished. Everything on the small web is slightly unfinished. That’s most of the charm.

Sixty-one entries. I’ll probably still be adding to that file next year.

This is sample content, here to show off the layout and typography. The pictures are generated placeholders — drop real ones in static/img/ and point the front matter at them.

I did this partly out of curiosity and partly because a page had been chugging on my phone and I wanted to know why.

Six sites, one article each, network panel open, cache cleared. The lightest came in at 2.1 MB. The heaviest was just under nine. Every one of them kept loading things for several seconds after the text was already sitting there on screen, which is why the layout jumps around while you’re trying to read.

The article text itself, in every case, was somewhere between fifteen and forty kilobytes.

Where it goes

Roughly, and it was consistent enough across all six to be worth writing down:

• Ads and the plumbing around them, usually more than half the total, spread over dozens of requests to servers the publisher doesn’t run.
• Analytics and consent management, which exists to legally collect the data the ads want.
• Fonts, often a few hundred kilobytes, frequently including weights the page never uses.
• The writing, at somewhere under two percent.

That last one is the number I keep thinking about. On a lot of the web the article is a rounding error inside its own delivery system.

The caveat

None of this makes a small site better journalism. Weight isn’t quality and a fast page can be completely empty. Those sites employ reporters, and I don’t, and the ad machinery I’m complaining about is what pays them.

What struck me wasn’t that the pages were heavy. It’s how much of the weight has nothing to do with either the writing or with funding it, and how much of it looks like stuff nobody has gone back and looked at in years.

For comparison, since it’s only fair: this page is about 20 KB of HTML, one stylesheet, and whatever pictures the post actually needs. That’s not clever engineering. I just didn’t add the other things.

Someone asked what this site runs on and I realised the honest answer is “not much”, so here it is written out.

The pages are generated on my laptop and handed to nginx as files. There’s no application server, no database, no queue, nothing that can crash at three in the morning. If the build breaks it breaks while I’m looking at it. What ends up on the server is a directory.

The full list:

1. A small VPS.
2. nginx, serving a folder.
3. A Let’s Encrypt certificate on a renewal timer.
4. Gzip, some cache headers, a handful of security headers.

That’s it. It has no interesting failure modes because there’s almost nothing in it to fail.

It’s fast because it’s lazy

A static file is the least work a web server can do. Nothing to render per request, no query, no cache to warm or invalidate. nginx reads from the page cache and writes to a socket. Response times are fractions of a millisecond and they don’t move much under load, because there’s nothing that gets slower when more people show up.

It’s also the easiest thing to keep secure, mostly by not having features. No upload handler, no comment form, no admin login, no session to steal. The attack surface is more or less “does nginx have a bug this month”, which is a much smaller question than the one a typical site has to answer.

When this stops working

The obvious caveat: this works because the site is small and one person writes it. Add search, or comments, or accounts, and you’re back to running an application. At that point the boring option is a different boring option rather than none at all.

But a lot of sites are, functionally, a folder of documents that someone has wrapped in a CMS out of habit. Worth checking whether yours is one of them before reaching for anything bigger.

I’ve clicked accept on thousands of these. I know roughly what’s in them. I still click accept, because the alternative is a second screen with thirty toggles and three paragraphs about legitimate interest, and I only wanted to read a recipe.

That’s the whole problem, and it isn’t really a problem with the law.

A consent dialog only works if saying no is as easy as saying yes. In practice “Accept all” is one big button and refusing is a maze. Given that, clicking accept isn’t consent. It’s just the rational way out of the maze.

What it taught everyone

The wasted seconds aren’t the damage. The damage is that a whole generation of users has now been trained that a box asking about data is noise to be cleared, not a decision to make.

Then something genuinely important shows up. A permission prompt, a security warning, a browser telling you a certificate is wrong. It inherits the same reflex, because it looks like the same thing. We spent fifteen years making privacy decisions feel like an obstacle and then acted surprised when people started treating them as one.

The version that works

There’s a simpler route, and a fair number of sites have quietly taken it: don’t collect the stuff that needs consent.

No ad identifiers, no third-party embeds, no analytics beyond the log file the server writes anyway. Do that and there’s no banner, because there’s nothing to ask about.

That’s why nothing interrupted you on the way in here. I want to be clear it isn’t a principled stand so much as a shorter feature list. But the compliant, private, fast version of a site also turned out to be the cheapest one to build, and I don’t think that’s a coincidence.