A client came to us last year with a WooCommerce store on a shared plan costing about four dollars a month. The front end looked fine because Cloudflare was serving cached HTML. Then they tried importing 6,000 products and the site fell over: PHP processes killed at the 60 second mark, imports half-finished, orphaned postmeta rows everywhere. The host’s answer was to upgrade to the “business” tier. The actual problem was that the account was capped at two concurrent PHP workers and 512MB of memory across the whole account.

That is the gap most WordPress hosting comparisons never close. They compare disk space and “unlimited bandwidth” when the numbers that decide whether your site survives Black Friday are CPU seconds, PHP worker count, and how fast the database can return an uncached query. Marketing pages rarely publish any of them.

So here’s how we actually pick a host, what we measure before signing anything, and where the conventional advice is wrong.

What you’re actually buying

Every WordPress request that misses the page cache runs the same way: nginx or Apache hands the request to a PHP-FPM worker, PHP boots WordPress (roughly 40 to 60ms of opcode execution on a warm OPcache with a lean plugin set, considerably more with 35 plugins), runs 20 to 200 database queries, renders HTML, and returns it. Your host controls four variables in that chain.

• PHP worker count. How many of those requests can run simultaneously. Shared plans commonly allow 2 to 10. If you have 4 workers and each uncached request takes 400ms, your ceiling is roughly 10 requests per second before queuing starts.
• CPU allocation. Shared hosts usually sell you a fraction of a core, enforced with cgroups. Hit the ceiling and your processes get throttled, not killed, which shows up as randomly slow responses rather than errors.
• Memory per process. WordPress with WooCommerce and a page builder regularly uses 128MB to 256MB per request. Two workers at 256MB is 512MB, which is the entire allocation on many entry plans.
• Database I/O. On shared hosting the MySQL server is shared too. A neighbour running a badly indexed query can add 200ms to yours.

Ask any host for those four numbers. The ones that answer clearly are usually the ones worth buying from.

Shared hosting: still fine, until it isn’t

There’s a snobbery about shared hosting that isn’t earned. We have brochure sites on decent shared plans, LiteSpeed-based hosts in particular, serving cached pages with a TTFB around 120ms from the nearest region. For a ten-page site with a contact form and a blog that publishes twice a month, spending 30 dollars a month is money set on fire.

The failure modes are predictable. Shared hosting collapses when a meaningful share of your requests can’t be cached:

• WooCommerce cart, checkout and account pages, which must bypass the page cache
• Membership or LMS sites where most traffic is logged in
• Sites with a busy editorial team, because wp-admin is entirely uncached and competes with front end traffic for the same tiny worker pool
• Anything doing long-running work: imports, exports, image regeneration, scheduled feeds

One specific trap: many cheap hosts enforce a hard maxexecutiontime of 30 or 60 seconds that you cannot raise from .htaccess or wp-config.php. Every media library regeneration on a 40,000 image site will die halfway. You’ll waste more billable hours working around that than the upgrade would have cost.

VPS: the best performance per dollar, and a second job

The raw numbers are not close. A 2 vCPU, 4GB VPS from Hetzner or DigitalOcean costs somewhere between 5 and 25 dollars a month and will comfortably outrun a 40 dollar managed plan on uncached throughput, because you’re not sharing and you tune it yourself. We run several client sites on exactly that shape of box with nginx, PHP 8.3, MariaDB 10.11 and Redis for the object cache.

The tuning that matters most is worker count, and almost everyone guesses it. Measure instead:

# Average resident memory per PHP-FPM worker, in MB
ps --no-headers -o rss -C php-fpm8.3 | awk '{ s+=$1 } END { printf "%.0f MB avg over %d procs\n", s/NR/1024, NR }'

If that returns 90MB and you have 4GB with 1GB reserved for MariaDB and 300MB for Redis and the OS, you have roughly 2.5GB for PHP, so pm.max_children = 25 is defensible. Set it to 50 and a traffic spike will swap, then OOM, then the kernel kills MariaDB. We’ve watched that happen on a site that had been stable for eight months.

Two settings people forget. OPcache should be sized for your actual codebase, and the interned strings buffer matters on WordPress:

; /etc/php/8.3/fpm/conf.d/10-opcache.ini
opcache.memory_consumption=256
opcache.internedstringsbuffer=32
opcache.maxacceleratedfiles=20000   ; WP core alone is ~5,000 files
opcache.validate_timestamps=1         ; keep on unless you deploy atomically
opcache.jit=disable                   ; JIT gives WP almost nothing and complicates debugging

The InnoDB buffer pool should hold your whole database if it fits. A 600MB WordPress database on a default 128MB pool means constant disk reads for queries that should be memory-resident.

The honest cost of a VPS is not the invoice. It’s unattended-upgrades that break PHP-FPM, expired certificates on a subdomain nobody monitors, and the question of who patches the kernel when you’re on holiday. If nobody on the team has a genuine sysadmin reflex, pay someone else.

Managed WordPress hosting: what the premium actually buys

Managed WordPress hosting from the usual names sits somewhere between 20 and 35 dollars a month at the entry tier, and the pitch is usually speed. That’s the weakest part of the argument. The strongest is everything around the running site.

What you’re really paying for:

• One click staging with a real database copy, plus push to production. Doing this properly yourself with WP-CLI and search-replace takes an afternoon to script and a while longer to trust.
• Restores measured in minutes. Not “we have backups” but a tested restore path. This does not remove your obligation to keep an off-platform copy, which is the whole point of the 3-2-1 rule.
• PHP version toggles that let you test 8.4 on staging and roll back in 30 seconds.
• Support that understands WordPress. A ticket that says “fatal error in class-wc-order.php after update” gets a useful reply rather than “please contact your developer”.

The trade-offs are real and rarely mentioned. Most managed hosts ban certain plugins (backup plugins, some caching plugins, anything that writes to the filesystem aggressively), they meter visits rather than bandwidth so a bot wave can push you into overage, and their caching layers can be opaque. If you run a headless setup, a custom Node process, or anything non-WordPress alongside the site, the platform will fight you.

Our rule of thumb: if the site generates revenue and an hour of downtime costs more than a month of hosting, buy managed. If it’s a portfolio, don’t.

How to test a host before you commit

Homepage speed tests are theatre. Cloudflare or a page cache will serve a static file and you learn nothing about PHP. Test the parts that can’t be cached.

# curl-format.txt
  timenamelookup:  %{timenamelookup}s\n
  timeconnect:     %{timeconnect}s\n
  timeappconnect:  %{timeappconnect}s\n
  timestarttransfer: %{timestarttransfer}s\n
  timetotal:       %{timetotal}s\n

Cache-busting query string forces a full PHP + DB render
for i in $(seq 1 10); do
  curl -s -o /dev/null -w "@curl-format.txt" "https://example.com/?nocache=$RANDOM"
done

timestarttransfer minus timeconnect is your real server think time. On a healthy host with a normal plugin load, expect 150ms to 400ms. Above 800ms consistently, either the host is oversold or your site has a problem that no host will fix. That’s a separate diagnostic exercise covered in our slow site method.

Then test concurrency, because that’s where shared plans reveal themselves:

# 200 requests, 10 at a time, all cache-busted
ab -n 200 -c 10 "https://example.com/?nocache=1"

Watch the 95th percentile, not the mean. If the mean is 300ms and p95 is 4,000ms, you’re queuing behind a worker limit. Run the same test while logged into wp-admin in another browser and see whether the dashboard becomes unusable.

Matching the plan to the site

Here’s roughly how we allocate, after a few hundred projects:

• Brochure or portfolio, under 20k visits: quality shared hosting, LiteSpeed if available, plus Cloudflare. Around 5 to 15 dollars a month. Forms handled by an third-party endpoint such as WebForms so a slow mail queue never blocks a page render.
• Agency site or busy blog: entry managed plan or a 2 vCPU VPS if you have the ops capability. Object caching with Redis matters more than CPU here.
• WooCommerce under 500 orders a month: managed WooCommerce tier, or a 4 vCPU VPS with 8GB. Checkout is uncacheable, so worker count is the binding constraint.
• High traffic or multisite: dedicated resources, separate database host, and a real CDN strategy. At this point hosting is an architecture decision, not a purchase.

One thing that stays constant across all of them: caching configuration outperforms hardware upgrades almost every time. Getting the layers right (page, object, browser, CDN) routinely takes a 1.2 second TTFB to under 200ms without changing plans.

The exit cost nobody prices in

Before you sign, find out how you leave. Can you get a full SQL dump and the uploads directory without a support ticket? Is there SSH and WP-CLI access? Some platforms make migration out deliberately awkward: no SSH, no direct database access, export only through their own tool.

Check DNS too. If the host manages your nameservers and also your email, moving becomes a coordinated operation across three systems rather than a TTL change. We keep DNS at Cloudflare for every client precisely so a host migration is a 300 second TTL drop and a record update.

Also worth knowing before the emergency: where the backups live, in what format, and whether a restore overwrites the database or merges it. The answer to that last question has surprised more than one team.