This page names no hosts and ranks nothing. Host performance changes with plans, data centres and ownership, so any ranking published today is wrong within a year — and the reader who needs it most cannot verify it anyway.
What does not change is what to check. Eight requirements, one number that tells you whether hosting is even your problem, and a test you can run before you commit.
First: is your host actually the bottleneck?
One number answers this. Time to First Byte.
TTFB is the time before the browser receives a single byte of your HTML, and web.dev's benchmark is that "most sites should strive to have a TTFB of 0.8 seconds or less", with anything above 1.8 seconds considered poor.
How to read your result:
| TTFB | What it means |
|---|---|
| Under 0.5s | Hosting is not your problem. Fix images and JavaScript instead |
| 0.5–0.8s | Fine. Improvable, but not where your gains are |
| 0.8–1.5s | Worth investigating — often a missing page cache rather than the server |
| Over 1.5s | Something is genuinely wrong: no caching, an old PHP version, an overloaded server, or a plugin doing work on every request |
Test logged out, in a private window, on a page that should be cached — and test more than once, because the first hit may be building the cache that the second one serves.
Two things before you blame the host. A missing page cache produces a bad TTFB on perfectly good hosting, and so does a plugin running expensive work on every request. Rule both out first — the methods are in WordPress caching explained and how to audit your WordPress plugins.
And note what TTFB is not. It is not a Core Web Vital — web.dev says so directly: "Because TTFB isn't a Core Web Vitals metric, it's not absolutely necessary that sites meet the 'good' TTFB threshold." It matters because it is the floor under LCP, not because it is assessed.
The eight things to verify
Not features to compare. Things to confirm before you buy, each of which you can ask about in one sentence.
1. Current PHP, and a way to change it yourself
WordPress's guidance is unambiguous: "Making sure you're running the latest version of Linux (or Windows), Apache, MySQL/MariaDB, and PHP is essential."
Ask two things: which PHP versions are offered, and whether you can switch versions from the control panel without a support ticket. The second matters more than the first, because it is what lets you test a version change and roll it back in minutes.
2. Server-level page caching, or the freedom to install your own
One or the other, clearly stated. A host that caches at server level saves you a plugin. A host that does not should not object to you installing one.
The bad answer is ambiguity, because that is how sites end up with two page caches. Layers and why doubling them causes bugs: WordPress caching explained.
3. A persistent object cache backend, if you have logged-in users
Redis or Memcached, available on your plan. WordPress's own guidance is that "Using a persistent Object Cache helps speed up page load times by saving on trips to the database from your web server."
This is the single clearest dividing line between plans for a shop or membership site, because logged-in traffic is exactly what a page cache cannot serve.
If your site is a blog with no logged-in visitors, skip this requirement entirely. It buys you very little.
4. Resources that are yours, and stated limits
The question is not "is it shared hosting" but "what are my limits and what happens when I hit them."
Ask for the numbers: memory, PHP workers or concurrent processes, and database connections. A host that will not state them is telling you something.
Why it matters practically: exhausted database connections produce an intermittent "error establishing a database connection" rather than a slow site — a failure that looks like corruption and is not. That distinction is covered in error establishing a database connection.
5. Staging, with a one-click copy both ways
This is a performance feature. Every measurement worth making — SAVEQUERIES, plugin deactivation, a PHP version change — should happen somewhere that is not your live site.
Ask whether staging is included or extra, and whether pushing back to production is one action or a manual database export.
6. Backups you can restore yourself, and a stated retention
"We take daily backups" is not the answer. The answer is how far back they go, whether you can restore without a ticket, and how long a restore takes.
Test it once, immediately after signing up, while nothing is at stake. What makes backups actually survivable is in WordPress backups: what most people get wrong.
7. Server location, or an edge that compensates
If your visitors are concentrated somewhere, your server or your edge cache should be too. Distance is latency and there is no software fix for it.
A CDN in front of a distant server helps static assets a great deal and the HTML not at all — unless you are doing full-page edge caching, which is a bigger commitment than most people realise.
8. Support that will answer a technical question
Test this before you buy, not after. Send a pre-sales question specific enough that a script cannot answer it — the PHP versions offered, or whether Redis is available on the plan you are considering.
A vague or scripted reply now is a vague or scripted reply during an outage.
What is not on the list
Deliberately, because these are how hosting is sold rather than how it performs.
- "Unlimited" anything. Nothing is unlimited; there is a limit and it is not published, which is worse than a stated one
- Uptime percentages. Almost universally quoted, rarely meaningful at the resolution that affects you, and never accompanied by the compensation terms
- Bundled premium plugins. A licence is not performance, and bundled plugins are frequently the heaviest thing on the site
- Speed claims with a number attached. Measured on what page, with what content, from where? A host's own benchmark is a marketing asset
- Awards and "fastest host" rankings, including the ones that look independent. The economics of that category are affiliate economics
- Price alone. The cheapest plan that meets the eight requirements is a good decision; the cheapest plan is not
The pattern: everything on the eight-point list is verifiable before you pay. Everything on this list is a claim.
Deciding whether to move
Six steps, in order. Most people who ask this question do not need to move.
Step 1 — Measure TTFB properly
Logged out, private window, a page that should be cached, more than once. Write the number down.
Step 2 — Rule out the two software causes
Is there exactly one page cache running? And is anything doing expensive work on every request? Fixing either can take a 1.5-second TTFB under 0.5 without changing host.
Step 3 — Try the free host-side change first
Move to the current PHP version on staging, test, and measure again. It costs nothing and it is the largest free improvement available on an old install.
Step 4 — Ask your current host the eight questions
You may already have what you need and not be using it. Object caching sitting unused on the plan you are paying for is extremely common.
Step 5 — If you are moving, verify before migrating
Ask the eight questions of the new host in writing, and test their support with one of them.
And migrate to staging first if they offer it, so you can measure the same page on both before switching DNS.
Step 6 — Re-measure the same page after the move
Same page, same conditions, same time of day. A migration that did not change TTFB has told you the host was never the problem — which is worth knowing, even though it is not the answer you wanted.
The honest summary
Hosting matters, and it matters less than the hosting industry's marketing budget implies.
For a content site with a working page cache and a current PHP version, the gap between competent hosts is smaller than the gap between an optimised and an unoptimised theme. For a shop with logged-in traffic and no object cache, the host is very often the whole problem.
Which of those you are decides how much of this page applies to you. The lever ordering that puts it in context is in speed up WordPress.
Frequently asked questions
Does hosting affect WordPress speed?
Yes, mainly through server response time, which is the floor under Largest Contentful Paint. But a missing page cache or a plugin doing work on every request produces the same symptom on good hosting, so rule those out before concluding the host is at fault.
What is a good TTFB for WordPress?
web.dev recommends most sites strive for 0.8 seconds or less, with above 1.8 seconds considered poor. TTFB is not itself a Core Web Vital, but it is dead time inside LCP, so a high value caps how good LCP can be.
Is managed WordPress hosting worth it for speed?
It depends what it includes. Server-level caching, a persistent object cache backend, staging and current PHP are the things that affect speed. If a cheaper plan offers all four, the label matters less than the list.
Do I need Redis or Memcached for WordPress?
Only if you have meaningful logged-in traffic — a shop, a membership site, a busy admin. A persistent object cache serves the requests a page cache cannot. For a blog with no logged-in visitors it buys very little.
Will moving hosts fix my slow WordPress site?
Only if server response time is the problem. Measure TTFB first, rule out a missing page cache and a heavy plugin, and try the current PHP version. A migration that does not change TTFB proves the host was never the issue.
Does updating PHP make WordPress faster?
Usually yes on an older install, and it is free. WordPress's own guidance is that running current versions of PHP and the database server is essential. Test on staging first, because very old plugins may not be compatible.
Should I trust "fastest WordPress host" rankings?
Treat them cautiously. Most are affiliate-funded, and results depend on the plan, the data centre and the test page. The eight requirements on this page are verifiable before you pay; a ranking is not.
What questions should I ask a host before buying?
Which PHP versions are offered and whether you can switch them yourself; whether they cache at server level; whether Redis or Memcached is on the plan; the stated memory, worker and connection limits; whether staging is included; backup retention and self-service restore; server location; and one technical pre-sales question to test support.
What to do next
Measure your TTFB on a cached page, logged out, twice. If it is under half a second, hosting is not your bottleneck and this page has saved you a migration.
If it is over a second, check whether you have exactly one page cache running before you check anything else. That single question resolves a large share of the cases that look like a hosting problem.
Related guides
- Speed up WordPress: what actually moves the number — where hosting sits among the levers
- WordPress caching explained — the layer that fixes most bad TTFB
- How to audit your WordPress plugins — the other cause of a slow server response
- Core Web Vitals for WordPress — why TTFB caps LCP
- Error establishing a database connection: fixed — when limits are hit rather than approached
- WordPress backups: what most people get wrong — the requirement worth testing on day one
The short version
- Measure TTFB properlyLogged out, private window, a page that should be cached, more than once. Write the number down before changing anything.
- Rule out the two software causesConfirm exactly one page cache is running, and check whether anything is doing expensive work on every request. Either can take a 1.5-second TTFB under 0.5 without changing host.
- Try the free host-side change firstMove to the current PHP version on staging, test, and measure again. It is the largest free improvement available on an older install.
- Ask your current host the eight questionsYou may already have what you need and not be using it u2014 object caching sitting unused on the plan you already pay for is common.
- If you are moving, verify before migratingAsk the eight questions in writing, test support with one of them, and migrate to staging first so you can measure the same page on both.
- Re-measure the same page after the moveSame page, same conditions, same time of day. A migration that did not change TTFB has told you the host was never the problem.
The WordPress Email Delivery Checklist
Stop your WordPress emails from failing silently. Get the complete setup guide.
Muhammad Basim has worked in digital marketing since 2013, focused on email deliverability and AI-assisted content production. He is the author of The Email Deliverability Playbook and The Email Copywriting Playbook.
Related Articles
Choosing a WordPress SEO Plugin
This page names no winner, and the reason is that the choice matters far less than the category's marketing implies. The major WordPress SEO plugins do the same six things. They have converged, they will continue to converge, and the difference between them is interface preference and a small number of features most sites never […]
Two-Factor and Login Hardening for WordPress
Login attacks against WordPress are constant, automated and indiscriminate. Every public WordPress site receives them, regardless of size or traffic, because the cost of trying is near zero. They are also the least successful route into a WordPress site. Vulnerable plugins account for more compromises than password guessing, which is worth holding onto — login […]
WordPress Email: Why Your Site’s Emails Never Arrive
WordPress sends email in a way that fails modern authentication by default, and it reports success while doing it. That combination is why this problem is so persistent. The site is not broken. Nothing is logged. wp_mail() returns true, the order is placed, the form says thank you — and the message never reaches an […]