Cloudways Managed Hosting WordPress Test: Real Benchmarks
A lot of WordPress hosting comparisons stop at marketing copy. This one starts at the command line.
For this Cloudways managed hosting WordPress test, I spun up identical WordPress 6.5 installs on three Cloudways cloud providers — DigitalOcean, Vultr, and AWS — and ran each through the same measurement pipeline I use for every host I cover. The goal was to answer a narrow question: does Cloudways' managed stack (Nginx, Redis object cache, Varnish, PHP 8.3) deliver TTFB and LCP numbers that justify its price premium over shared hosting?
Spoiler-free version: the numbers are competitive, but the provider you pick inside Cloudways matters more than most reviews admit.
How I Set Up and Measured Each Server
Every server in this test ran the same baseline:
- WordPress 6.5 with Twenty Twenty-Four theme (no page builder)
- PHP 8.3 (selected in Cloudways application settings)
- MySQL 8.0
- Nginx as the web server
- Cloudways Object Cache Pro (Redis) enabled, 128 MB allocated
- Cloudflare free tier disabled — raw origin measurements only
- No caching plugins on the first pass; Cloudways' built-in Varnish-based Breeze cache plugin on the second pass
Server size: 2 vCPU / 2 GB RAM on each provider, the smallest tier where Cloudways enables all stack features.
Measurement tools:
- WebPageTest (Dulles, Virginia node; Cable profile; 9 runs, median reported)
- GTmetrix (Vancouver node; 3 runs, median)
- k6 for load testing (50 virtual users, 60-second ramp, from a DigitalOcean droplet in the same region)
- Query Monitor plugin to confirm PHP execution time and database query count per page load
I tested each configuration twice: once with Breeze cache off and once with Breeze cache on and Varnish warmed (three manual page loads before recording).
Cloudways Stack Baseline: TTFB Before Any Caching
Before turning on Breeze, I wanted to see what the raw PHP + MySQL stack delivers. These are origin TTFB numbers — no CDN, no page cache, cold server.
| Provider | Region | TTFB (median) | PHP Exec Time | DB Queries |
|---|---|---|---|---|
| DigitalOcean | NYC1 | 218 ms | 142 ms | 14 |
| Vultr | New Jersey | 231 ms | 149 ms | 14 |
| AWS (EC2) | us-east-1 | 197 ms | 138 ms | 14 |
All three cleared the informal 200–300 ms "good origin TTFB" threshold that Google's CrUX data suggests correlates with passing LCP on typical connections. AWS came in lowest, which is consistent with its dedicated compute allocation versus the burstable credits on DigitalOcean and Vultr entry tiers.
Query Monitor confirmed 14 database queries per homepage load across all three — that's the Twenty Twenty-Four baseline with no plugins beyond Query Monitor itself. PHP execution time tracked closely with TTFB, confirming the bottleneck is PHP rendering, not network.
Breeze Cache + Varnish: Before and After
Cloudways ships Breeze, its own caching plugin, pre-installed. Breeze handles page caching by writing static HTML files and passing cache-control headers to Varnish, which sits in front of Nginx. Object cache (Redis) handles the WordPress object cache API.
After enabling Breeze with default settings (page cache on, Gzip on, browser cache on) and warming the cache:
| Provider | TTFB Uncached | TTFB Cached | Reduction | LCP (WebPageTest) |
|---|---|---|---|---|
| DigitalOcean | 218 ms | 38 ms | 83% | 1.21 s |
| Vultr | 231 ms | 44 ms | 81% | 1.28 s |
| AWS | 197 ms | 31 ms | 84% | 1.09 s |
The cached TTFB numbers are the ones that matter for real-world performance. At 31–44 ms origin TTFB, all three providers are well inside the range where LCP is determined by asset delivery, not server response. That's where the test shifts to front-end optimization territory rather than hosting.
LCP on the Twenty Twenty-Four homepage (a 94 KB hero image, served from the same origin) landed between 1.09 s and 1.28 s across providers on a cable connection. Google's "Good" LCP threshold is under 2.5 s; these results are comfortably in range even without a CDN.
Load Test: 50 Concurrent Users
A single-user TTFB tells you about the stack; a load test tells you about stability. I used k6 to ramp from 0 to 50 virtual users over 30 seconds, hold for 60 seconds, then ramp down. Each VU requested the homepage in a loop with a 1-second think time.
With Breeze cache on, Varnish absorbs nearly all requests before they reach PHP. The results reflect that:
| Provider | Median Response (p50) | p95 Response | Error Rate | Req/sec (peak) |
|---|---|---|---|---|
| DigitalOcean | 41 ms | 68 ms | 0% | 47.2 |
| Vultr | 48 ms | 79 ms | 0% | 44.8 |
| AWS | 34 ms | 55 ms | 0% | 51.3 |
No errors on any provider at 50 VUs. The p95 numbers stayed well below 100 ms, meaning the 95th percentile visitor still got a sub-100 ms server response. For a typical small-to-medium WordPress site, this headroom is substantial.
I repeated the test with Breeze disabled to simulate cache bypass (logged-in users, WooCommerce cart pages, etc.):
| Provider | Median Response (no cache) | p95 Response | Error Rate |
|---|---|---|---|
| DigitalOcean | 289 ms | 612 ms | 0% |
| Vultr | 314 ms | 698 ms | 0% |
| AWS | 261 ms | 541 ms | 0% |
No errors, but p95 response times climbed into the 500–700 ms range under concurrent uncached load on 2 GB RAM servers. That's expected behavior. If your site has a high proportion of cache-bypass requests (WooCommerce, membership sites, heavy AJAX), you'd want to move up to the 4 GB tier or add Redis full-page caching.
Cloudways Pricing vs. What You Actually Get
Cloudways pricing is cloud-provider cost plus Cloudways' management margin. As of the time of writing:
| Plan | Provider | vCPU | RAM | Storage | Price/mo |
|---|---|---|---|---|---|
| DO 2GB | DigitalOcean | 1 | 2 GB | 50 GB SSD | $14 |
| Vultr 2GB | Vultr | 1 | 2 GB | 50 GB SSD | $13 |
| AWS 2GB | AWS EC2 | 1 | 2 GB | 20 GB EBS | $36 |
| DO 4GB | DigitalOcean | 2 | 4 GB | 80 GB SSD | $28 |
The AWS premium is real. You're paying roughly 2.5x DigitalOcean for marginally better single-thread performance. For most WordPress sites, DigitalOcean or Vultr at $13–14/month is the practical entry point. AWS makes sense if you're already in the AWS ecosystem or need specific compliance positioning.
Compared to shared hosting at $3–8/month, the $13–14 Cloudways entry tier costs roughly 2–4x more. The cached TTFB improvement from ~200 ms (typical shared hosting) to ~38 ms is the quantifiable return on that spend.
Recommended Cloudways Settings for WordPress Performance
These are the settings I changed from defaults during this test, in the order I'd apply them on a new Cloudways application.
1. Switch to PHP 8.3 Default may be PHP 8.1 depending on when your server was created. PHP 8.3 shaved approximately 8–12 ms off PHP execution time in my Query Monitor readings versus 8.1 on the same server. Change it under Application Settings > PHP Version.
2. Enable Redis Object Cache Cloudways calls this "Object Cache Pro" in the add-ons panel. At $0/month on Cloudways (included), there's no reason to skip it. It reduced database queries on repeat page loads from 14 to 3 in my test (WordPress core uses the object cache for options, transients, and user lookups).
3. Configure Breeze with these non-default changes
- Enable Minify HTML (saves ~2–4 KB on typical pages)
- Enable Defer JavaScript for non-critical scripts
- Set browser cache TTL to 1 week for static assets
- Enable Lazy Load for images if you're not handling it at the theme level
4. Set PHP-FPM workers to match your vCPU count
Under Server Settings > PHP-FPM, set pm.max_children to 2x vCPU count as a starting point. On a 2 vCPU server, that's 4 workers. This prevents PHP queue buildup under moderate concurrent load.
5. Add a CDN for static assets Cloudways integrates with Cloudflare (free) and StackPath. Even with sub-40 ms origin TTFB, a CDN reduces LCP for geographically distant visitors. In a separate test with Cloudflare proxying enabled, LCP on the DigitalOcean server dropped from 1.21 s to 0.94 s for a London-based WebPageTest node.
Do This First When You Migrate to Cloudways
Before optimizing anything, establish your baseline. Run three WebPageTest tests on your current host and record median TTFB and LCP. Then migrate to Cloudways (their migration plugin handles most WordPress sites cleanly), run the same three tests, and compare.
In my test environment, the migration from a mid-tier shared host to Cloudways DigitalOcean 2 GB produced:
- TTFB: 310 ms → 38 ms (cached)
- LCP: 3.1 s → 1.21 s
- Time to First Byte improvement: 88%
Those numbers are specific to a Twenty Twenty-Four install with no heavy plugins. Your results will differ based on plugin count, database size, and theme complexity. The method — measure before, migrate, measure after — is what makes the comparison meaningful rather than theoretical.
If your post-migration TTFB is still above 100 ms with Breeze enabled, check two things first: whether Varnish is actually serving the cached response (add ?nocache to bypass and compare), and whether any plugin is sending Cache-Control: no-cache headers that prevent Varnish from storing the page.
Cloudways Managed Hosting WordPress Test: Verdict
This Cloudways managed hosting WordPress test confirms that the platform delivers consistent, measurable performance improvements over shared hosting, with cached TTFB in the 31–44 ms range across all three providers tested. The Nginx + Varnish + Redis stack works as advertised when configured correctly.
Provider choice matters. AWS gives the best raw numbers but costs 2.5x more than DigitalOcean for comparable workloads. For most WordPress sites under moderate traffic, DigitalOcean or Vultr at $13–14/month represents the best performance-per-dollar inside the Cloudways ecosystem. If you need a more detailed comparison of hosting options, this guide on VPS providers covers similar decision criteria.
The settings that move the needle most: PHP 8.3, Redis object cache, and Breeze with deferred JavaScript. Apply those three before reaching for a third-party performance plugin.