Most WordPress speed advice opens with plugins and image compression. Useful, sure, but it skips the thing that actually decides how a page feels: the server underneath it. You can stack every caching plugin ever shipped, and if your host dropped you on an oversold node with tired disks and PHP 7.4, the site still crawls. Genuinely fast WordPress hosting comes down to hardware, PHP version, and how many other accounts are elbowing you for the same CPU. Nail those three and the plugins become polish instead of life support.
I've moved a lot of sites off "cheap" plans that turned out to be expensive in every way that counts. Here's what to actually look for, what the marketing quietly hides, and how to prove a host is quick before you hand over a card.
What makes WordPress fast at the host level
WordPress is a PHP application talking to a MySQL or MariaDB database. Every uncached request runs PHP, fires off queries, assembles HTML, and ships it back. The speed of that chain is what you're buying. A handful of things move the needle far more than the rest, so start there.
NVMe storage, not SATA SSD (and definitely not spinning disks)
WordPress touches a lot of small files: core, themes, plugins, uploads, the database itself. NVMe drives chew through those small random reads several times faster than an older SATA SSD, and you feel it most in wp-admin. Editing a post, saving Elementor changes, running a batch of plugin updates: all disk-heavy work. If a plan page doesn't say NVMe, assume it isn't there. Our NVMe web hosting and managed WordPress hosting both run on NVMe as standard, because in 2026 there's no reason to ship anything slower.
PHP 8.3 or newer, with OPcache on
This is free performance and people still leave it sitting on the floor. PHP 8.3 runs roughly twice as fast as 7.4 on typical WordPress workloads, and 8.4 is already out. If a host still defaults fresh installs to PHP 7.x, that tells you exactly how much attention they pay. Check yours under Tools, then Site Health in wp-admin, or in your control panel's PHP selector.
OPcache earns its keep too. It holds compiled PHP bytecode in memory so the server stops re-parsing your code on every request. It should be on by default. If you have shell or php.ini access, confirm opcache.enable=1 and give it a reasonable ceiling (128MB is plenty for one busy site). A host that ships OPcache off is either misconfigured or throttling you, and neither is a great sign.
Object caching with Redis
Page caching stores finished HTML. Object caching is quieter and does something different: it holds the results of database queries in memory, so repeat lookups stop hammering MySQL. For anything logged-in-heavy (WooCommerce, membership sites, a busy comment section) a persistent object cache on Redis is the biggest win after PHP version. Drop in the Redis Object Cache plugin, point it at the socket, and admin pages that dragged at 1.5 seconds come back in around 400ms. Ask any prospective host whether Redis is available and included. Plenty of budget plans simply don't offer it, and that gap shows up the moment your site gets real.
HTTP/2 and HTTP/3, plus current TLS
A single WordPress page pulls in dozens of assets: CSS, JS, fonts, images. HTTP/2 lets the browser grab them over one connection instead of opening a fresh one per file. HTTP/3 over QUIC trims more still, especially on shaky mobile. Any decent host has run HTTP/2 for years; HTTP/3 is the tell that they keep their stack current. Open your browser's network tab and check the Protocol column: it'll read h2 or h3.
A datacenter close to your visitors
Physics doesn't care how clever your caching is. If your readers are in Europe and your server sits in the US, every request burns 100ms or more of round-trip latency before the box lifts a finger. Put the server near the audience. We run in Frankfurt, London, and Gravelines precisely so European sites get low latency without leaning on a CDN to fake it. A CDN helps with static assets, but the first byte of HTML still comes from origin, so where origin lives matters.
Why "unlimited" shared plans quietly throttle you
Here's the bit the pricing page won't spell out. "Unlimited storage" and "unlimited bandwidth" are marketing, not engineering. What is never unlimited is CPU time, RAM, and I/O throughput, and those three are exactly what WordPress leans on.
Oversold shared hosts cram hundreds of accounts onto one machine and enforce hidden per-account caps: a limit on concurrent PHP processes (often 1 or 2 on entry plans), an I/O rate limit, an "entry processes" or CPU-seconds ceiling. Bump the ceiling and your requests get queued or thrown a 508. You experience it as random slowness at peak hours, or a WooCommerce checkout that stalls when three people buy at once. The disk is "unlimited," but you get one PHP worker, so the disk hardly matters.
To smoke this out before you buy, go looking for the real limits instead of the unlimited claims. A host that's confident in its performance will tell you the PHP worker count, the per-site memory limit, and whether there's an I/O throttle. If those numbers are nowhere and everything is just "unlimited," you have your answer. Vague specs usually mean the specs wouldn't flatter anyone.
How to test TTFB honestly
Time to First Byte is how long the server takes to start sending a page after the browser asks. It's the cleanest single number for host speed because it isolates server work from your front end. It's also easy to measure badly and fool yourself, so do it properly.
- Warm the cache, then measure. The first hit after a purge is always slow because it's building the cache. Load the page twice and record the second. You want steady state, not a cold start.
- Test the URL directly with curl. Run curl -w "%{time_starttransfer}\n" -o /dev/null -s https://yoursite.com/. That prints TTFB in seconds. Fire it five or six times and read the spread, not one lucky result. Under 0.2s from a nearby location is good; consistently over 0.6s on a cached page means the server, not your theme, is the problem.
- Hit an uncached, logged-in path too. Cached homepage TTFB flatters everybody. Load wp-admin, or tack a cache-buster query string on the URL, so PHP and the database actually run. That's where oversold hosts fall apart and where Redis and a current PHP version earn their money.
- Measure from where your visitors sit. A test node in the same city as your host will always look fast. Use a tool that lets you pick the origin of the test and choose one near your real audience. If most readers are in Berlin, a Frankfurt origin should come back in well under 100ms of network time.
- Compare like for like. Same install, same theme, same plugin list, moved between hosts. It's the only way to know you're measuring the host and not your own setup. Our free migrations exist partly for this: move a copy, benchmark it, keep whichever is faster.
One honest caveat. TTFB is a server signal, not the whole picture. A quick server behind a bloated page builder loading 40 render-blocking scripts still feels sluggish to a human. Fix the host first, then the front end. Once the server is sorted and you're chasing the browser-side half, our guide to five ways to speed up your website covers caching plugins, image formats, and thinning out the plugin pile.
Putting it together when you switch
If you've decided the host is your bottleneck, the move itself is the part that feels scary, and it really doesn't need to. The order that works: stand the site up on the new host, run the TTFB and admin-speed checks above, confirm PHP 8.3 or newer, OPcache, and Redis are genuinely active, and only then point DNS at it. That sequence lets you prove the speed win before a single real visitor lands on the new box. We walk the whole thing in how to migrate a website with no downtime, including the DNS TTL trick that keeps the cutover clean.
Honestly, for most people running a business site or a store, managed fast WordPress hosting on NVMe with Redis and a current PHP beats squeezing another month out of a shared plan. You stop babysitting resource limits and get your evenings back. If you're curious whether your site feels different on a stack tuned for exactly this, spin up a copy on our WordPress hosting and run the same curl test side by side. That'll tell you more than any spec sheet ever could.