Ask any WordPress owner how to make their site fast and the first answer is always the same: install a caching plugin. It is good advice, and almost everyone takes it — on the professionally run sites we have measured, a caching plugin of some kind is close to universal. So the interesting question isn’t whether people cache. It’s whether caching is enough.
To find out we picked the least forgiving sample we could: nine WordPress sites run by the industry itself. The makers of SEO and performance plugins. The theme companies. The publications that write about page speed for a living. If a caching plugin were the finish line, these are the sites that would have crossed it.
The median mobile PageSpeed score across the nine was 51. Not one of them reached the 90 that Google marks as “good”. Four were under 50 — in the red.
The plugin was installed and the score was still low
On four of the nine we could confirm, from the outside, exactly which tool was doing the caching — either from an HTTP header the server sends, from the plugin’s own signature comment in the HTML, or from its runtime markup. In every one of those four, the plugin was demonstrably there and the mobile score was still not good:
| Site | Confirmed tool | Mobile before |
|---|---|---|
| WPForms | LiteSpeed Cache | 49 |
| ProBlogger | W3 Total Cache | 51 |
| CSS-Tricks | Breeze | 61 |
| Variety | Cloudflare Rocket Loader | 46 |
These are not sites that forgot to turn caching on. WPForms ships behind LiteSpeed Cache and scores 49 on a phone. ProBlogger runs W3 Total Cache and scores 51. The caching is working — and the page is still slow.
Why a cache doesn’t move the number
A page cache does one specific thing: it stores the finished HTML the first time WordPress builds it, and serves that stored copy on every later request instead of running the PHP and the database again. That makes the server answer sooner — Time to First Byte, the moment the first byte arrives, drops. It is real and it is worth having.
But the phone still has to draw the page, and caching changes nothing about what it has to
draw. The stored HTML is the same HTML. Its <head> still links the same stylesheets, and
CSS is render-blocking — “the browser won’t render any processed content until the CSSOM is
constructed.” The largest image on the first
screen is still fetched at the same low priority as everything below the fold. The same
third-party scripts still run.
Caching fixes when the response arrives. It does not touch what is in the response — and on a throttled mobile connection, what is in the response is almost the whole score.
The confusing case: tools that game the lab
Two of the four tools above don’t just cache — they defer JavaScript. WP Rocket’s option delays “the loading of all JavaScript files and inline scripts until there is a user interaction”; Cloudflare’s Rocket Loader defers “the loading of all of your JavaScript until after rendering.” In a lab test there is no interaction, so that deferred JavaScript never runs, and the score can look better than a real visitor’s experience — the phone that does tap and scroll pays the cost the lab skipped.
This is worth knowing for a second reason: it is exactly the kind of arrangement a naive front-end optimizer breaks. A tool that re-queues those already-deferred scripts can undo the site’s own timing and make things worse. Getting this right means recognising the site has already made a decision about its JavaScript and leaving it alone — one of the things we had to teach our own proxy before it could help these sites rather than fight them.
What was left on the table
The same nine pages, served through WebSpeed with no plugin added or removed, moved from a median of 51 to 69 on mobile — a median gain of 18 points, entirely from reordering the critical path, prioritising the largest image, and deferring what the first screen doesn’t need. ProBlogger went from 51 to 97. GeneratePress from 64 to 89. The headroom the cache couldn’t reach was still there.
The point isn’t that caching is wrong — keep it, it does the half of the job we don’t. The point is that “we already have a caching plugin” and “the page is fast on a phone” are two different statements, and on the nine sites most likely to have closed that gap, they still hadn’t.
Method and limits
Nine well-known WordPress sites — makers of performance and SEO plugins, and publishers that cover web development — measured on mobile PageSpeed (Google Lighthouse), median of three runs each, original versus the same page through the WebSpeed reverse proxy. Every site was checked first to confirm the proxy served the real page and did not redirect to the origin, so the before/after is a like-for-like comparison. Where a caching or optimization tool could be confirmed from the outside — an HTTP response header, the plugin's own signature comment, or its runtime markup — it is named; where it could not, the site is left unlabelled rather than guessed at.
Measured on 23 Jul 2026 across 9 sites. These figures are frozen at that date — we don't quietly restate a published study when the audit base grows.
What this doesn't show
- This is not a random sample of the web. These are nine sites we chose on purpose — WordPress performance-plugin vendors and speed-focused publishers — because they are the least likely to have neglected this. Read every figure as "of these nine sites", never as "of WordPress" or "of the web".
- Confirming which caching plugin a site runs, from the outside, is only partly possible. A CDN in front of the origin hides the server's own headers, so we could positively confirm a caching or optimization tool on four of the nine; the other five run WordPress and score the same way, but we do not name a plugin we could not see. "Still slow with a plugin" therefore rests on the four we could confirm, not on all nine.
- PageSpeed is a lab score from a single simulated mobile load. It is a useful proxy for the front-end work a page makes a phone do, which is the subject here, but it is not a measurement of what any individual real visitor experienced.
Sources
- Time to First Byte (TTFB) — web.dev, Google
TTFB is a metric that measures the time between starting navigating to a page and when the first byte of a response begins to arrive.
- Render-blocking CSS — web.dev, Google
By default, CSS is treated as a render-blocking resource, which means that the browser won't render any processed content until the CSSOM is constructed.
- Delay JavaScript execution — WP Rocket
Delay JavaScript Execution improves performance by delaying the loading of all JavaScript files and inline scripts until there is a user interaction (e.g. moving the mouse over the page, touching the screen, scrolling, pressing a key, scrolling with the mouse wheel).
- Rocket Loader — Cloudflare
Rocket Loader prioritizes your website's content (text, images, fonts, and more) by deferring the loading of all of your JavaScript until after rendering.