Slow sites are rarely slow for the reason you were told

We measure the uncached number first

Add a random query string to a URL and most caches treat it as a page they have never seen. That gives you the real server response time. Under a second is healthy. Three seconds is a problem. Above ten and something is broken rather than merely slow.

We also measure field data from real visitors rather than a single lab score, because a lab score taken from one location on one connection tells you very little about customers in three cities on four networks.

One thing we are careful about: never measuring during our own crawl. That gives you the number for a server under load, which is a different question and has misled more than one agency into blaming the wrong thing.

Where the seconds usually actually are

The database, more often than anything else. One site was being killed roughly every forty minutes because its buffer pool was set to five times the RAM the server actually had. Between crashes the server looked completely idle, which is exactly why nobody had suspected it.

A full opcode cache. When PHP's compiled-code cache fills up, the site keeps working and simply recompiles constantly. The tell is autoloader frames dominating the slow query log — those are not slow queries, they are a symptom of something else.

Scheduled tasks that stopped. One site had them dead for 23 days with no alert of any kind. The only visible evidence was a 492 MB sessions table nobody was clearing.

Cache layers hide each other, so they get untangled one at a time

Object cache, page cache and CDN each mask the other two's faults. Turning them all on at once and measuring tells you nothing about which is helping.

So each gets isolated and verified independently. It takes longer and it is the only way to know what actually did the work — and to know which layer to look at when something breaks in six months.

This is also where we find configurations that are actively harmful rather than merely useless. A minification setting that saved zero bytes gzipped and broke a layout. A bad-bot plugin whose honeypot link was itself an uncacheable full-bootstrap request.

The plugin installed to make it fast was the reason it was slow

A store came to us with the strangest symptom shape there is: cached pages in 0.27 seconds, uncached pages in 24 to 46. The homepage looked perfect to anyone spot-checking it. Cart, checkout, my-account, search and every first-time visitor were unusable.

The cause was a persistent object cache plugin — installed, by someone, to make the site faster. We benchmarked it in-process against plain memory: 703 milliseconds against 2.5. Two hundred and eighty-one times slower. Its backing file had grown to 121 MB with a 130 MB write-ahead log that had never once been checkpointed, on shared disk doing 5.5 ms per write.

A persistent object cache is only a win when the store behind it is faster than simply regenerating the value. On oversubscribed shared disk it inverts, and every one of the tens of thousands of cache writes a store page performs becomes a disk sync. The plugin's own connection test reported the backend healthy throughout.

Speed and capacity are two different numbers, and only one of them is your problem

Measured on the same three pages minutes apart on one site: served one at a time on a quiet box, 1.5 to 3 seconds. Four requests back to back, 112 seconds, 88 seconds, 60 seconds.

Per-request speed was never that site's problem. A small box with a full opcode cache has no headroom, so concurrency is what collapses it — and concurrency is what a real Tuesday afternoon looks like. We will admit to getting this wrong ourselves: we once reported an 88-second shop page that turned out to be our own parallel testing. Space the requests out or you measure yourself.

It has a corollary worth knowing before anyone clicks the tempting button: a full cache purge on an undersized server is a self-inflicted outage. Every visitor and every crawler arrives at once as an uncached render. Warm the important pages first, or purge in stages.

The tell for this class of problem is in the slow log, and it is not a slow query. If the traces are full of autoloader and file-include frames, the answer is the opcode cache, not the database. On one site 52 plugins compiled to 135 MB of PHP against a 128 MB cache — nothing fit, so every request recompiled from disk, burning both cores.

Most of what is sold as optimisation is not, and some of it is a liability

We measure before we keep anything. On one store the minification everyone assumes is free was re-minifying stylesheets that already shipped minified. Gzipped, the three largest files went from 36,373 bytes to 36,398 — 25 bytes *larger*, for a feature that was also silently breaking the site whenever its cache directory was cleared while a cached page survived.

The same goes for a database problem that is really a scheduling one. One store's session table had reached 492 MB — bigger than its post content — because a constant in the config promised something else would run scheduled tasks, and nothing ever did. It had been dead for 23 days and WordPress gives no warning at all.

On another store the same table held 329 MB, and it was not customers. 99.1% of those sessions carried an add-to-cart notice against six real orders in 48 hours — a crawler walking the add-to-cart links on the shop grid, minting a session per hit. The site already disallowed those URLs in robots.txt and marked every link nofollow. The bots ignored both, so it had to be enforced at the server.

Cloudflare, done properly or not at all

Cloudflare's free plan does not include Indian data centres. We measured an India-hosted site being served out of Singapore, and turning the proxy off made it four and a half times faster. A CDN pointed at the wrong continent is a downgrade.

Cache rules are order-dependent, and the last matching rule wins. We have found a bypass rule sitting above a cache-everything rule, quietly caching logged-in carts and serving one customer another customer's basket.

And WAF rules need to know about your own site's internals. A bot rule that also matches your cart's AJAX endpoint will break every add-to-cart on the site, and it will do it silently.