A slow WordPress site does not always need another optimization plugin

“The site is slow” is a symptom. Underneath it sit at least four layers that can each produce that symptom on their own, and they routinely produce it together. Installing an optimization plugin before knowing which one is responsible does two things: it sometimes helps, and it always makes the next diagnosis harder.

The four layers

1. Hosting — how long until the first byte

If the server takes a long time to produce the first byte of an uncached page, nothing downstream will save you. Minifying CSS does not fix a slow database query. Check the server response for a page that is definitely not cached, and check it repeatedly rather than once — shared hosting is inconsistent by design.

2. Delivery — the CDN, if there is one

A CDN that is passing everything through to origin is a slower CDN than no CDN, because you have added a hop. The question is not “is Cloudflare enabled” but “what is it actually serving from cache, and what is it refusing to”. Response headers answer this; the dashboard summary often does not.

3. Cache — what is really being cached

This is where most WordPress performance work quietly fails. A page cache that is bypassed for logged-in users, for anything with a query string, or for every page carrying a cart fragment, is a cache that does not exist for a large share of real traffic. Test as a logged-out visitor, then as a logged-in one, and compare.

4. Application — the site's own weight

Plugin count, uncompressed images, render-blocking assets and third-party scripts. Third-party scripts deserve their own pass: they are frequently the largest single cost on a business site and the easiest to remove, because someone added them for a campaign that ended two years ago.

Why the second caching plugin hurts

Two caching layers do not compose. They each decide independently what to store, when to invalidate it and which requests to skip — and the union of two exclusion rules is a larger set of uncached requests, not a smaller one. Worse, you can no longer attribute a change to either of them, which is the thing you actually needed.

Lab numbers and real users

Lab data

A synthetic test run on a fixed device and connection. Reproducible, good for debugging, and not a description of your visitors.

Field data

What real visitors experienced, on their devices and networks. Slower to react, harder to debug with, and the number that actually matters.

A site can hold a high lab score and still fail Core Web Vitals in the field, usually because the test device is nothing like the phone your customers use. Optimising for the score rather than the experience is how sites end up fast in a report and slow in a hand.