Caching is storing a copy of something that was expensive to produce so that the next request for it can be served from the copy instead of being produced again. On a website that means saving the finished HTML of a page, the result of a database query, a compiled block of code or a static file, and handing out the saved version until it changes. Caching is the single largest lever on how fast a WordPress site feels, because WordPress builds every page from the database on each request unless something tells it not to.

It is also the most common source of “but I just changed that” confusion, because a cache that is working correctly is, by design, showing visitors something older than the live version. Knowing which caches a site has, what each one stores and how each one is cleared is the difference between a fast site and a fast site that serves stale content.

The layers of caching on a WordPress site

A typical managed WordPress site has five or six caches stacked between the visitor and the database. They work independently, and each has to be considered separately.

  • Browser cache. The visitor’s own browser keeps copies of images, CSS, JavaScript and fonts, controlled by Cache-Control and Expires headers the server sends. A returning visitor does not re-download them. Set by the host or theme; cleared by the visitor or by changing the file’s name or version string.
  • CDN and edge cache. A content delivery network stores static files, and sometimes whole pages, on servers near the visitor. WP Engine, Cloudflare and similar services run one in front of the site.
  • Page cache. The finished HTML of each page, saved after the first visitor requests it and served to everyone after, bypassing PHP and the database entirely. This is the cache that makes the biggest difference. Provided by the host (WP Engine’s page cache), a plugin (WP Rocket, W3 Total Cache) or both.
  • Object cache. The results of database queries and expensive calculations, stored in memory (Redis or Memcached) so repeated queries within and across requests do not hit the database. Matters most for logged-in users, WooCommerce stores and anything the page cache cannot serve.
  • Opcode cache. PHP’s compiled code (OPcache), so the server does not re-parse the theme and plugins on every request. Almost always on by default on managed hosting and rarely something to think about.
  • Transients and application caches. WordPress’s own mechanism for storing temporary values (API responses, feed data, menu output) in the database or object cache with an expiry.

Request flow runs from the top of that list down. A page served from the CDN never reaches the page cache; a page served from the page cache never reaches PHP. The further down the list a request has to go, the slower it is.

What can and cannot be cached

Page caching works for pages that look the same for everyone: service pages, blog posts, the homepage. It does not work, and is usually bypassed automatically, for pages that differ per visitor: a logged-in dashboard, a shopping cart, checkout, a membership area, search results, anything with a nonce or a personalized greeting. That is why WooCommerce stores and membership sites feel slower than brochure sites on the same host: a larger share of their traffic cannot be served from the page cache and has to run PHP and the database every time. For those sites the object cache does the heavy lifting, and the quality of the theme’s queries starts to matter.

Content that changes per visitor can still be built on a cached page. The common pattern is to cache the page and fetch the dynamic part (cart count, logged-in name, A/B test variant) with a small request after the page loads. Done badly, that pattern causes layout shift; done well, it keeps the page cacheable without showing the wrong name to the wrong person.

Cache invalidation: the hard part

A cache is only useful if it is cleared when the underlying content changes, and this is where most problems live. Publishing a post should purge the post, the homepage, the archives it appears on and any page that lists recent posts. Changing a menu should purge every page. Editing a template should purge everything. Hosts and caching plugins handle the common cases automatically and miss the uncommon ones, which is why a redirect added in theme code, a change to a sitemap, or an edit made through the REST API or a script can appear not to work: the old copy is still being served.

The habit that prevents this is simple: after any change that did not go through the normal editor, purge the page cache and check the live URL in a private window, or with a query string that bypasses the cache. On this site every content change made through our editing tools ends with a purge of the page, minified-asset and object caches, because we learned the alternative the hard way when a corrected sitemap kept serving its stale copy to Google from an edge cache for weeks.

Caching and performance measurement

Caching changes what a speed test measures. The first request for a page after a purge is a cache miss and runs the full WordPress stack; every request after is a hit and runs almost nothing. A Lighthouse run on a freshly purged page reports the slow path, and one on a warm page reports the fast one, which explains most of the wild variation people see between runs. Real-user Core Web Vitals data in Search Console reflects the mix visitors actually experience, and on a well-cached site that is mostly hits.

Caching also cannot fix everything. It makes the server’s response fast; it does nothing about a 4 MB hero image, render-blocking scripts, a font loaded from three places or layout shift from an ad slot. Those are front-end problems, and the PageSpeed case study shows what moves when they are fixed in the theme rather than papered over with a plugin. Our list of ten ways to speed up a WordPress site puts caching first for a reason, but it is first of ten.

Common caching mistakes

  • Two page caches fighting. A host-level cache plus a caching plugin that is also page caching, each with its own purge rules. Use the host’s page cache and keep the plugin for what the host does not do (minification, lazy loading, critical CSS).
  • Caching logged-in pages. Misconfigured rules that serve one user’s account page to another. Managed hosts prevent this; self-managed servers sometimes do not.
  • Short or missing browser cache headers. Static files re-downloaded on every visit because the server sends no Cache-Control header, or a one-hour one. A year is the normal value for versioned assets.
  • Caching the sitemap, robots.txt or redirects at the edge. Files search engines rely on being current, served stale. Exclude them from long edge caching or purge them explicitly after changes.
  • Plugins that break cacheability. A plugin that sets a cookie on every visit, or adds a nonce to every page, can turn a fully cacheable site into one that misses on every request. Common with some analytics, consent and security plugins.
  • Clearing everything on every save. The opposite failure: a full purge on each edit means the whole site runs cold after every typo fix. Purge what changed.

Caching on WP Engine

We host client sites on WP Engine, which runs a page cache and an object cache at the server level and a CDN in front of them, with purge hooks that fire on normal WordPress saves. The practical consequences: there is no need for a plugin’s page cache, the object cache should be enabled per site from the host’s portal, and the “Clear all caches” button in the admin bar is the first thing to press when a change is not showing. WP Rocket still earns its place for front-end work (minification, delayed JavaScript, lazy loading, critical CSS) but its page cache should be left to the host. Our maintenance plans include checking this configuration, because a host migration or a plugin update is enough to change it.

Caching and the theme

A cache hides a slow theme from most visitors and exposes it to the ones who matter: the first visitor after a purge, logged-in users, and search engine crawlers that arrive before the cache is warm. A theme that runs 300 database queries to build a page is slow on every miss, however good the cache, and a page builder that adds its own scripts and markup to every page is slow on every hit. The database optimization and custom theme work that makes a site fast without a cache is what makes it fast with one.

Getting the caching layers configured, purged and measured correctly is part of our page speed optimization services. If your site is slow despite a caching plugin, or shows visitors content you changed an hour ago, book a discovery call and we will find which layer is responsible.