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.

Then I corrected some lyrics with a script, and the table stopped being current.

The catch

The lyrics live in post meta. My script called update_post_meta(), which writes the meta and fires its own meta hooks. It doesn’t fire save_post, because the post itself wasn’t saved.

Edit a post on the screen and everything works, since the editor saves the post. Change the same value from a script, an import or WP-CLI, and anything hanging off save_post never hears about it.

What to do about it

If your code derives something from post meta, you have two options.

Hook the meta write as well:

add_action( 'updated_post_meta', function ( $meta_id, $post_id, $key ) {
    if ( 'hymn' === $key ) {
        my_rebuild_map();
    }
}, 10, 3 );

That fires once per changed row, so on a bulk import you’d rebuild thousands of times. For a bulk job it’s cheaper to do what I did and call the rebuild once, at the end of the script.

Either way, the rule is worth remembering. save_post means a post was saved, and it doesn’t mean the data changed.

wp litespeed-purge all
Success: Purged All!

The pages kept coming back with x-litespeed-cache: hit and the old HTML.

Where the cache really was

The page cache on that host lived in server-level storage outside the WordPress folder, in a directory called lscache. It held 19,189 pages. The wp-content/litespeed folder that I’d assumed was the cache only held about 3 MB of optimized assets.

The WP-CLI purge signal never reached the server’s storage. The command had no way of knowing that, so it reported success.

Purging from wp-admin worked, because that request goes through the web server. On the command line, this did the job:

find ~/lscache -mindepth 2 -type f -delete

It’s safe because it’s only a cache and rebuilds itself on the next request. -mindepth 2 leaves the top-level control file alone.

Check the page, not the message

With a seven-day cache lifetime, a theme or plugin change on that site could look broken for a week. Any fix would seem to have done nothing, and you’d go hunting for a bug that wasn’t there.

So after any purge, I fetch the page twice:

curl -s -D- https://example.com/ -o page.html | grep -i x-litespeed-cache

The first fetch should be a miss and the second a hit, with your new markup in the file. Desktop and mobile are cached separately, so check both.

A success message tells you that a command finished. It says nothing about whether the thing you wanted actually happened.