ProBlogger has been teaching people how to run a blog since 2004, and it runs W3 Total Cache. You can see the plugin announce itself at the bottom of the page’s HTML — Performance optimized by W3 Total Cache — which means the server is doing the thing everyone recommends first: it builds the page once, stores the finished HTML, and serves that stored copy instead of running WordPress again on every visit.
It works. The server answers quickly. And the page scores 58 on a phone, with its largest image landing at 11.3 seconds.
That gap — a cache that works and a page that is still slow — is the whole point. A page cache changes when the response arrives. It does not change what is in the response, and on a throttled mobile connection what is in the response is almost the entire score.
What the cache doesn’t touch
The stored HTML W3 Total Cache serves is the same HTML. Its <head> still links the same
stylesheets, and the browser will not paint a single pixel until it has downloaded and parsed
all of them. On this page that is 193 KB of CSS the first screen never uses — downloaded,
parsed, and blocking the paint, cached or not.
Behind it sits 848 KB of unused JavaScript, most of it third-party and below-the-fold, and a largest image that is fetched at the same low priority as everything under it. So the first screen waits: first paint at 3.7 seconds, the main image at 11.3. The cache made the server fast and then handed the browser a page built to be slow.
The same page, reordered
Served through WebSpeed, with nothing installed and nothing changed at the source, the same page inlines the CSS the first screen needs and stops the rest from blocking, gives the main image priority, and defers the JavaScript the first paint never calls. The largest image moves from 11.3 seconds to 2.4; total blocking time from 280 ms to 10; the mobile score from 58 to 97, desktop from 76 to 99.
The page also got lighter on the way — 127 requests down to 40, 3.8 MB down to 1.2 — but the weight is not the story. The story is the order. The bytes that made the difference were the first 193 KB, the ones standing between the visitor and the first paint. The cache had already served them as fast as they could be served. They were still in the wrong place.
Keep the cache
None of this is an argument against W3 Total Cache, and turning it off would make ProBlogger slower, not faster. Caching and front-end optimization work on different halves of the problem: the cache decides how quickly the server can hand over the page, and everything above decides how quickly the browser can draw it. “We have a caching plugin” and “the page is fast on a phone” are two different sentences — and on a site whose entire subject is doing WordPress well, they still hadn’t met.
Fix it yourself
None of this needs us. It needs someone to do it, test that nothing broke, and do it again after the next template change — which is the part we sell.
- Send only the CSS the first screen needs The page downloads 193 KB of CSS that the first screen does not use, and CSS is render-blocking — the browser will not paint until it has parsed all of it. W3 Total Cache can minify and combine those files, which it has, but combining does not make unused rules stop blocking. The lever that helps is inlining the small slice the top of the page actually needs and loading the rest without blocking. Several caching and optimization plugins have a "critical CSS" or "eliminate render-blocking" option; turning it on is the single biggest move available here.
- Give the main image priority instead of a queue position The largest image on the first screen — the one the score waits for — is fetched at the same low priority as everything below it, so it lands at 11.3 seconds. Add fetchpriority="high" to that one image and preload it, and it stops queueing behind assets nobody has scrolled to yet.
- Stop shipping 848 KB of JavaScript the first screen never calls Most of it belongs to third parties and to features further down the page. Load it after the page is usable rather than before it paints. A caching plugin will not do this for you — it caches the script tags exactly as they are.
- Keep the cache — it is doing the other half None of this is an argument against W3 Total Cache. It makes the server answer quickly, which is real and worth having. It simply does not change what the browser has to download and draw, and on a throttled phone that is almost the entire score.
What we measured, and what got worse
PageSpeed Insights (Lighthouse, mobile and desktop) run against the live site
and against the same page served through the WebSpeed proxy, on
23 Jul 2026. Audit bc75ed5eff27c3 — the numbers
on this page are frozen at that run and are not restated later.
Proxy response re-checked on 23 Jul 2026: the proxied URL returns the page itself, not a redirect back to the origin. That check exists because a redirect makes both halves of a before/after the same page, and the improvement pure noise.
What the page still loaded
The accelerated run made 40 requests against the original's 127, and transferred 1.2 MB against 3.8 MB. We print this because a score can rise for two very different reasons — the page got faster, or the page got less of itself — and across our audit base the second is common enough to be worth ruling out in the open.
What got worse or stayed the same
- These are lab numbers from a single simulated mobile load that never scrolls and never clicks. They are a fair proxy for the front-end work the page makes a phone do, which is the subject here, but they are not a recording of what any one real visitor experienced.
- "Runs W3 Total Cache" is confirmed from the plugin's own signature comment in the served HTML; we did not need to log in to see it. What the site's own configuration of that plugin looks like on the inside, we cannot see, and some of the levers above may already be half-set.
- The after-column is our proxy applying front-end fixes on the fly, not a change to the site. It shows the headroom exists; capturing it permanently means making the same changes at the source, which is what the "fix it yourself" section is for.