Technology

Why serving WordPress doesn't need PHP

A WordPress page view does a remarkable amount of work. A PHP-FPM worker wakes up, loads WordPress core, your theme, and every active plugin, opens a connection to a MySQL server, runs the loop, and tears most of it down again. For every single request. That's why typical WordPress hosting answers in 300–1000 ms, and why each concurrent visitor costs 50–200 MB of RAM.

None of that work is what makes your site your site. Your site is the content, the theme that renders it, and the admin you edit it with. BookPress keeps exactly those three things and replaces everything underneath.

The engine

Real theme rendering

BookPress renders WordPress block themes natively. It reads the same template files, the same block markup, the same theme.json, and produces the same HTML and CSS WordPress produces: global styles, layout classes, font presets, fluid typography. The default WordPress theme, Twenty Twenty-Five, renders pixel-close today from its unmodified theme files, web fonts and all.

The admin works the same way. /wp-login.php verifies your existing WordPress password hashes, and /wp-admin gives you the dashboard, post lists, and editor, served by the same engine at the same speed.

Measured, not promised

One machine. Same Twenty Twenty-Five theme, same content, same benchmarking client. Three stacks: naive WordPress (the official Docker image, Apache, mod_php with OPcache, MariaDB, no page cache), optimized WordPress (the same stack plus WP Super Cache, installed and switched on, its cache hits verified by response headers), and BookPress. Keep-alive p50. The client and setup are published.

The honest part: a well-tuned page cache is worth having. It makes anonymous repeat visits fast, and the numbers above show that. What it can't do is rewrite the physics of a page it can't serve: first visits after any change, search, logged-in sessions, and anything dynamic all still pay the full PHP-plus-database price, cache installed or not. BookPress doesn't have that second number, because it was never trying to cache its way to fast. Cold is the only path, so cold is what we optimized: p99 under 1 ms, with tens of thousands of mostly idle sites per server hitting that cold path on nearly every request.

Bytes on the wire: every stack compresses. WordPress via Apache's mod_deflate (enabled by default in the official image), BookPress natively in the engine, negotiated per request, no plugin or server config. The same front page travels as 11.9 KB from WordPress and 3.1 KB from BookPress, because our markup is 4× thinner before compression even starts. Compressing costs about a third of a millisecond and gzipped responses still render in 0.70 ms p50.

See the charts →

What this unlocks

When a site costs ~6 MB of memory and microseconds of CPU per view, hosting economics invert. Thousands of low-traffic sites fit on one modest server, and an idle site's cost approaches the cost of its storage. That's the difference between selling hosting at €10–30 per site with thin margins and wholesaling it at €1–3 per site profitably.

What that means if you manage many sites →