WordPress Caching Explained: Page, Object and Browser

Page caching stores the finished HTML of a page and serves it directly on the next request, skipping PHP and the database entirely. It is by far the biggest single win for a content site, because it turns a dynamic page into a static file.

It works brilliantly for anonymous visitors reading the same pages. It cannot be used where the HTML differs per visitor: a cart, a checkout, an account page, or anything showing "logged in as". Getting that exclusion list right is the whole game — a misconfigured page cache serving one customer's cart to another is a far worse problem than a slow site.

Most managed WordPress hosts do page caching at the server level, which is faster than a plugin doing it in PHP. If yours does, you often don't need a caching plugin's page caching at all, and running both can cause confusing double-caching.

Object caching stores the results of individual database queries and expensive computations in memory. WordPress has an object cache built in, but by default it only lasts for the duration of a single request — which means it saves repeat queries within one page load and nothing more.

Add a persistent backend, Redis or Memcached, and that cache survives between requests. Suddenly the queries a page runs are answered from memory instead of MySQL.

This is the layer that matters most on sites where page caching can't help: WooCommerce stores, membership sites, anything with logged-in users, and the WordPress admin itself. If your admin is slow while the front end is fast, persistent object caching is usually what's missing.

PHP compiles your source files into bytecode every time they run. OPcache stores that compiled bytecode in memory so it isn't recompiled on every request.

This is a server setting rather than something you install in WordPress, and on any competent host it's already on. It's worth checking though — it costs nothing and its absence is a meaningful, invisible tax on every request. If you can see your PHP info, look for OPcache being enabled with a memory limit large enough for your codebase.

Browser caching is an instruction to the visitor's browser to keep a copy of your CSS, JavaScript, images and fonts, so a second page view doesn't re-download them. It's controlled by response headers — Cache-Control and its max-age — set by the server.

The rule is simple: give versioned assets a long cache life and unversioned ones a short one. Build tools that put a content hash in the filename make this easy, because a changed file gets a new name and the old cache entry becomes irrelevant. Assets served at a fixed URL need shorter lives, or you'll be telling people to hard-refresh.

A CDN keeps copies of your files at locations near your visitors, so someone in Delhi isn't waiting on a round trip to a server in Singapore. At minimum it should serve your static assets. Configured further, it can cache full HTML pages at the edge, which is page caching that never even reaches your server.

For an Indian business with visitors abroad — or an overseas audience served from Indian hosting — this is often a bigger improvement than anything you can do on the server itself, because you're removing distance rather than processing time.

Do them one at a time and measure after each. Changing all five at once means you have no idea which one helped, and no idea which one caused the bug that shows up next week.

• Confirm OPcache is on. It's free and it's server-side.
• Add page caching, ideally at the server level, with cart, checkout, account and any personalised pages excluded.
• Add persistent object caching if the site has logged-in users, a store, or a slow admin.
• Set sensible browser cache headers on static assets.
• Put a CDN in front, starting with static assets and extending to full-page caching if the site suits it.

• The page being tested was already cached, so you measured the cache both times.
• The site is slow for a reason caching doesn't touch — a huge unoptimised hero image, or a third-party script blocking rendering.
• You're logged in. Most page caches bypass logged-in users entirely, so you're seeing the uncached site while your visitors see the cached one.
• A plugin is setting a cookie on every request, which many page caches treat as a signal not to cache.
• The host was already page-caching at the server level, so the plugin added nothing.

Almost every caching complaint I get is actually an invalidation complaint: I updated the page and it still shows the old version. Caching is easy; knowing when to throw a cached copy away is not.

Make sure publishing or updating a post purges that page, the archives it appears on, and the homepage if it's listed there. Make sure a product price change purges the product page and the shop archive. And keep a way to purge everything for when something slips through.

Be careful with very long cache lifetimes on pages that contain anything time-sensitive. A stock level or a price cached for a week is worse than a slower page.

One, or sometimes none. Two caching plugins fighting over the same job is a reliable source of bizarre behaviour: half-purged caches, minification breaking on some pages, assets served from a stale copy.

Pick one, or rely on your host's server-level caching plus a persistent object cache. Then leave it alone. A caching setup you understand and can debug is worth more than an aggressive one you can't.