I’ve done enough WordPress speed optimization work to know the pattern: a client hires me after months of trying every caching plugin, every image compression tool, every “performance optimization” checklist on the internet — and their site is still slow. Nine times out of ten, I look at their TTFB and it’s sitting at 800ms or higher. At that point, no plugin is going to save them. The hosting is the problem.

Here’s what I actually look at when evaluating a WordPress host — and why getting this wrong makes every other optimization feel like you’re bailing out a boat with a cup.

1. TTFB is the tell

Time to First Byte is the single metric that exposes your hosting before anything else loads. Run your site through PageSpeed Insights or WebPageTest and look at it. Google’s threshold is under 800ms for a “passing” TTFB — but realistically, anything over 400ms is a sign your server is struggling.

A high TTFB means the server is slow to respond before a single byte of your page reaches the browser. Caching plugins, CDNs, and image optimization all operate after TTFB. If your server takes 900ms to generate a response, you’re already half a second behind before the browser paints anything.

I’ve seen clients with fully optimized themes, object-cache.pro installed, and WP Rocket configured beautifully — still failing Core Web Vitals because their host can’t serve a cached page in under 600ms. That’s a hosting problem, not a plugin problem.

2. PHP version and execution model

WordPress runs on PHP. PHP 8.2 and 8.3 are dramatically faster than 7.4 — we’re talking 15–30% throughput improvements in benchmarks, and those aren’t academic gains. I’ve seen real TTFB drops of 150–250ms just from migrating a PHP version on the same server.

The part most people skip: check whether your host is running PHP-FPM (FastCGI Process Manager) rather than mod_php. PHP-FPM handles concurrent requests more efficiently. On a shared host running mod_php, busy traffic periods cause requests to queue. The symptoms look like intermittent slowness that you’ll never reproduce in a local dev environment.

When evaluating a host, ask explicitly: what PHP version is default, what’s the max available, and which execution model do they use? If they can’t answer the second question, that’s a signal.

3. Server-side caching is non-negotiable

WordPress is dynamically generated. Every uncached page request hits PHP, queries the database, assembles the HTML, and sends it back. That chain is expensive. The solution is server-side caching — storing the generated HTML so that most requests never touch PHP at all.

There are a few layers worth understanding:

  • Full-page cache — stores complete HTML responses. This is what WP Rocket, W3 Total Cache, and server-level caching (like Nginx FastCGI cache) do. If your host supports Nginx-level caching, prefer that over plugin-level caching; it’s faster because it bypasses PHP entirely.
  • Object cache — stores database query results in memory (Redis or Memcached). Without this, even a cached page might still hit the database for logged-in users or uncacheable pages.
  • OPcache — caches compiled PHP bytecode. Should be enabled by default on any competent host. If it’s not, that’s a problem.

Hosts that advertise “built-in caching” often mean they’ve bundled a plugin. That’s not the same as server-level caching. Ask whether Nginx FastCGI cache or Varnish is actually running on the server, not just in the control panel UI.

4. Database performance — the forgotten layer

WordPress leans heavily on MySQL (or MariaDB). Slow queries are one of the most common causes of high TTFB I find during audits, and they’re almost always the result of one of three things: a bloated wp_options table with autoloaded garbage, missing indexes from poorly written plugins, or a database server that’s physically shared across too many sites.

A quick check: install Query Monitor and look at the query count and total query time on a typical page. A well-optimized WordPress page should be doing 20–50 queries and taking under 50ms in total database time. If you’re seeing 200+ queries or 300ms+ of database time, you’ve got a problem that even a great host can only partially mask.

That said, on a cheap shared host, even 30 fast queries can take forever because the database server itself is throttled. A managed host with dedicated database resources makes a measurable difference here.

5. Shared hosting vs. managed WordPress hosting

This is where I’ll be direct: shared hosting is a false economy for anyone running a WordPress site they care about. You’re not just sharing disk space — you’re sharing CPU, RAM, and database resources with dozens or hundreds of other sites. One noisy neighbor can tank your TTFB at 2am for no apparent reason.

Managed WordPress hosts (Kinsta, Cloudways, WP Engine, Flywheel, Rocket.net) cost more — but they provide dedicated containers, automatic PHP-FPM tuning, built-in Redis object caching, server-level full-page caching, and automatic PHP version management. These aren’t luxury features. They’re what makes a WordPress stack perform consistently.

For agencies or developers managing multiple client sites, Cloudways is worth a look specifically because it lets you provision on top of DigitalOcean, Linode, or Vultr — you get managed tooling without being locked into proprietary infrastructure pricing.

6. What I’d actually recommend to a client

When a client comes to me with a slow WordPress site, the first thing I check is their hosting stack — before I touch a single plugin setting. Here’s the rough triage order:

  1. Run WebPageTest and note the TTFB from a cold cache (no CDN). If it’s over 500ms, the host is a suspect before anything else is.
  2. Check PHP version in the host control panel. If it’s on 7.4 or 8.0, upgrading is the easiest performance win available — takes 5 minutes and costs nothing.
  3. Confirm OPcache and Redis are available and actually enabled, not just listed as “supported.”
  4. Look at Query Monitor on the homepage and a typical interior page. Flag anything over 100ms total query time.
  5. Only then consider whether the host itself needs to change. If TTFB is still over 400ms after enabling caching at every layer, a migration conversation is warranted.

The hardest part of this conversation with clients is that hosting feels abstract. They want to tune a plugin slider, not pay $30/month more for a server. But I’ve never regretted recommending a hosting upgrade on a struggling WordPress site. I have regretted spending six hours optimizing a theme on a $4/month shared host that couldn’t sustain 50ms TTFB under any configuration.

If you’re dealing with a WordPress site that won’t pass Core Web Vitals no matter what you try, the WordPress speed optimization service I offer starts with exactly this kind of infrastructure audit — not guessing at plugin configurations. And if you want a second opinion on your current stack before committing to a migration, book a quick call and we’ll dig into the numbers together.