Why "install a caching plugin" is not an answer
Every slow WordPress site has been told to install a caching plugin, and most of them have three. The advice is not wrong, it is incomplete. Caching in WordPress happens at four different layers, each solving a different problem, and stacking plugins that all do the same layer while ignoring the others is how a site ends up with cache-busting query strings, stale content and no measurable speed-up.
Here is what each layer does, in the order a request passes through them.
Layer 1: the CDN and edge cache
What it does: stores copies of your pages and assets on servers near the visitor, so a request from Sydney is answered from Sydney rather than from your host in Frankfurt.
What it speeds up: time to first byte for cached pages, and every static asset: images, CSS, JavaScript, fonts. For a global audience this is the largest single latency win available.
What it does not do: speed up anything the origin has to compute per request, unless you configure the edge to cache full pages, which most WordPress sites do not because of logged-in users, carts and personalisation.
Tools: Cloudflare, Fastly, Bunny, or the CDN bundled with a managed host. Full-page edge caching for WordPress needs cache rules that bypass for logged-in cookies and cart cookies, and a purge hook when content changes.
Layer 2: the page cache
What it does: stores the finished HTML of a page on your server, so the next request for the same page is served as a file instead of running WordPress, its theme and every plugin.
What it speeds up: server response time for anonymous visitors, dramatically. A page that takes 800 milliseconds to generate is served in 20.
What it does not do: help logged-in users, carts, checkouts, or any page that must differ per visitor. Those bypass the page cache by design, which is why a WooCommerce checkout is not made faster by a page cache and why "my site is fast except the checkout" is such a common complaint.
Tools: the host's built-in page cache (WP Engine, Kinsta, SiteGround and Cloudways all have one), or a plugin such as WP Rocket, Cache Enabler or W3 Total Cache. Use one. Two page caches fight over invalidation and serve stale pages.
The misconfiguration: caching pages that should not be cached. A form's nonce cached for twelve hours means every submission fails validation. A cart fragment cached means visitors see somebody else's cart count. Exclude the dynamic endpoints explicitly.
Layer 3: the object cache
What it does: stores the results of database queries and expensive computations in memory, in Redis or Memcached, so WordPress does not run the same queries on every request.
What it speeds up: everything the page cache cannot: logged-in pages, admin screens, checkouts, search, and the first uncached hit on any page. On a store or membership site with thousands of options and meta lookups, a persistent object cache can halve the time to generate a dynamic page.
What it does not do: help a small brochure site that is already fully page-cached. If every visitor gets a cached page, the object cache rarely runs.
Tools: Redis or Memcached provided by the host, plus a drop-in plugin such as Redis Object Cache or the host's equivalent. This is the layer most often missing on stores that complain about slow admin and slow checkout.
The misconfiguration: no eviction policy, so the cache fills and everything slows; or caching objects that change constantly, so the cache never hits. Monitor the hit rate.
Layer 4: the opcode cache
What it does: PHP is compiled to bytecode every time a file runs. OPcache keeps the compiled bytecode in memory so PHP skips compilation on subsequent requests.
What it speeds up: every PHP execution, by a meaningful margin, at zero application risk.
What it does not do: anything visible if it is already on, and it is on by default on nearly all modern hosting. Check phpinfo() or your host's panel. If it is off, turning it on is the cheapest speed-up on this list.
Which layers a given site needs
| Site type | CDN | Page cache | Object cache | OPcache | | --- | --- | --- | --- | --- | | Brochure or booking-led business site | Yes | Yes | Optional | Yes | | Blog or content site with global readers | Yes, ideally full-page | Yes | Optional | Yes | | WooCommerce store | Yes, assets only or with cart bypass | Yes, with cart and checkout excluded | Yes | Yes | | Membership or logged-in app | Yes, assets only | Limited | Yes | Yes |
The pattern: the more of your traffic is logged in or personalised, the more the object cache matters and the less the page cache can do.
The things caching cannot fix
A cache hides slow code from anonymous visitors. It does not make the code fast. If the admin is slow, the checkout is slow, or the first uncached visit takes four seconds, the cause is upstream: autoloaded options bloating every request, a plugin running an unindexed query, a theme making external API calls on page load, or images the size of posters.
Fix those and the caches have less to hide. Profile before you cache. Query Monitor on a staging copy shows exactly which plugin is spending the time.
A sane default stack
For most of the sites we build or rescue: the host's page cache or one good caching plugin; Redis object cache switched on for anything with a store or logins; OPcache confirmed on; Cloudflare in front for assets, with full-page edge caching only where the site has no logged-in state. One tool per layer, invalidation hooked to content changes, and the dynamic endpoints excluded by name.
If a site has three caching plugins and is still slow, the caches are not the problem. That is when a performance pass starts with the profiler, not with another plugin.