We measured ~100 WordPress sites. The host brand barely mattered — the cache did
Published October 30, 2026
People pick a WordPress host like they pick a car brand — on reputation, on who everyone else uses. So I went looking for whether the reputation shows up in the numbers. We watch close to a hundred sites across the usual stacks, and every one gets its PageSpeed measured. I grouped them by what they actually run and looked at the mobile scores.
The host’s name turned out to be a weak predictor. What the site had running in front of it was a strong one.
The groups, by real numbers
Mobile performance score and field TTFB (the time a real visitor waits for the first byte), averaged within each stack:
| Stack | Sites | Mobile score | Field TTFB |
|---|---|---|---|
| nginx + WP Rocket | 20 | 79 | 702 ms |
| WP Engine + a second cache layer | 7 | 77 | 1,577 ms |
| WP Engine (EverCache) | 35 | 65 | 1,352 ms |
| nginx, no page cache | 18 | 60 | 2,474 ms |
| Cloudflare in front, no origin cache | 10 | 60 | 1,373 ms |
What jumps out
The fastest group isn’t the fanciest host — it’s a tuned open stack. Plain nginx with WP Rocket doing full-page caching came out on top, and by the margin that matters: a 702 ms first byte, less than a third of the uncached group’s. No managed-hosting premium required.
The most popular managed stack landed in the middle. WP Engine on EverCache — the biggest single group at 35 sites — averaged a 65. That’s not bad, but it’s not the automatic win the brand implies. You’re paying for reliability and support, which are real; you are not buying a guaranteed fast site.
No page cache is where it falls apart. The nginx sites with no caching averaged a 60 and a 2.5-second first byte — the worst TTFB in the whole set. Every request was building the page from scratch, per visitor.
A CDN doesn’t save an uncached origin. The “Cloudflare in front, nothing cached behind it” group had the worst lab LCP of all — the CDN can’t serve what the origin won’t cache, so the slow first byte just happens at a different address.
The actual lesson
Lining it up, the split is clean: the two fastest groups both had a real full-page cache; the two slowest had none. The host brand reshuffled the order a little. The cache decided it.
One footnote worth a warning: seven sites were running two full-page caches at once — a host cache and WP Rocket stacked together. It didn’t hurt their scores here, but it’s a foot-gun. Two caches disagree about when a page is stale, and the bug that produces — a change you published that just won’t show up — is miserable to chase. You want one cache, configured on purpose.
How to check your own
Your first byte is the tell. Run your site through PageSpeed, or just curl -w "%{time_starttransfer}\n" -o /dev/null -s https://yoursite.com. If it’s consistently over a second, you probably don’t have a working page cache, no matter what your host charges. Site Doctor reports the stack and the field TTFB on every scan, so you can see where you actually sit — but the curl line above costs nothing and tells you most of it.