More requests a second, even with the plugins on.
On real WooCommerce and Elementor pages, BookPress serves about 4.5 times the requests per second of a WordPress tuned with PHP-FPM, OPcache and its JIT, a Redis object cache and MariaDB on a 4-vCPU Intel server, and over 5 times on a 4-vCPU ARM server. The stacks and every number →
BookPress 0.2.64 (packaged), measured 19 October 2026. WordPress runs its own PHP with OPcache, its JIT and a Redis object cache, with the page cache off.
Every page, every server, as a multiple of WordPress.
The numbers come from a repeatable setup: it builds a tuned WordPress, loads the identical demo content into WordPress and BookPress, checks that both show the same page, then drives each engine to the most requests a second it serves with 99% of them under one second and none failing. BookPress renders every page fresh; the WordPress side runs its own PHP with the page cache switched off, which is the state a cart, a search, an account page or anything with a session is always in.
What both engines served
A real WordPress site, migrated across: the Kadence theme, WooCommerce with a five-product catalogue, a built Elementor showcase page, Yoast SEO and Contact Form 7. Both stacks serve the same pages, from the same seeded content: the same Elementor markup, the same product page, the same shop catalogue. The two databases carry the same row counts, checked before timing.
The WordPress it beat
WordPress 7.1.3 on PHP 8.3.35 with OPcache and the JIT enabled, a Redis object cache over a socket, MariaDB, and PHP-FPM behind nginx, with WooCommerce on its newer order storage (HPOS). Tuned the way a competent host tunes one. The page cache is off for every measurement, and we check it is off before timing.
Both servers
A 4-vCPU Intel server and a 4-vCPU ARM server (Google Cloud
c2-standard-4 and c4a-standard-4), both 16 GB.
BookPress wins on both. The ARM server has four real cores where the Intel
one has two, and BookPress serves about 2.3 times the
Elementor requests per second on it.
Every number, as a multiple of WordPress
| Page | Server | Requests / second | p50 response time | p99 response time |
|---|---|---|---|---|
| Elementor page | Intel | 4.53×162 against 36 pages/s | 3.80× | 1.93× |
| WooCommerce shop | Intel | 4.85×134 against 28 pages/s | 4.75× | 2.79× |
| Elementor page | ARM | 5.30×376 against 71 pages/s | 5.30× | 3.70× |
| WooCommerce shop | ARM | 5.19×297 against 57 pages/s | 5.20× | 2.50× |
Measured on Google Cloud c2-standard-4 (Intel) and c4a-standard-4 (Arm), uncached dynamic pages, BookPress 0.2.64 (the packaged build you install) against WordPress 7.1.3 / PHP 8.3.35 with nginx, PHP-FPM, Redis object cache, OPcache with JIT and MariaDB.
Requests per second is at each engine's knee; p50 and p99 are the median and 99th-percentile response-time multiples at WordPress's knee rung. WordPress is measured without a page cache; a page a cache can serve is served from the cache by either setup and does not measure the engine.
A site with no plugins runs no PHP interpreter at all. There BookPress serves 112.9 times the requests per second of WordPress on the Intel server (5,234 against 46) and 125 times on the ARM server (11,436 against 91), with no plugins installed.
What the same site costs in memory.
Memory is a separate, earlier measurement, taken on BookPress 0.2.57. Under full load on the Intel server the same site took about 0.6 GB on four BookPress workers, against 0.55 GB for a right-sized WordPress and 1.8 GB for a tuned 64-child pool. Thirty seconds after the load stopped, BookPress released to about 0.3 GB while the WordPress pools held their 0.43 to 1.8 GB. The density page has the memory story in full →
Memory measured on BookPress 0.2.57, 13 October 2026, counting memory shared between processes once.
Two things that travel with every number here.
The point of publishing the stacks is that a reader can check them. So here is what the numbers above do not say.
Page caches are a separate layer
WordPress is measured without a page cache. A page a cache can serve is served from the cache by either setup and does not measure the engine. Every figure here is an uncached dynamic render on both stacks, the state a cart, a search or a logged-in session is always in.
Classic PHP themes are newer ground
WordPress's own classic templates are lighter than its block themes, and BookPress's classic-theme rendering is more recent than its block-theme path: a few of the bundled classic themes still fall back to an error today. The pages above are block themes, which is where WordPress core itself is heading.
Check the numbers yourself
The demo is a real WordPress site with no page cache in front of it. Sign in, publish a post, open the shop, ask for a page no cache could have kept.
Open the live demo