Field Notes · 01

WordPress Is a Publishing Tool Masquerading as a Website Builder

One site on my server takes up 1,233 megabytes. The words on it would fit in about forty kilobytes. Let me show you what fills the gap.

Patrick Jean-Baptiste · Measured across the sites we maintain

I still run WordPress. Hundreds of installs. I update them every week and I plan to keep doing it.

What I stopped doing, years ago now, was starting there.

Now you may be wondering: if he still runs the thing, why write this at all? Fair question. Because there is a difference between using a tool where it fits and reaching for it by default. Most arguments about WordPress are arguments about whether it is good. That is the wrong question. It is excellent at a few things and structurally bad at others. The trouble starts when a client needs the second set and gets sold the first.

What it is genuinely great at

Publishing without a developer in the room. That is the whole achievement and I am not going to wave it away. Someone who has never opened a terminal can write a post, drop in a photo, fix a typo at ten at night, and hit publish. Twenty years later, nothing else has made that as ordinary.

Not breaking your site. The project treats a broken upgrade as a failure. Themes from 2012 still load. That is rarer than it sounds and worth more than it gets credit for.

And the ecosystem. Event calendars. Restaurant menus. Membership tiers. Multilingual catalogues. If your requirement is a common one, somebody already solved it and you can have it tonight. Building that from scratch would be malpractice.

So when a client publishes three times a week, or their team already knows the admin, or the job needs booking software I would spend four months writing badly, WordPress is the right answer. I say so and I build it.

Let me show you the layers

A brochure site for a small business does not arrive as one thing. It arrives as a stack. Each layer comes from different people, on different release schedules, with different incentives. This is a real one I inherited.

Read that list again and watch where it turns. The first nine layers build the site. The last four exist only to manage the first nine. A third of the machinery is there to contain the rest of the machinery. None of it is what your customer came for.

Now go a level deeper

Every plugin is code you did not write, from an author you cannot call, on a schedule you do not control. Each one ships its own CSS and its own JavaScript, and most load on every page whether that page uses them or not. Your privacy policy is downloading a contact form library. Your about page is downloading a slider.

Every plugin is also a door. Most compromised WordPress sites are not broken into through core. They are broken into through an outdated plugin, very often one the author abandoned two years ago, still sitting in the directory because nobody audits what they are not looking at.

And remember what I said about the ecosystem being a strength? It is the same fact. The thing that lets you solve a problem tonight is the thing that hands you forty maintenance obligations by Friday. One property, two consequences.

The numbers

These are measured off my own production server this month. I left the names out, because the clients did not choose this architecture. In most cases they inherited it, which is exactly the point.

Thirty-seven plugins on one site. Sit with that. Thirty-seven release schedules, thirty-seven authors, thirty-seven chances that an update lands badly on a Tuesday morning. Say each ships eight releases a year, which is conservative. That is close to three hundred update events on one site, in one year.

Multiply that across a fleet and you are not running a web practice any more. You are running a patching operation with a web practice attached. That is the part nobody puts on the invoice.

Look at the bottom two rows. A research archive with hundreds of pages of scholarly material, maps and primary sources, serving in two megabytes. And this site, the one you are reading, at nine hundred kilobytes including the video on the home page, as one compiled file.

So why Go

I moved new builds to Go because it deletes the category of problem instead of managing it.

A Go site compiles into one file. The HTML, the CSS, the images, the video, all of it embedded in a single binary. Deploying is copying that file to the server. Rolling back is putting the old file back. There is no database to breach, corrupt, or restore wrong at two in the morning. There is no plugin folder, so there is nothing in it to go out of date.

The language matters too. Go made a compatibility promise in 2012 and has kept it. Code that compiles today still compiles years from now. That sounds like a technical footnote until you have paid somebody to make a four year old site build again because its toolchain rotted underneath it.

The result you can measure: this page answers in under a millisecond, with no caching layer, because there is nothing to cache. No plugin to tune. No purge to run when your change does not show up.

When I still reach for WordPress

When you already have a WordPress site worth keeping. Rebuilding a working site to satisfy my architectural preference is spending your money on my comfort.

When your team publishes without me. If somebody posts three times a week, an admin they already know beats a fast binary they have to email me about.

When the job genuinely needs the ecosystem. Bookings, memberships, a real storefront with inventory. I would write that from scratch in four months and it would be worse.

What I will not do is start there by default and then spend your first invoice removing the parts you never asked for.

Alright. That is the lesson for this one: you are not buying a website, you are buying everything that has to be maintained to keep it standing. Ask what that is before you sign, not after.