Getting out of caching hell!

This problem crosses my path often: you’ve got aggressive caching going on and now the WordPress admin isn’t showing the right stuff. Things aren’t updating, or the admin bar is showing on pages even when you’re logged out. You update pages and you’re not sure what’s cached where.

You start to feel insane…

Let’s work out what’s going on here.

Caching basically takes the content sent to your browser (HTML, images, CSS, JavaScript) and saves it in memory, on disk, or in a database. What we’re dealing with most of the time is a lack of know-how about how caching works, and we try to apply plugins or theme options to fix things. The truth is that caching happens everywhere—often several layers deep. For the most part, smart people make these layers work well, but sometimes folks go a little cache-crazy, using too many plugins or “theme optimization features” (often just baked into the theme) and losing track of where and when things are cached. That’s when the madness starts.

Stop! Let’s focus on what caching actually does to help us:

It reduces the need for code to run

Your site works because code runs on a server somewhere and sends the result. It runs PHP, talks to a database, connects to APIs, figures out what needs to be sent to the browser—and sends it.

The browser already caches by default, but it’s not doing the same thing: when it receives content, it stores it locally. It’s easy to get confused—was this cached by the browser, or something all the way back on the server?

Screenshot of the Disable cache option in Chrome Devtools Network Panel

Pro tip: One easy way to test if it’s your browser: disable browser caching. Don’t rely on Shift+Reload. In Chrome, right-click → Inspect, go to the Network tab, and check Disable cache. Now refresh—without closing the panel. The page will load fresh: now you know it’s not the browser. Keep the panel open while you test. Other browsers have something similar.

Caching also brings content closer to the user

I won’t get too deep here, but when you type aubreypwd.com, my hosting provider dynamically picks a server near Albuquerque, NM to reduce round-trip time. If the original server were in the UK, it wouldn’t make sense to send you content from there when it’s already cached in California—or closer.

Then there’s what I like to call micro-caching

Like in WordPress—when we call another API (say pinterest.com), we might save that response in the database for a day or two.

PHP also caches compiled code in memory via Opcache. And good hosts cache content (HTML, CSS, JS, etc.) in memory using Redis, Memcached, Varnish, NGINX, etc.

Lots of micro-level caching happens automatically. These systems usually work well out of the box. Yes, they can be tuned—but they often don’t need to be.

The worst culprits tend to be themes and plugins…

So yeah, the layers can be confusing. And while most of them work great, here’s the most common cause of problems:

You’ve got a plugin (or theme) caching page content inside WordPress

Yep—most plugins (and themes) do it wrong. Page-level caching inside WordPress is almost always a bad idea. Some do an okay job, but WordPress is meant to run code and database queries on every request. That’s how you make changes and see them right away.

WordPress isn’t really meant to be cached.

Where am I going with this? Remember, caching solves just a couple of simple things:

  1. It reduces unnecessary or expensive server operations
  2. It delivers content closer to the user

That’s it. Let’s focus on #1 though. Why are expensive operations happening unnecessarily to begin with?

Often it’s bloated themes and plugins.

The system gets weighed down by features beyond core WordPress: bloated themes, heavy plugins, overloaded databases. The more you extend WordPress, the more expensive it is to compute each page. That’s normal though—but eventually, things get too bloated.

So, how do we de-bloat? Disabling plugins or changing themes isn’t always realistic, you know that. You picked them for a reason—they did what you needed—and you’ve invested a lot of time to build with those tools. But let’s be honest: those “performance features” are part of the problem.

Turn them off.

  • Check your theme for built-in caching or performance “enhancements”—turn them off
  • Check your plugins—especially the bloated ones (you know the ones). Disable any “performance” or “optimization” options they offer, especially caching ones

All these layers inside WordPress just confuse things. Now, with caching stripped out of WordPress, it’s time to get caching working for us outside WordPress.

This means working with your hosting provider

DIY plugin-based caching only makes things worse based on what I’ve seen. Use the rest of this guide to talk to support and get caching working the right way.

First—I have to mention this—consider moving to managed WordPress hosting if you haven’t already. They’ve already optimized everything for the most part. And now that you’ve de-bloated WordPress itself, you’ll get the full benefit.

But, whether you do that or not, let’s make sure caching is working properly at the hosting layer, CDN, and browser—where it belongs. Ask your host these questions:

Can you confirm what server-level caching is active?

They should mention NGINX FastCGI cache (or equivalent) and how long it stores content in days or hours. They should confirm that /wp-admin/ and logged-in users are excluded from caching (Pro tip: this is usually done by detecting WordPress login cookies, they should know that). Also ask if caches are automatically purged when content is updated.

Do you support OPcache, and can you share the configuration?

OPcache keeps precompiled PHP in memory for faster performance. The config might look like:

opcache.enable=1 
opcache.memory_consumption=256 
opcache.interned_strings_buffer=16 
opcache.max_accelerated_files=10000 
opcache.validate_timestamps=0 
opcache.revalidate_freq=0 
opcache.enable_cli=0

You don’t need to analyze this. If they can share it, it means it’s configured—and they’re aware of its performance. If they can’t, that’s a red flag.

Do you have or offer a CDN service?

Ask if it’s Cloudflare (many hosts use it). If it’s disabled, ask if they can enable it. A good answer sounds like:

Yes, we use a built-in CDN or can connect your site to Cloudflare. Static assets like CSS, JS, and images are cached globally. HTML caching is off by default to prevent dynamic content issues, but we can enable it outside the admin area if you want it on.

You want it on. This means they understand WordPress and have a good CDN caching strategy in place.

How is WP Cron handled here?

WordPress uses an internal cron system, but caching can interfere with it. A good host will say:

We disable WordPress’s default CRON (DISABLE_WP_CRON=true) and instead run a real cron job every 15 minutes that requests https://yourdomain.com/wp-cron.php?doing_wp_cron. This ensures tasks run reliably even with low traffic.

Read more about how WP CRON can cause problems outside of caching here.

Extra Credit: Do you recommend a specific plugin or setup for caching WordPress content?

A good host will say:

We already handle caching at the server level—no plugin needed. If you want more control, we recommend a lightweight plugin that works with our setup, like Cache Enabler, NGINX Helper, or LiteSpeed Cache.

If they recommend a plugin-heavy setup, they’re probably not confident in their stack—and that’s a red flag.

Now you’ve got caching where it belongs—not inside WordPress

Caching isn’t complicated: but it can be. It gets complex when you layer too much on top of WordPress. Let NGINX, PHP, your hosting provider, and the browser do the work. Avoid WordPress-level caching unless you really know what you’re doing—hire an expert!

I’m not saying all plugins are bad—I don’t love them though—but now you know how caching works a little better and where it works best: not in WordPress!