Last summer I got a panicked Slack message from a client whose recipe blog had finally caught a wave: a single Pinterest pin landed them at roughly 100,000 monthly pageviews, mostly bursty traffic from 7–9pm. Every evening their site went down for ten to twenty minutes. The host’s response was the same every time: “You’ve exceeded your CPU allocation. Please consider upgrading.” They were on a $4.99/month shared plan that promised “unlimited everything.”
That client is the reason I push back hard whenever a founder tells me hosting is a commodity. It is not. The difference between a site that takes 1.8 seconds to render and one that takes 6 seconds is almost never the theme or the plugins — it’s where the PHP is executing and how the cache is configured. After ten years of running and migrating WordPress sites for clients ranging from law firms to media properties doing 4 million monthly sessions, I have strong opinions about what each hosting tier actually delivers. This is the comparison I wish someone had handed me when I started.
The four categories, as they actually exist in 2026
Marketing pages have blurred the lines on purpose. Bluehost calls one of its products “managed WordPress hosting.” It is not. Cloudways calls itself “managed cloud.” That one’s closer. Here is how I think about the categories at the infrastructure level, which is the only level that affects your TTFB.
1. Shared hosting ($3–12/month)
Hundreds of sites — sometimes thousands — share one virtual machine. CPU and RAM are oversubscribed, meaning the host bets that not everyone will spike at once. You get cPanel or a clone, a one-click WordPress installer, and a single PHP-FPM pool you cannot tune. Examples: Bluehost Basic, SiteGround StartUp, Hostinger Premium, Namecheap Stellar, GoDaddy Economy.
This tier is fine for a portfolio with 500 monthly visits. It is not fine for anything monetized.
2. Managed WordPress hosting ($25–150+/month)
An opinionated, WordPress-only stack. The host runs server-level caching (NGINX FastCGI cache or LiteSpeed), maintains PHP/MariaDB versions, runs daily backups, restricts certain plugins, and patches WordPress core for you. The good ones (Kinsta, WP Engine, Pressable, Pantheon, Flywheel) operate on top of GCP, AWS, or their own bare-metal fleets. Pricing scales with monthly visits, not raw resources.
3. VPS hosting ($5–100/month)
You rent a slice of a real server with dedicated CPU cores, dedicated RAM, and a fixed IP. The host gives you Ubuntu and SSH; everything else is on you, unless you layer a panel like RunCloud, GridPane, ServerPilot, or SpinupWP on top. Examples: DigitalOcean, Linode (now Akamai), Vultr, Hetzner Cloud, OVHcloud.
Hetzner’s CX22 at €3.79/month is the best price-to-performance VPS I’ve ever benchmarked, but you need to be comfortable in a terminal — or pay $9–15/month for a panel.
4. Cloud hosting ($10–500+/month)
Pay-per-use compute on hyperscaler infrastructure. Cloudways is technically a managed layer over DigitalOcean, AWS, GCP, Linode, and Vultr. AWS Lightsail and Google Cloud’s Click-to-Deploy are entry points to the hyperscalers themselves. Render and Railway are newer, app-platform-style options. The defining trait is horizontal scalability: you can add a node, switch to load balancing, or swap your database to a managed instance without rebuilding.
What each tier actually feels like under load
I run a default Twenty Twenty-Four install on most providers I evaluate, with the same set of plugins (Yoast SEO, Contact Form 7, WooCommerce stub, WP Rocket where it’s allowed). I measure TTFB from three regions and p75 LCP via real-user monitoring once the site has at least 1,000 sessions. These are ranges I’ve consistently seen — treat them as “in our experience” figures, not lab guarantees.
- Shared (Bluehost, Hostinger): TTFB 600–1,200ms cold, sometimes 2,000ms+ during peak. p75 LCP rarely under 3.5s without aggressive plugin caching. Concurrency falls apart around 30–40 simultaneous PHP requests.
- SiteGround GoGeek (still shared but their best tier): TTFB 300–700ms, holds up reasonably to 75 concurrent users.
- Kinsta / WP Engine: TTFB 100–300ms when their server cache hits, 400–800ms uncached. p75 LCP commonly under 2.0s with a decent theme.
- Cloudways DO Premium 2GB: TTFB 150–350ms with their built-in Varnish/Redis. Genuinely competitive with managed hosts at half the price.
- Hetzner CX22 + RunCloud: TTFB 80–200ms in EU, 250–400ms in US. Cheapest per-millisecond option I know of.
The single biggest determinant is whether full-page caching happens at the web server (NGINX/LiteSpeed) or inside PHP via a plugin. Server-level caching is roughly an order of magnitude faster for cold cache hits.
Realistic traffic ceilings
People over-budget for hosting they don’t need and under-budget for hosting they do. Rough rules I use:
- Shared: healthy up to about 10,000 monthly active users if your content is mostly static and you’ve installed a real cache plugin. Beyond that you’ll see daily slowdowns.
- Managed WordPress: comfortable from 10k to several million MAU depending on plan, with the host absorbing most of the operational burden.
- VPS: ceiling is your skill, not the hardware. A well-tuned $20 droplet with Redis object cache can serve hundreds of thousands of MAU. A misconfigured one chokes at 5,000.
- Cloud (auto-scaling): effectively unbounded, but your bill scales linearly with traffic if you don’t cache aggressively.
Features that actually matter
Hosting feature lists are designed to confuse. Here are the ones that move the needle, in order:
- Server-level page caching. Non-negotiable above 5,000 visits/month. NGINX FastCGI, Varnish, and LiteSpeed are the three real implementations.
- A real staging environment. One-click push-to-live with a database merge option. SiteGround, Kinsta, WP Engine, and Pressable all do this well. Bluehost’s “staging” on shared plans is a separate subdirectory you have to migrate manually.
- Automated daily off-site backups with at least 14 days of retention. Verify they are off-site — some hosts “back up” to the same disk.
- PHP version control. The ability to switch between PHP 8.2 and 8.3 from a UI without a support ticket.
- Free SSL via Let’s Encrypt or AWS Certificate Manager. If a host charges for SSL in 2026, run.
- CDN included or trivially attachable. Cloudflare integration, Bunny.net, KeyCDN, or a host-native edge.
- SSH and WP-CLI access. If you can’t SSH in, you can’t debug a stuck cron or rotate keys.
- Object caching via Redis or Memcached. Critical for WooCommerce and membership sites.
NGINX vs Apache matters less than people think now that mod_php is mostly retired and PHP-FPM is standard. LiteSpeed is genuinely faster than both for WordPress because of its native LSCache integration, but it’s only a real choice on a handful of hosts.
Managed hosting trapdoors
Managed hosting is what I recommend most often, but the marketing leaves out the rough edges. Be honest with yourself about these before you commit:
- Overage fees. Kinsta charges $1 per 1,000 visits over your plan. WP Engine charges $2 per 1,000. Pressable is more forgiving with its fair-use model. A viral post on a Starter plan can cost you a surprise $200.
- Plugin restrictions. Most managed hosts ban WP Rocket, W3 Total Cache, WP Super Cache, and other caching plugins because they cache at the server level. Some also ban backup plugins (UpdraftPlus on WP Engine), related-posts plugins that hit the database hard, and anything that writes to the file system at runtime.
- Vendor lock-in. Kinsta’s backups are proprietary tarballs that aren’t directly importable elsewhere without unpacking. Pantheon’s Pressflow-style fork of WordPress core has subtle behavioral differences. Migrating off can be a weekend of work.
- No SSH on cheaper plans. WP Engine’s Startup tier doesn’t include SSH gateway access. You’re stuck with their UI for everything.
- Custom services are forbidden. You cannot run a Node.js sidecar, a Redis you control, or a separate Python worker. If your stack is anything more than “just WordPress,” managed hosting will fight you.
When NOT to use managed WordPress hosting
Despite being the default recommendation for most businesses, managed hosting is wrong for several real cases:
- You’re running a hobby site or local nonprofit with under 5,000 monthly visits and a hard $10/month budget. Buy a Hetzner CX22 or stay on shared — managed is overkill.
- Your team never customizes WordPress at the code level. You will pay for engineering features you never use.
- You need to colocate WordPress with non-WordPress services in the same VPC — an internal API, a queue worker, a reverse proxy. Managed hosts won’t let you in.
- You’re building a multi-tenant SaaS on top of WordPress Multisite. Most managed hosts charge per-network and limit subsite counts harshly.
The comparison table
| Provider | Tier | Price/mo (entry) | Caching | Staging | Best for |
|---|---|---|---|---|---|
| Bluehost Basic | Shared | $2.95 intro / $11.99 renewal | None at server level | Manual | First WordPress site, low traffic |
| SiteGround GoGeek | Shared (premium) | $7.99 intro / $44.99 renewal | SG Optimizer + NGINX | One-click | Agencies running 10–15 small client sites |
| Kinsta Starter | Managed (GCP) | $35 | NGINX FastCGI + Edge Caching | One-click + selective push | Serious sites 25k–50k visits/mo |
| WP Engine Startup | Managed | $24 (annual) | EverCache (Varnish-based) | 3 environments included | US-focused agencies, established product sites |
| Cloudways DO Premium 2GB | Managed cloud | $30 | Varnish + Redis + Breeze | One-click clone | Performance per dollar, WooCommerce |
| Hetzner CX22 + RunCloud Pro | VPS + panel | ~€3.79 + $9 = ~$13 | NGINX FastCGI / Redis (DIY) | RunCloud staging add-on | Technical owners who want control + low cost |
A decision framework that actually works
Forget the “best hosting” lists. Walk these four questions in order:
Traffic. Under 5,000 monthly visits and you can stay on shared without anyone noticing. 5,000 to 50,000 is the sweet spot for managed entry plans or Cloudways. 50,000 to 500,000 means a managed plan above the entry tier or a properly tuned VPS. Above 500,000 you should be discussing dedicated infrastructure or autoscaling cloud, not picking from a brochure.
Budget. Under $15/month forces you into shared or a bare VPS. $25–50 unlocks Cloudways and entry-level managed. $100+ opens up serious managed plans and bigger VPS instances with object caching headroom.
DevOps comfort. If you’ve never SSHed into a server, do not buy a raw VPS to save $20/month. The first time MariaDB crashes at 2am you will pay back the savings in lost sleep. Use managed or a VPS-with-panel like RunCloud or GridPane.
Team size. Solo operators benefit most from managed because the host handles ops. Teams of 3+ with a developer can get more out of a VPS or cloud setup because they can split the operational work.
Run those four through your situation and the answer usually picks itself. A solo blogger doing 30k visits at a $50 budget? Cloudways or Kinsta Starter. A 5-person agency hosting 40 client sites at $300/month total? GridPane on a beefy Vultr instance. A WooCommerce store doing $80k/month in revenue? Don’t cheap out — Kinsta Pro or WP Engine Growth, full stop.
Migrating without taking your site down
Migration is where most people lose data or have downtime they didn’t plan for. The pattern that works for me:
- Lower DNS TTL to 300 seconds at least 24 hours before the migration window. This way, when you flip the A record, propagation takes minutes rather than hours.
- Provision the new host and install WordPress with the same PHP version as your current site. Mismatched PHP versions are the silent cause of half the post-migration weirdness I’ve debugged.
- Migrate files via rsync or All-in-One WP Migration for sites under 2GB. For larger sites I export the database with WP-CLI (
wp db export) and tar thewp-contentdirectory directly. - Run search-replace properly. Use WP-CLI’s
wp search-replacewith the--preciseflag to handle serialized data correctly. Manually search-replacing the SQL dump in a text editor will corrupt option_value rows that contain serialized arrays. I’ve seen this break sites a dozen times. - Test on a hosts-file override. Edit your local
/etc/hoststo point the domain at the new server’s IP and click around as a logged-in admin. Test checkout, contact forms, search, and any AJAX-heavy area. - Flush transients before going live. Stale transients hold cached menus, related-posts queries, and homepage feeds.
wp transient delete --allhandles it. - Flip DNS during a low-traffic window and watch your error log for the next hour.
What usually breaks: hardcoded asset URLs in custom CSS or JavaScript files (search the codebase for the old domain), email plugins that use the server’s sendmail rather than SMTP (configure SMTP via Brevo/Postmark/Amazon SES before migrating), and any plugin that stores absolute paths in options — some sliders and gallery plugins are notorious for this.
Common mistakes I see every month
- Buying multi-year intro pricing without checking renewal rates. Bluehost’s $2.95 intro renews at $11.99. SiteGround’s $7.99 intro renews at $44.99 — a 5.6x jump. Always read the renewal column on the pricing page, not the lead number.
- Skipping staging and editing live. One bad plugin update on a production site can cost you a day of work and a Google Search Console alert. Every host I recommend includes staging; use it.
- Trusting host-bundled “security” plugins. Most are repackaged free plugins or thin wrappers that mostly exist for upsells. Real security is keeping core/plugins updated, using strong admin passwords, enforcing 2FA, and putting Cloudflare in front of the site. A host’s “SiteLock” or “Sucuri Lite” bundle is rarely worth what it costs.
- Picking based on Trustpilot reviews. Hosting reviews are heavily influenced by affiliate marketing. Trustpilot is mostly people writing about support response times. Performance under load is invisible to the reviewers. Use independent benchmarks (WPHostingBenchmarks, Review Signal’s annual report) instead.
- Not testing the actual response on the actual plan. Hosts give faster review accounts to sponsored reviewers. Provision a real account, run k6 or Loader.io against it, and judge for yourself.
- Confusing “cloud” with “fast.” A misconfigured AWS Lightsail instance is slower than SiteGround GoGeek. The infrastructure word doesn’t produce performance — the configuration does.
What I run my own sites on
For my personal projects — my technical blog, two affiliate sites, and a small WooCommerce store — I’ve been on Cloudways with DigitalOcean Premium Intel droplets for about three years. My reasoning, in case it’s useful:
- I want a Linux box I can reason about, with Varnish and Redis pre-configured by people who do this every day. Cloudways gives me that without making me re-learn server tuning every time PHP releases a new version.
- The DO Premium Intel droplets use newer Xeon chips with consistent CPU performance. The standard droplets oversubscribe more aggressively. The premium tier is roughly 20% more expensive and noticeably faster on PHP-bound workloads.
- I can scale vertically with a button when I need to (caveat: it requires a few minutes of downtime), and I can attach Cloudflare at the edge without fighting the host.
- Pricing is predictable. No overage charges for traffic spikes — I just pay for the droplet size I picked.
If I worked exclusively on client sites that someone else paid for, I’d use Kinsta Pro or WP Engine Growth without thinking about it — the support quality and operational guarantees are worth the premium when it’s not your money. For dirt-cheap personal projects I’d use Hetzner CX22 with RunCloud, accept the slightly higher operational burden, and pocket the savings.
The wrap-up that actually helps
Pick the smallest hosting tier that comfortably covers your real traffic plus 50% headroom, then upgrade when your monitoring tells you to — not when a marketing email tells you to. Treat hosting as a tool you can swap out, not a marriage. A clean WordPress site is portable: filesystem plus database plus DNS. The whole stack moves in an afternoon if you’ve done it before.
And whatever tier you land on, configure your monitoring before you need it. UptimeRobot for uptime, a synthetic check from a tool like Better Stack or Pingdom for end-to-end response time, and Real User Monitoring through Cloudflare or a dedicated tool for actual visitor experience. Without monitoring you don’t know your hosting is failing until your traffic numbers drop and Google Search Console emails you about Core Web Vitals. By then you’ve already lost rankings. Set the alarms first, then pick the host.