← Blog

Bird CMS Performance: Real Benchmarks

Real measurements from the live site: ~10 ms median server response from a ~3 MB engine with zero dependencies and no database on the hot path. Methodology included.

Bird CMS serves pages in roughly 10 milliseconds on a modest shared VPS, from an engine of about 3 MB with zero runtime dependencies and no database on the hot path. These are real measurements from this very site, not a synthetic lab. Performance depends on your hosting, so treat these as a reference point from one ordinary server.

How this was measured

Everything below was measured on the live bird-cms.com server: a modest Contabo VPS running HestiaCP, PHP 8.3, nginx and php-fpm. The site is shared with other tenants, so this is a realistic floor, not best-case hardware.

  • Server response time is time_starttransfer minus time_pretransfer from curl, which isolates the server's own processing and excludes DNS, TCP connect and the TLS handshake.
  • Each figure is the result of 60 requests with a warm cache, reported as median (p50), minimum and 95th percentile.
  • Engine footprint is du of the engine directory on disk.

Server response time

Measured 2026-06-12 on the live site:

Pagep50minp95
Home (/)10.2 ms8.8 ms16.1 ms
A docs page (/docs/quickstart)14.4 ms11.2 ms30.6 ms
A long article (/blog/bird-cms-vs-wordpress)17.4 ms13.1 ms23.8 ms
The changelog (1,600+ lines of markdown)14.5 ms11.2 ms20.0 ms

Single to low double-digit milliseconds, server-side, on cheap shared hosting. A faster or dedicated host will beat this; a heavily oversubscribed shared host may be slower.

Engine footprint

ComponentSize
Whole engine~3.1 MB
PHP application code (app/)~796 KB
Themes~660 KB
Bundled assets~200 KB
Runtime dependenciesnone (no vendor/, no Composer packages)

For comparison, the approximate install footprints commonly cited for other systems are around 85 MB for a WordPress core install and around 55 MB for Ghost (Node plus its dependencies). Those are published reference figures, not measured here.

Why it is fast

  • No database on the hot path. Content is markdown files; a request reads files, not a database.
  • Markdown parsed once, cached in memory. Repeated requests do not re-parse.
  • No build step and no framework. There is no JavaScript runtime to boot and no compiled asset pipeline in the request path.
  • A small codebase. Less code to load and execute per request.

Honest caveats

  • Numbers are hosting-dependent. This is one shared VPS on a specific day. Your mileage will vary with CPU, neighbours and PHP configuration.
  • Server response is not the same as a pure render microbenchmark. The figures above are full HTTP responses through nginx and php-fpm. An isolated markdown-render microbenchmark is faster than the end-to-end response.
  • The WordPress and Ghost sizes are approximate published figures, included for scale, not benchmarked on this machine.

The takeaway is not a single magic number. It is that a markdown, no-database, no-build engine is small and fast by construction, on hardware that costs a few dollars a month. Want to try it on your own host? Start with the Quickstart.

Frequently asked questions

Is Bird CMS really faster than WordPress?

On equivalent hardware a no-database, no-plugin engine has far less to do per request, so it is typically faster and far smaller on disk. The exact gap depends on the WordPress plugin and caching setup it is measured against.

Do these numbers depend on my hosting?

Yes. The figures here are from one modest shared VPS. A faster host will be quicker and a cheap oversubscribed host may be slower. The relative advantages (no database, tiny footprint, no build) hold across hosts.

What does the 10 ms number actually measure?

It is the median server response time for the homepage: the time the server spends producing the page, excluding network connect and TLS handshake, over 60 requests with a warm cache.

Why is the engine about 3 MB and not smaller?

That includes the PHP application code, the default theme and bundled assets, with zero external dependencies. It is small enough to read end to end, while still shipping Schema.org, sitemaps and an admin panel.