Hosting for WordPress performance: TTFB, PHP, and workers

Your host sets the ceiling on how fast a WordPress site can be, and no plugin raises it. Caching hides a slow server until the cache misses, but the moment a request cannot be served from cache, a logged-in user, a checkout, a search, you are back on the raw speed of the machine. So before the clever stuff, get the boring stuff right: a server with real resources, and a modern version of PHP.

Here is what actually matters when you are choosing or judging a host.

TTFB is the number to watch

Time to first byte is how long the server takes to start sending the page. It is the part of speed your host owns. Google’s rough target is a TTFB of 0.8 seconds or less, and it sits underneath everything else: a slow TTFB delays LCP directly, and no amount of image or JavaScript work claws that time back.

Measure it on a warm cache, on a real page. If TTFB is comfortably under that target, your host is probably not your bottleneck, so go optimize the front end. If it is not, keep reading.

Shared, VPS, or managed

Hosting comes in three rough shapes, and the price difference is mostly about who does the work.

Shared hosting puts hundreds of sites on one machine and hopes they are not all busy at once. It is cheap, and it is why a site can be fast at midnight and slow at noon. The neighbors are the problem, and you cannot see them.
A VPS gives you dedicated CPU and memory, which fixes the noisy-neighbor problem, but you, or someone, has to set it up and keep it patched.
Managed WordPress hosting is a VPS with the WordPress-specific work already done: server-level caching, a persistent object cache, sensible PHP settings, staging. You pay more and skip the sysadmin job.

For a client site that matters, I want managed hosting or a properly run VPS with real resources. This one decision usually does more than every plugin tweak combined.

Run a modern PHP version

WordPress is PHP, so the PHP version is a direct speed lever, and upgrading it is close to free. WordPress now recommends PHP 8.3, and newer PHP runs the same site faster with no code changes: benchmarks put recent 8.x versions well ahead of 7.4 on requests per second.

There is a security angle too. PHP 7.4 and earlier are past end of life, so they stop getting security fixes. Staying on an old version to dodge an afternoon of testing is a bad trade. Bump it on staging, click through the site for plugins that complain, then ship it.

PHP workers decide what happens under load

Here is the part the marketing pages skip. A site can have a great TTFB for one visitor and still fall over when traffic arrives, because the server can only run so many PHP requests at once. Those concurrent slots are PHP workers, and cheaper plans cap them low.

When every worker is busy, new requests wait in line, and your fast site becomes a slow one exactly when it matters, during the campaign or the launch you sped it up for. Two things help: caching, because a cached page does not need a worker at all, and a host that gives you enough workers for the traffic you actually get. If a site is fine day to day and collapses under load, this is usually why.

Where the server sits

Distance is latency you cannot optimize away in code. A server in one region answering visitors on the other side of the planet pays for that gap on every request. Put the origin near your audience, and put a CDN in front so cached copies live close to everyone, wherever they are.

Fix this first

Hosting is the floor. Caching, images, and JavaScript are all things you build on top of it, and none of them make up for a server that cannot keep up. So start here: a host with real resources, a modern PHP version, and enough workers for your traffic. Get TTFB into the green, then go spend your effort on the front end.

For the full running order, see how to actually speed up a WordPress site, and for the caching layers that sit on top of a good host, WordPress caching explained.