Purpose-Built Templates

ZU2B Blueprints

Business in a Box

  • Purpose-built launch kits for local service businesses — website, copy, prompts, SEO, and more.
  • Local Launch Kits →

Website Widgets

  • Working features you install once and own outright — no plugin, no subscription.
  • Chat Widget — Coming Soon

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free

“It’s Not Working” — When You’re Actually Fighting Three Caches, Not One

Field Note #108
🔬 Generalized 🟡 Intermediate ⏱ 30 Minutes ✓ Observation from Experience
You make a change. You clear your caching plugin. You reload. The old version is still there. You clear it again, harder this time, out of pure frustration. Still nothing.
The instinct here is to assume the fix itself failed — maybe the code was wrong, maybe you saved it in the wrong place. But on most real hosting setups, there isn’t just one cache standing between your edit and your visitor. There are usually two or three, stacked on top of each other, and clearing only one of them accomplishes nothing.

The three layers, and what each one actually does
Asset optimization (e.g. Autoptimize) — combines and minifies your CSS/JS into bundled files. It doesn’t cache your page’s HTML; it caches the ingredients.
Full-page cache (e.g. WP Super Cache) — saves a static HTML snapshot of an entire rendered page, so the server doesn’t have to rerun PHP and database queries on every visit.
Host or CDN-level cache — many managed hosts (and any CDN/firewall sitting in front of your site) cache responses at the network edge, closer to the visitor than your server. This layer often caches static file types — .js, .css, .jpg — even more aggressively than your own plugins do.
Each layer sits in front of the one below it. A change you make has to survive all three before a real visitor sees it.

Why clearing them in the wrong order wastes your time
If you clear the outermost layer (the host/CDN cache) first, but a stale full-page cache is still sitting underneath it, the very next visit just re-populates the outer cache with that same stale page. You’ve cleared something for nothing — the CDN dutifully fetched the “fresh” version, which wasn’t actually fresh at all.

The fix: clear from the inside out
Asset optimization plugin first — regenerate the actual CSS/JS bundles.
Full-page cache second — regenerate HTML using those new bundles.
Host/CDN cache last — so when it re-fetches from your origin, it grabs the genuinely current version.
Then hard-refresh your browser (or check in an incognito window), since your own browser cache is a fourth, entirely separate layer.

How to confirm which layer is actually stale
Don’t guess — check the source directly. View-source the live page (not the rendered page) and search for the specific thing you changed. If it’s genuinely gone from the raw HTML but a tool or scanner still reports the old behavior, the problem has moved from your caches to something scanning/reporting a stale result on its own — a different kind of staleness entirely, and clearing your site’s caches further won’t touch it.

How to avoid the confusion next time
Write down every caching layer your specific hosting setup has — plugin-level, host-level, CDN-level — the first time you find them all. It’s genuinely easy to forget one exists, especially a host-provided layer that isn’t a plugin you installed and don’t see in your normal WordPress dashboard. Once you have the full list, clearing cache after a real change becomes a fast, three-click habit instead of a guessing game.

Tagged in :

More from the field