Vast majority of requests are Dynamic cache status when Cache rule should prevent that

To combat a huge number of pages on our site that we need cached (to prevent overload on origin) I have a cache rule that forces Edge TTL and Browser TTL to 1 hour.

This works correctly on my end as I always see Response Headers of either HIT or EXPIRED.

However, when I look at the Cache Overview tab, filter down to Content Type: html, Paths: /, Edge Status Codes: 200 OK I find that a vast majority of these html requests are Dynamic (seemingly missing the cache rule).

The rule is simple…URI Path does not contain /game/, Cookie does not contain wordpress_logged_in.

There are two rules below it on the priority list. Neither overlap.

Any help figuring out why such a huge number of these are missing the cache rule (and how to fix it) would be very helpful.

HTML isn’t cached by default, so you have to mark it as eligible for cache in addition to whatever other rules you have. If you want a “cache everything” rule, you can create one that just matches the hostname and makes everything eligible.

Another thing: the list of rules is last match wins, not first match, so that rule goes first and exceptions come after.

Thanks, though the rule already is set up like in your screenshot.

Like I mentioned - it works 100% of the time when I test it using my browser and examine the response headers.

However, for some reason, a huge number of requests are still, apparently, Dynamic and being served uncached from origin even with a working rule.

Any thoughts?

From your description it sounds like you have a Pro account, and thus have Cache Analytics. It’s not immediately obvious but that view can be filtered by cache status.

If you click the “Cache status” tab, then hover over “Dynamic”, you get a button to filter the view to show only those requests.

Screenshot 2023-12-20 at 4.30.07 PM

Then you can see exactly what is being requested and treated as Dynamic:

Here, almost all the “dynamic” requests are health checks. I have that /check.html path set up to bypass cache, because otherwise the health check probes will succeed even if the server is down, which is not ideal.

I have no idea what’s up with the rogue request to /. But, I don’t have anything else mysterious, using a cache everything rule. If you do, this should help narrow it down.

So you have one request that is dynamic outside the path you have set to be dynamic. That seems like…… not an issue.

Else provide a specific example of a request that is not served from cache as expected?

Also if this isn’t tens or hundreds of thousands of requests there are a lot of other per colo requests that could be in play.

That was my screenshot showing it working, not OP’s.

Yeah yeah… in the absence of data I will attribute that to OP as well. Because until then it is all hypothetical voodoo to which the answer is….