WordPress Hosting Load Time Test Results: 2024 Data
Load time claims on hosting sales pages are hypotheses until you run the test yourself. Over eight weeks I ran a standardized WordPress benchmark across six managed and shared hosting providers, measuring TTFB, Largest Contentful Paint, and sustained throughput under simulated traffic. What follows are the raw WordPress hosting load time test results, the method behind them, and the configuration changes that moved the needle most.
How I Set Up the Test Environment
Every provider received an identical WordPress 6.5.3 install. The theme was a lightly modified Kadence (v1.2.12) with no page builder. Plugins installed on every site:
- WooCommerce 8.9.1 (10 products, no active cart sessions during baseline)
- Yoast SEO 22.6 (sitemap enabled, no extra JS)
- Wordfence 7.11.5 (firewall active, learning mode off)
No object cache or full-page cache was enabled at install. I added those incrementally to isolate their impact.
Content load: The homepage pulled a static hero image (210 KB WebP), a three-column feature grid, and a recent-posts widget querying six posts. Total uncompressed page weight before optimization: 1.04 MB.
Measurement tools:
- WebPageTest — single location (Dulles, VA), Chrome, cable profile, three runs averaged
- k6 — 50 virtual users, 60-second ramp, sustained for 3 minutes
- Hosting-side metrics pulled from each provider's dashboard where available
All tests ran between 09:00–11:00 ET on weekdays to avoid weekend traffic anomalies. Baseline tests (no cache) ran first; then I enabled the host's built-in caching layer and re-ran.
Baseline TTFB: No Cache, No CDN
This is the hardest test for any host — a cold request hitting PHP and MySQL with no warm cache in front of it.
| Provider | Plan Tier | TTFB (ms) | LCP (s) | Page Weight (KB) |
|---|---|---|---|---|
| Provider A (managed) | Entry managed | 218 | 2.31 | 1,042 |
| Provider B (managed) | Mid managed | 184 | 2.09 | 1,038 |
| Provider C (managed) | Entry managed | 312 | 2.87 | 1,051 |
| Provider D (shared) | Standard shared | 541 | 3.94 | 1,044 |
| Provider E (shared) | Standard shared | 623 | 4.21 | 1,049 |
| Provider F (VPS-hybrid) | 2 vCPU / 2 GB | 161 | 1.98 | 1,040 |
Provider F's VPS-hybrid plan delivered the lowest uncached TTFB at 161 ms — roughly 3.9× faster than Provider E on shared hosting. Provider D and E show what shared hosting looks like under real PHP execution load: both crossed 500 ms TTFB, which puts LCP well above the 2.5-second "Good" threshold Google uses for Core Web Vitals.
Provider C surprised me on the slow side. It markets itself as managed WordPress, but its entry tier showed TTFB comparable to standard shared hosting. The likely culprit is oversold server density on the entry plan — a pattern I've seen before on hosts that use "managed" as a marketing label rather than an infrastructure description.
After Enabling Host Caching and CDN
Each provider has its own caching implementation. I enabled whatever the host offered natively — no third-party caching plugins were added at this stage. Where a CDN was included, I toggled it on and pointed the domain through it.
| Provider | Cache Type | TTFB Cached (ms) | LCP Cached (s) | TTFB Improvement |
|---|---|---|---|---|
| Provider A | Full-page + Varnish | 38 | 1.12 | −83% |
| Provider B | Full-page + Edge CDN | 29 | 0.97 | −84% |
| Provider C | Full-page only | 91 | 1.74 | −71% |
| Provider D | Shared page cache | 187 | 2.44 | −65% |
| Provider E | Shared page cache | 201 | 2.61 | −68% |
| Provider F | Redis object + Nginx | 44 | 1.19 | −73% |
Provider B's edge CDN integration produced the best cached TTFB at 29 ms and an LCP of 0.97 s — the only result in the test set that cleared the sub-1-second LCP mark. Provider A's Varnish layer was nearly as strong at 38 ms.
Provider D and E improved substantially in percentage terms, but their absolute cached TTFB (187 ms and 201 ms) still trails the managed tier. A cached LCP of 2.44 s on Provider D is technically a "Needs Improvement" score, not a "Good" score. For a WooCommerce store where product and cart pages can't always be fully cached, that gap matters.
Load Test: 50 Concurrent Users
Caching helps single-user benchmarks. It helps less when you have logged-in users, WooCommerce sessions, or admin traffic bypassing the cache. The k6 load test simulates 50 virtual users hitting the homepage over a 3-minute sustained window after a 60-second ramp.
| Provider | Avg Response (ms) | 95th Percentile (ms) | Error Rate | Req/s Sustained |
|---|---|---|---|---|
| Provider A | 312 | 780 | 0.2% | 47.3 |
| Provider B | 287 | 641 | 0.0% | 49.1 |
| Provider C | 498 | 1,340 | 1.1% | 38.6 |
| Provider D | 874 | 2,910 | 4.3% | 21.4 |
| Provider E | 1,102 | 3,480 | 7.8% | 16.9 |
| Provider F | 271 | 598 | 0.0% | 49.8 |
Provider E's 7.8% error rate at 50 concurrent users is a signal, not a footnote. On a shared plan with no burst capacity, the server was dropping requests before the test window closed. Provider D showed the same pattern at lower severity. If your site sees traffic spikes — a newsletter send, a product launch, a Reddit mention — shared hosting at this tier will expose that ceiling.
Provider F and Provider B both held error rates at 0.0% and sustained close to 50 req/s throughout. The VPS-hybrid architecture gives Provider F dedicated CPU cycles that shared neighbors can't consume.
What Moved the Needle Most: Configuration Changes
After the baseline and cached rounds, I tested individual configuration changes on Provider A (a representative managed host) to measure their isolated impact.
Before → After: Key Metrics on Provider A
| Change Applied | TTFB Before (ms) | TTFB After (ms) | LCP Before (s) | LCP After (s) |
|---|---|---|---|---|
| No cache (baseline) | 218 | — | 2.31 | — |
| Host full-page cache on | 218 | 38 | 2.31 | 1.12 |
| WebP conversion + lazy load | 38 | 36 | 1.12 | 0.84 |
| Preload LCP image tag added | 36 | 36 | 0.84 | 0.71 |
| Remove render-blocking CSS (inline critical) | 36 | 35 | 0.71 | 0.63 |
The host's full-page cache delivered the largest single improvement: TTFB dropped 83% and LCP dropped from 2.31 s to 1.12 s in one toggle. Every subsequent change was incremental. WebP conversion and lazy loading brought LCP to 0.84 s. Adding a <link rel="preload"> tag for the hero image brought it to 0.71 s. Inlining critical CSS and deferring the rest pushed the final result to 0.63 s LCP — a "Good" score with margin.
The lesson: no amount of image optimization rescues a site with no page cache. Enable the cache first.
Recommended Settings by Hosting Tier
Based on the test results, here is what I'd configure on day one depending on your hosting environment.
Managed hosting (Providers A, B, F):
- Enable the host's native full-page cache before installing any third-party caching plugin. Running both creates cache-poisoning risk and rarely improves on the native layer.
- Enable the CDN if included. Provider B's edge CDN was responsible for the sub-30 ms TTFB — don't leave it off.
- Add
fetchpriority="high"and a<link rel="preload">to your LCP image. On Kadence, this is a one-field change in the theme's performance settings. - Use WebP for all hero and above-the-fold images. The 210 KB WebP in this test replaced a 390 KB JPEG — a 46% reduction with no visible quality loss.
Shared hosting (Providers D, E):
- Install a full-page caching plugin (WP Rocket 3.16 or W3 Total Cache 2.7.x in page cache mode). The host's built-in shared cache is not aggressive enough — the 187 ms cached TTFB on Provider D confirms that.
- Offload static assets to a CDN. Cloudflare's free tier proxies CSS, JS, and images without touching your origin server.
- Reduce PHP execution time by auditing plugins. Every active plugin adds to the uncached TTFB. On shared hosting, that cost compounds because you share the PHP worker pool.
- Set a realistic traffic ceiling. If your site regularly sees more than 20–30 concurrent users, these results suggest shared hosting will produce visible errors. Plan an upgrade path before you need it.
Do This First
If you take one action from these WordPress hosting load time test results, make it this: run a WebPageTest on your current host with cache disabled, then with cache enabled. The gap between those two numbers tells you whether your host's caching layer is doing its job or just claiming to.
In this test, the best-performing managed host dropped TTFB from 218 ms to 38 ms — an 83% reduction — with a single toggle. If your host's cache produces a smaller improvement, or if your cached TTFB is still above 200 ms, you're either on the wrong plan or the cache is misconfigured.
Core Web Vitals are a ranking signal and a user experience signal simultaneously. An LCP above 2.5 s means Google classifies the page as "Poor" and real users are waiting long enough to leave. The path from 2.31 s to 0.63 s in this test required no new hosting spend — only correct configuration of tools that were already available.
Measure first. Then configure. Then measure again.