WordPress Caching Explained

WordPress builds every page from scratch on every request: run PHP, query the database, assemble HTML. For a page that has not changed in three months, that is the same work repeated for every visitor.

Caching is how you stop doing it.

Page caching — the big one

Stores the finished HTML and serves that instead of rebuilding it. On an uncached site this is the single largest available improvement.

What it does not cover:

• pages that must be per-user: cart, checkout, account, anything logged-in
• anything genuinely dynamic

Which is why it helps a brochure site enormously and a WooCommerce store only partially. Improving WooCommerce store performance covers what to do about the gap.

Object caching

Stores the results of database queries in memory, so a repeated query does not hit the database again.

Matters most on complex sites and on the pages page caching cannot touch. Needs Redis or Memcached available on the host — not all shared hosting provides it.

Browser caching

Headers telling the browser to keep static assets locally. A returning visitor re-downloads much less.

Mostly a hosting or server configuration item. Long expiry on versioned assets, short on HTML.

CDN

Serves static files from a location near the visitor. Helps geographically distributed audiences most; helps a purely local business least.

Also provides some protection against traffic spikes, which is worth something independently of speed.

How they stack

Visitor ↓ Browser cache — nothing leaves the device ↓ CDN — static assets from a nearby edge ↓ Page cache — pre-built HTML, no PHP ↓ Object cache — avoid repeating database queries ↓ PHP + MySQL — the work you were trying to avoid

Each layer that handles a request means the ones below it never run.

Where it goes wrong

Two page-caching plugins. They fight, produce inconsistent results, and are harder to debug than either alone. Pick one.

Caching plus a host-level cache, unconfigured. Many managed hosts cache at the server. Adding a plugin cache on top without knowing means clearing one does not clear the other, and you will chase ghosts.

Caching pages that should not be cached. Logged-in views, carts, personalised content. Exclusions need to be set, not assumed.

Never clearing it. You update a page, it does not change, you conclude the update did not save. Know how to purge, and confirm changes as a logged-out visitor.

Testing whether it is actually working

Load a page twice and check the response headers for a cache indicator — most caching layers add one. Or compare Time to First Byte on a first and second load.

If TTFB is unchanged between loads, your cache is not doing what you think.

What caching does not fix

• INP. JavaScript still runs in the visitor's browser regardless of how the HTML got there.
• Heavy pages. Caching serves the same 4MB page faster, not smaller.
• Layout shift. Entirely unrelated.

Caching addresses server work. If your problem is payload or main-thread work, it will not help — which is why diagnosing which kind of slow you have comes first.