WordPress speed is not a single number, it is a stack. Each request runs through PHP-FPM workers, hits a database, then either gets cached at one of five layers or rebuilds from scratch. This page documents what actually happens on each request and which hosts enable which layers. Companion to the 2026 speed leaderboard.

Anatomy of a WordPress Page Request

An uncached WordPress request crosses eight stages before the first byte reaches the visitor, and every stage is a place where hosts differ:

1. DNS resolution, the browser turns your domain into an IP. Usually 5-30ms with a decent DNS provider; effectively free on repeat visits.
2. TCP handshake, one round trip to the server. This is pure physics: distance to the origin sets the floor, which is why geography dominates remote-region TTFB.
3. TLS negotiation, one to two more round trips. Modern hosts with TLS 1.3 and session resumption pay this once, not on every request.
4. Web server accept, LiteSpeed, NGINX, or Apache picks up the request. If a full-page cache holds the rendered HTML, the response leaves here and PHP never runs, this is the single biggest speed multiplier a host can enable.
5. PHP-FPM worker, on a cache miss, a free PHP worker loads WordPress core. If all workers are busy, the request queues, this is where slow hosts fall over under load.
6. OPcache, compiled PHP opcodes are reused instead of recompiled. Without it, every request re-parses tens of thousands of lines of PHP.
7. MySQL queries, core, theme, and plugins query the database; a Redis object cache answers repeat queries from memory instead of disk.
8. Response, WordPress assembles the HTML through output buffering and hands it back. TTFB is everything up to here.

The stack below determines how many of those stages a given host can skip or accelerate.

The 5-Layer Cache Stack

WordPress speed multiplies when all five layers cooperate. Each layer addresses a different bottleneck. ScalaHosting and Kinsta enable all five out of the box; budget shared hosts typically enable two or three.

• Browser cache, static asset reuse across page loads. All hosts support this.
• CDN / edge cache, serves cached HTML and assets from a node near the visitor. Cloudways, Kinsta, and Rocket.net include this.
• Full-page cache, stores rendered HTML so PHP does not execute on cached requests. LiteSpeed Cache on LiteSpeed hosts, FastCGI cache on NGINX hosts.
• Object cache (Redis), stores database query results in memory. ScalaHosting, Cloudways, ChemiCloud, Kinsta include it.
• OPcache, caches compiled PHP opcodes. All serious hosts enable this.

The per-host stack table below shows which of these layers each host ships enabled.

PHP Workers Explained

PHP workers are the parallel processes that execute WordPress PHP code. When all workers are busy, new requests queue. When the queue fills, visitors get 503 errors or timeouts. Shared hosting typically allocates 2-4 workers per account; a managed VPS allocates 30 or more.

Per-host worker counts, queue behavior under load, and the math of concurrent checkout sessions will be filled in during the next research pass.

How Hosts Compare

The stack each host ships out of the box, from our 2026 test cycle, alongside the idle TTFB it produces:

Read the table top to bottom and the pattern is hard to miss: every host under 100ms pairs modern CPUs with NVMe storage and a server-level cache; the hosts above 150ms are missing at least one of the three. The web server label matters less than what is enabled on it, SiteGround's NGINX with SG Optimizer beats Hostinger's LiteSpeed with CPU-seconds throttling. Per-layer multiplier data (how much each cache layer buys on each host) lands in the next research pass.

For the jargon used on this page, see LiteSpeed vs Apache vs NGINX, cache layers explained, and NVMe vs SSD storage.

Back to the full speed comparison: Fastest WordPress Hosting 2026.