Most of my content isn't cached

Testing with the following page, it seems that much of my content isn’t cached on the Cloudflare servers:

I have used WebPageTest to check if my content is cahed by Cloudflare.
I get the following result:

If I look at the first request, which I guess is the HTML page, I get this header: cf-cache-status: HIT
But if I look at .css, .js or .jpg files from my domain, I don’t see a cf-cache-status. But I do still have the cf-ray header

Looking at the filetypes that Cloudflare caches, I would expecct to see more of my content being cached. Especially my images.

According to the following link, a missing cache-status header could mean that the files is not on the list of files that would be cached, as long as I still have the cf-ray header
That doesn’t seem to be my problem though, as it is .css, .js & .jpg files (amongst others) I’m having problems with. Where all of these files are on the list of extenstions that Cloudflare caches

My first The first thing I though, was that something might be wrong regarding my pagerules. But I have the following 3 rules, and I can’t seem to see that they should create the problem?

What could be my problem? Is this a common issue?
I’m on the free tier, could this be the problem?

1 Like

Hi @Squazz,

Your second page rule seems to be the culprit. Since /wp-* will match /wp-admin/, /wp-login.php, /wp-json.php, but also /wp-content/*, where your static files are located (images, JS, CSS etc), it cannot have the “Cache Level: Bypass” setting. Just remove this setting.

Bear in mind that just by placing this rule before the “cache everything” page rule, as you have it now, you are already preventing any HTML content in these files and folders from being cached, because they are not cached by default and the page rule prevents the cache-everything page rule from being triggered, as only one page rule is triggered for any given URL. At the same time, the static content on /wp-content/*, which is cacheable by default, will be cached once the “bypass” setting is dropped.

Also, for the same reason, you may want to remove the Disable Performance on your second rule, and replace it instead with a Rocker Loader: OFF setting. RL is known to create conflicts with some WordPress plugins in the back end. But disabling performance in general would also disable other performance features, such as minification, Polish, and Mirage.

Last, purge your cache (purge everything) after you change your settings, then visit your pages again a couple of times to see if it works.


@cbrandt, you are of course right :slight_smile: I hadn’t thought about Wp-content when I made that rule. I just wanted to ensure that wp-admin and similar pages wouldn’t be cached on Cloudflare. Do you have an idea for how I can target the administration parts of WordPress?

Will removing the bypass setting be enough? That is what I understood from this part:

Yes, just remove that setting.

This is what I have in both of my static-content WordPress sites:

With that, all my images, CSS, JS etc under /wp-content/uploads are cached, while /wp-admin/, /wp-login.php and /wp-json.php are not.

Of course you can always adapt the settings to adjust for specific needs of your website.

1 Like

Thank you so much for your reply @cbrandt :slight_smile: It makes sense for me now, and it seems to really work! :wink: I would have loved if the wordpress plugin and it’s suggested settings set this up automatically :wink:

1 Like

I had a major ah-ha moment last night after @cbrandt suggested Page Rules such as his image above. (I don’t use Rule #1 because WordPress already redirects to the proper URL)

  1. I use a Cookie Bypass Worker so logged in users see live content. This includes Previews, such as your ?p=* page rule. This worker is assigned to route:*
  2. I assign Workers script: None (it’s in there, as a “no script assigned”) to routes* and* (I do this because the Bypass-Cookie worker throws a cache-buster parameter in the URL, and it seems to mess up wp-admin and interferes with wp-login)

The downside to all this, and there’s no way around it, is that logged in users need to hit your server for dynamic page content.

  1. Hopefully @cbrandt can review this. I think there may be more places to assign the “None” Worker so the cache buster doesn’t take effect, such as wp-content, but that may interfere with Woo-Commerce, or maybe just wp-content/uploads. At worst, logged in users won’t get some resources cached.

@sdayman I’ve been wanting to look into workers. The usecase you are talking about makes perfect sense as something I could use! :smiley:


@sdayman, since you are using Workers, you should consider enabling Rule #1. One of the advantages of the canonical redirect at the edge, besides the obvious savings in bandwidth and server activity, is that you can set your Workers routes to only the canonical URLs.

So if you use any worker that needs to apply to all requests coming to your website, such as a security-related worker, for instance, you can avoid using the wildcard prefix (* and only route the worker to the canonical version of your website, either or, as well as of course to any subdomains your site may have.

In case of a sudden increase in traffic, either legit or malicious, your worker will only run after the canonical redirect is done, with the potential of saving you a few bucks depending on how big the traffic gets in such a scenario.

1 Like

I’m not familiar with Woo Commerce, so I’m not the best person to look into this.

My hope is that someone will write a theme someday that will segregate the dynamic portions of an HTML page into embeds, so that the basic HTML could be cached for everyone, with the embeds (login, your purchases, etc) loading subsequently for the logged-in users. :joy: I don’t even know if that’s possible, but hey, we can always dream, can’t we?


It is, but it’s work, and as far as I’ve experienced, most of the Wordpress community is frontenders with little to no knowledge of how the backend code works :wink:
And I don’t even think that such selling points, are points that would sell any better than a slick design :wink:

1 Like

This topic was automatically closed after 31 days. New replies are no longer allowed.