WordPress speed is a common topic, but most guides focus on things you control — caching plugins, image compression, CDNs. Those matter. But the floor your site performs on is set by your host, not your plugins.
Here's what actually controls it.
PHP Workers: The Biggest Lever
Every WordPress page request runs PHP. PHP on shared hosting runs through PHP-FPM, a process manager that maintains a pool of worker processes. When a request comes in, it claims a worker, runs your page, and releases the worker back to the pool.
If all workers are busy, the next request waits. That wait is what causes the "first byte" delay that makes a site feel slow. It's not your theme. It's queue depth.
On an oversold server, PHP worker pools are shared or severely constrained. On our platform, each account gets a dedicated pool. When your site is busy, it only competes with itself.
RAM: Where WordPress Actually Lives
WordPress loads your theme, plugins, and active content into PHP memory for each request. A minimal WordPress install uses around 32MB per request. A WooCommerce store with ten active plugins can use 80–128MB.
If your host caps your PHP memory at 64MB and your store needs 96MB, requests fail with a blank page or a 500 error. You'll see this in your PHP error log as Fatal error: Allowed memory size exhausted.
We don't hide memory limits from customers. Your plan page shows exactly what you get.
Disk I/O: The Silent Bottleneck
WordPress reads a lot of files per request — PHP source files, template files, WordPress core files. On a server where a hundred sites are running on the same disk, I/O contention is real.
We use SSDs across the fleet and separate I/O quotas per customer via cgroups. A site doing a heavy database backup in the background doesn't steal disk throughput from your live traffic.
Database: Shared vs Isolated
Most shared hosts run one database server with all customers' data inside it. A runaway query from one site can degrade response times for everyone.
WordPress on TrueCore uses SQLite — a local database file inside your site directory, with no shared database server at all. There's nothing to contend with. For custom applications on Ember plans and above, we provide a dedicated PostgreSQL database isolated per customer.
What Good Performance Looks Like
A well-configured WordPress site on a properly resourced server should serve cached pages in under 100ms (time to first byte) and uncached pages in under 500ms. If your site is consistently slower than that, the host is the likely cause — not your plugins.
If you're debugging performance, the fastest check is time to first byte with a fresh browser (no cache, incognito window). If that's slow, no amount of frontend optimisation will fully fix it.