Two identical WordPress installs on two “unlimited” plans can differ by a factor of five. The difference is invisible in marketing pages because it lives in plan-line items: workers, memory, disk type, and what caches at the server level. Here is how to read a hosting plan the way an engineer does.
PHP workers: the invisible ceiling
Workers are the concurrent PHP processes serving requests. Shared plans typically give 1–4; VPS 8+; managed WordPress hosts 2–12 depending on tier. Every uncached page request occupies a worker until done — low worker counts mean queues, and queues mean TTFB spikes and 503s under load. Ask the host the number; few publish it.
RAM: where MySQL and PHP live
Undersized RAM throttles MySQL’s buffer pool and PHP’s opcache simultaneously. Symptoms: database-heavy pages slow, admin sluggish, the memory-limit errors appearing under normal load. 1GB plans run tiny WordPress; 2–4GB is the realistic floor for a store.
Disk: NVMe vs “SSD” marketing
Older SATA SSDs and NVMe differ 5–10× in random I/O — and WordPress does random I/O constantly (autoloaded options, object cache persistence). A fast disk shows up as snappier admin and faster uncached pages. “SSD” in a 2015 sense is not the same claim as NVMe today.
Server-level cache: the biggest differentiator
Hosts with LiteSpeed or nginx FastCGI page cache deliver double-digit cached TTFB before any plugin — the layer difference measured in the cache comparison. Hosts without it lean entirely on your plugins. If the plan mentions LiteSpeed/NGINX caching, that is worth more than most plugin budgets.
The plan-reading checklist
- PHP worker count (ask if unpublished).
- RAM per site (not “unlimited” — the per-account cap).
- NVMe or equivalent disk, not just “SSD”.
- Server-level page cache available and enabled by default.
- PHP version control — can you choose 8.2/8.3 per site?
- Staging included? The staging workflow depends on it.
- Object cache (Redis/Memcached) offered — the Redis layer needs host support.
When to move (and when not to)
Move when: workers starve under normal traffic, cached TTFB stays past 300ms with everything configured, or support cannot answer the worker/RAM questions. Do not move to escape theme weight — a migration that lands a heavy theme on better hardware fixes one of two problems, per the theme diagnostic.
The free audit reports your current hosting profile’s performance ceilings — worker behavior, cache layers, and disk responsiveness — before you spend on a plan you may not need.
PHP worker count, RAM, NVMe disk, and server-level page cache (LiteSpeed/FastCGI). Together they set your site's ceiling before WordPress optimization even begins. Content sites: 2–4 suffices with caching. Stores with logged-in traffic: 4–8+. Watch for 503s and TTFB spikes under normal traffic — those mean the worker pool is starved. Measurably — WordPress does constant random I/O (autoloads, object cache, uploads). NVMe's 5–10× random-I/O advantage shows up in admin responsiveness and uncached page generation. Optimize first — caching, images, theme diet. If cached TTFB still exceeds ~300ms with everything configured, the hosting tier is the remaining bottleneck and worth the upgrade.What hosting specs matter most for WordPress speed?
How many PHP workers do I need?
Is NVMe hosting actually faster for WordPress?
Should I upgrade hosting or optimize WordPress first?
