Demo of fast, secure Enterprise CMS in Rust for super high traffic websites (400x faster than WordPress)

Benchmark table of stats comparing PageZest with Wordpress and Ghost

Easiest way to demo:

• run pagezest in a docker container. For example:
  • create digitalocean VM in SF datacenter. 2 GB RAM, 1 vCPU
  • run in a Docker container: docker run -p 8080:8080 pagezest/pagezest:latest
• create a VM for running the "Apache Benchmark" program.
  • create digitalocean VM in NYC datacenter. 8 GB RAM, 4 vCPU
  • ab -n 15000 -c 1000 "http://$IP:8080/hello-world"

PageZest goal: to be the fastest, most secure, most reliable enterprise CMS in the world. Specifically...

• fastest website response times (i.e. lowest latency responses)
• secure, unhackable CMS, by sandboxing potentially dangerous plugins.
• reliability: 99.99% uptime SLA.

How are PageZest plugins secure?

The plugins are compiled to WebAssembly, then run in a WebAssembly VM. This means the plugins are sandboxed by default. PageZest CMS can strongly limit exactly what these plugins can do. It means these plugins cannot hack your server, unlike WordPress plugins (I learned this the hard way!).

Technical explanation for why WordPress plugins are unsecure: the underlying PHP VM executes WordPress CMS and WordPress plugins with the exact same privileges. Anything that WordPress CMS can do, so can the WordPress plugins. So just one hacked plugin can lead hackers to downloading lots of hidden files on to your system! If this ever happens to you, you essentially have to destroy the server and start the WordPress installation all over again.

And unbelievably, this happens to about 1% of all WordPress sites every year. 1%!!!

How did we engineer PageZest to be 200-400x faster than Wordpress?

Just a few major technical decisions was responsible for 400x faster.

• For static PageZest websites, the biggest one was simply making plugins static/cacheable by default.
  • We are aiming to design plugins like React components – if the input didn't change, then the output didn't change, and we cache based on a hash of the input.
• For dynamic PageZest websites, the biggest one was: NO JSON!!! Using FlatBuffers (zero-parse step!!)
  • for dynamic pages, this was the biggest speedup by far, amazingly. There's a good reason why Google uses FlatBuffers for their internal RPC system instead of JSON. Parsing JSON requires a significant amount of mallocs, and malloc is a very non-trivial implementation.
• Rust!! (Not PHP). Self-explanatory. You can look at any one of the many programming language benchmarks. Rust floors PHP, every time. 5-10x faster.
• WebAssembly for plugins.

How static/cacheable plugins work

This deserves a brief explanation because I think it's quite cool:

• Inspired from React components.
• Similar to React's useEffect API.
• An "input" attribute specified in the plugin's manifest JSON.
• By default, plugins are static/cacheable.
  • there will be an attribute that plugin writers can specify, to disable caching of the plugin. Like "disable_cache: true".
• If the input didn't change, then output didn't change.
  • so take a hash of the input.
  • use the hash to map hashtable from input to output.
• Concrete example:
  • input could be: "URL", or "URL param"
  • the output of the plugin would be the same every time for that URL.

Why static/cacheable plugins are really useful

Because most of the top Wordpress plugins can be easily static/cached

• Yoast SEO: output is almost always the same for a given URL
• Translation plugins: same.
• Cookie banner for consent
• Google analytics plugin
• custom HTML blocks.
• WPForms
• Any webpage widget

How are the files structured in PageZest:

• pagezest: a single binary with the dashboard (pz-admin) files compiled into it.
• plugins/ directory
  • toc/ directory
    • toc.wasm
  • footer/ directory
    • footer.wasm

How we benchmark PageZest against Wordpress and Ghost

Hardware requirements:

• 2 GB RAM, 1 vCPU VM used for all tests. No SSL setup. Located in DigitalOcean's SF datacenter.
• IMPORTANT: need yet one more VM to run benchmark from. We used a 8 GB RAM, 4 vCPU server in DigitalOcean's NYC datacenter.
  • DO NOT run Apache Benchmark from your own home network!! As we found out the hard way, my ISP was rate-limiting the number of open connections I could have. During development, couldn't get over 200 RPS. Once we tested on a DigitalOcean server, we immediately got over 650 RPS. 3800 RPS was later achieved with more optimizations.

We used Apache Benchmark (ab) to measure request per second:

• These are the ab parameters we used for wordpress+ghost ab -n 1000 -c 16 "$URL"
• Because PageZest was so much faster, we needed to increase the parameters significantly in order to fully saturate the CPU: ab -n 15000 -c 1000 http://$IP:8080/hello-world

Wordpress

• Setup using DigitalOcean image
  • this means we run this benchmark on a Wordpress with 0 plugins.
  • Usually Wordpress will have 10-20 plugins ==> significantly smaller request/second. See Kinsta's numbers.
  • Woocommerce, even worse.
• Run: ab -n 1000 -c 16 "http://$IP/index.php/2025/05/03/hello-world/

Ghost

• Setup using DigitalOcean image
• Run: ab -n 1000 -c 16 http://$IP/hello-world/

PageZest

• Easiest way is probably to run PageZest as a Docker container: docker run -p 8080:8080 pagezest/pagezest:latest .
  • alternative is for you to compile the UI, plugins, server from source.
• Run: ab -n 15000 -c 1000 "http://$IP:8080/hello-world"

Optimizations that did NOT help PageZest become much faster

It was quite instructive and surprising to us what didn't help. We'll write these down to help other learn:

• Using the filesystem to store blog posts instead of sqlite.
  • actually, this resulted in a big performance regression from 2200 RPS to 400 RPS.
  • the performance regression was due to the blog posts no longer being cached in memory. So each request was now reading from the filesystem. Lots of syscalls. Very slow.
  • as it turns out, sqlite was caching relevant rows in memory.
• using actix web server instead of tiny-http
  • we thought actix and tokio's green threads would help.
  • Since we are benchmarking on a 1 vCPU VM, it didn't really help.

Can PageZest be made even faster?

Yes, but not that much faster. The theoretical maximum we found was 6500 RPS, using Anton's basic actix server he used for his own benchmarking youtube video. PageZest is already at 3600-3800 RPS. The main speedup I see is if PageZest cached the whole page in-memory instead of only static plugin output. Then static PageZest sites could deliver 6000+ RPS.

What's next for PageZest?

We want to launch a managed hosting service, with a generous free tier (your own custom domains allowed!). If you are interested, please sign up to the PageZest email list (see bottom of this webpage). Email List signups are the primary way we evaluate whether people are really interested in what we are doing.

Feature-wise, we want to release good looking themes so people can have decent looking websites.