I kept WordPress and removed the server

Nziyo is a Shona hymn library with about 2,600 pages. These hymns are sung in Zimbabwe. Its server was in the US.

On a cached page, the first byte took about 1.3 seconds to arrive here. I spent time on the usual fixes. I minified everything, and stopped Contact Form 7 and its reCAPTCHA from loading on hymn pages. Combined assets went from 113,998 bytes to 88,953, a 22% cut.

The first byte took 1.31 seconds before that work and 1.28 to 1.34 seconds after it.

Distance doesn’t minify

About 890 ms of that time was round trips to the US. No plugin setting can change where a server is. The options were a CDN in front of WordPress, or removing the origin from the visitor’s path altogether.

Almost nothing on a hymn site changes between requests, so I took the second option.

How it works now

WordPress runs only on my own PC. I edit there exactly as before. A Python script asks WordPress for every public URL, saves the HTML, rewrites the links, copies the assets and deploys the result to Cloudflare Pages.

Two things needed replacing, because static files can’t run PHP:

• Search became a Pagefind index, built during export.
• Forms and comments became Cloudflare Pages Functions. Comments wait in a D1 database and I approve them from a link in an email. The next publish imports them into WordPress and clears them from the queue.

The result

The first byte now takes about 0.3 seconds from the same connection. There’s also no public wp-login.php for bots to hit, and nothing on the server to patch.

What it costs you

Publishing is now a step you have to run, and scheduled posts won’t appear by themselves. The only full copy of the site is on one computer, which makes a nightly backup essential. And this approach suits a site that’s mostly read. A shop with carts and accounts needs something else.

For a brochure site, a blog or a reference library, it’s worth asking whether your visitors need PHP at all.