survivalism.pl

My own survival and outdoor guides publication with a few dozen posts in two languages, run on WordPress since 2020. I rebuilt it so the editor keeps working in the WordPress they know, while readers get prebuilt HTML files with no WordPress in between.

Starting point: "it can't get faster"

Before the change, PageSpeed Insights scored the site 97-100. On paper there was nothing to fix. Measured from a regular reader's side it looked different: Google's test hit the server cache, visitors almost never did. In a day-long series of measurements the cache worked once in 24 tries, and the median time to first byte of a post was 2.42 s.

On top of that, 28 active plugins on the public site and close to 300 releases to install in a year, around 70 of them with a security fix. Every delayed update left a door open.

What I changed

• The public site is static files generated from the WordPress content. There is no WordPress and no database on it, so plugins and their vulnerabilities have nothing to attack.
• WordPress stays as the editorial panel on a separate address, behind a server password and a login. The editor writes as before and clicks "Publish". About fifteen minutes later the change is live.
• Before every publish, an automated check goes through the built site: links, images, comments, redirects. If anything is off, publishing stops and the previous version stays live.
• Reader comments arrive in the panel as pending. Approving a comment triggers the publish on its own, no commands involved.
• The contact and comment forms run as small scripts protected by Cloudflare Turnstile, loaded only when someone starts filling in the form.

No lost URLs

The site lives on search traffic and partner posts, so every URL, redirect and link had to come through unchanged. After the switch the live check passed 188 of 188 URLs and the Google Search Console URL list 235 of 235, without a single difference. Partner posts kept their content and link attributes 1:1.

Result

• Server response for a post: now 0.06 s, 2.42 s (median) before the rebuild, for every visitor.
• A post on mobile: 224 KiB and 9 requests, LCP 1.65 s (1.80 s before), PageSpeed 99.
• Plugins: 0 on the public site, 11 in the editorial panel instead of 28 in production.
• Cost: the same shared hosting as before, builds fit in the free GitHub Actions allowance.

Where the speed comes from: before, every reader's visit started WordPress, which assembled the page from the database with 28 plugins loaded. The cache was meant to skip that, but it hit once in 24 visits. Now the page is assembled once, at publish time, and the server only hands over a ready file.

Honestly, about what is not better yet: the home page on mobile is heavier than before (a bigger header image), and that is the next fix. I am measuring search results for 30 days after the switch and will add them here at the end of October 2026.

Hosting: lower requirements, more choice

Readers get prebuilt files, so the public site needs neither PHP nor a database: hosting for plain files is enough, and more traffic does not call for a stronger server. WordPress now serves only the editors, so the smallest plan does for it too.

With a single editor you can go further: WordPress runs on the editor's own computer, with a database backup kept off it, and only the files live online. survivalism.pl worked this way for its first day after the switch, and today it is its fallback route.

Here the forms run as small PHP scripts on the same hosting; on file-only hosting an external form service takes them over. I then move the redirects that search traffic depends on into the new host's settings.

survivalism.pl stayed on its existing hosting because the same account runs other sites, so I did not measure that saving here. It counts where a whole hosting plan is paid for one website, or where traffic forces a higher plan: a lower plan is then enough, and with the editor working on their own computer even free hosting for plain files will do.

When this approach fits

Static files work where the content is the same for every visitor: a blog, a how-to publication, a company site. In a shop the cart, customer account and stock have to stay dynamic, so the gain does not carry over one to one. A shop built headless from the ground up is described in the Suavius Atelier case study.