A cache plugin is the cheapest performance win on a WordPress site and the easiest way to stop looking at a problem. Both are true at once, which is why "we installed a cache plugin" is the start of a performance conversation with a client, not the end of one. Here is what it fixes, what it papers over, and how to tell the two apart in ten minutes per site.
What a page cache actually does
WordPress builds every page from scratch on each request: PHP boots, loads the theme and every active plugin, runs a few dozen database queries, and assembles HTML. On a healthy site that takes a few hundred milliseconds; with 40 plugins and a page builder it can take two or three seconds before a single byte reaches the browser.
A page cache stores the finished HTML the first time a page is built and hands that copy to the next visitor. PHP never runs. The database is never touched. Time to first byte drops from "however long WordPress takes" to "however long the server takes to read a file", usually tens of milliseconds.
That is the whole trick. Two things follow from it:
- It only helps the part of the load that happens on the server. It does nothing for a 4 MB hero image or 30 render-blocking scripts.
- It only helps pages that can be served the same way to everyone. Logged-in users, carts, checkouts and member areas are excluded (or must be), so the pages that matter most to a store are the ones a cache helps least.
When a cache plugin genuinely helps
The clean case is a content site: a brochure site, a blog, a firm's marketing site. Most visitors are anonymous, most pages change rarely, and the expensive part of each request is WordPress itself. Google's Largest Contentful Paint threshold for "good" is 2.5 seconds at the 75th percentile (web.dev), and on a content site a slow server is often the only thing standing between the site and that number.
It also helps the site survive the moments that matter. A newsletter goes out, a local news story links to the client, and 500 people arrive in the same minute. Without a cache that is 500 full WordPress builds competing for the same PHP workers on a $15/month shared plan. With one it is 500 file reads. The site stays up and you never get the 9pm "is the site down?" text.
When it hides a problem
The cache serves the second visitor. The first visitor, the one who hits a page after it has been purged or has expired, still gets the full build. So does every logged-in editor, every customer with something in a cart, and every bot that hits a URL variation the cache treats as new. If the build takes three seconds, those people wait three seconds, and your monitoring, which requests the home page like an anonymous visitor, reports everything as fine.
The arithmetic for a typical client store: 2,000 page views a day, an 85% cache hit rate, an uncached build of 2.8 seconds. That is 300 uncached views a day, each about 2.5 seconds slower than a cached one: 750 seconds of waiting a day, 12.5 minutes, concentrated on the people about to pay. The home page speed test the client ran says the site is fast. Their checkout is not.
The second thing a cache hides is a plugin that is quietly getting worse. A plugin that adds 200 ms per request today and 600 ms after three more updates is invisible behind a cache until a purge-everything event, a theme update or a menu change, lands during peak traffic and the server falls over rebuilding everything at once. "The site was fine for a year and then it just died" is usually this.
The third is staleness, which looks like a bug to the client. A price changes in WooCommerce and the category page shows the old one for an hour. Clients do not report this as "cache not purged"; they report it as "your update broke the site", and it costs you an hour to work out that nothing broke.
The ten-minute check for every site on a care plan
Once a quarter per site, or after any big plugin change, measure the thing the cache is hiding:
- Time an uncached request. Add a query string nobody uses (
?nocache=1works on most setups, or purge one page and request it immediately) and record the time to first byte. Under 500 ms is fine. Over 1.5 s means the cache is doing load-bearing work and a cache miss costs real money. - Time a cached request to the same page. The gap is what the cache is worth on that site, and what every logged-in or checkout visitor pays.
- Request the page as a logged-in user. This is the number your client's own staff live with.
- Check the purge rules. Edit a post, change a price, update a menu: does the right page refresh, and does changing the menu refresh every page? Most staleness tickets come from a cache that purges the post but not the listing it appears on.
- Read the excluded-URL list. Cart, checkout, account and anything with a session cookie should be on it. If the previous agency installed the plugin, do not assume.
Put the numbers from steps 1 to 3 in the client's monthly report next to the Core Web Vitals you already track (the monthly CWV post covers which three). A single "page speed score" hides exactly the gap you just measured.
Two caches is one too many
The most common mess on a site that changes agencies is stacked caching: the host caches pages at the edge, a cache plugin caches them on the server, and a CDN caches them again in front. Each layer has its own purge rules and expiry, so a change can take three purges to reach a visitor, and nobody can say which layer served a stale page. Managed hosts such as Kinsta and WP Engine run their own page cache and tell you not to add a second one. Believe them.
The rule: one page cache per site. If the host provides one, use the host's. If not, one plugin, on the care-plan checklist with its purge rules written down. Everything else, browser caching, compression, image sizing, script deferral, is a separate decision, not a box to tick on install day. "Minify and combine everything" has broken more client sites than slow servers ever did; the visual regressions post exists partly because of it.
Purge after every update, not just after every edit
The purge event most agencies forget is their own maintenance. You update 14 plugins on a Tuesday night; the cached HTML was built with the old versions of their scripts and styles. Until it expires or someone purges it, visitors get new JavaScript under old HTML, and you get a "the slider stopped working" ticket on Wednesday that resolves itself by Thursday. Every update run should end with a full purge, a warm-up of the main pages and a screenshot of the home page, so the first visitor after your maintenance is you.
This is the piece WPClientHub One 2.0's page cache is built around: it lives on the client's own server, purges the affected pages after updates, restores and database cleanups, warms the site again afterwards, and steps aside if WP Rocket, LiteSpeed Cache, W3 Total Cache or a caching host is already in charge, so you never end up with the stacked-cache mess above. It is on every plan, free for 3 sites, paid plans from $19/month, and it is rolling out to sites now.
Where this leaves you
A page cache belongs on almost every content site and needs measuring on every site with a login or a cart. The number to care about is not the cached home page but the uncached one, because that is what the people who pay your client actually experience. Measure it once a quarter, keep one cache per site, and purge after your own updates, not just the client's edits. If you want purge-after-update, warm-up and the before/after numbers handled from one dashboard across every site on your care plans, start with 3 sites free.