If APO is working with Wordpress, why so many MISS HTML calls?

We’re trying to find out why we have so many MISS cache requests for pages on our site.

I’m assuming APO stores a copy of the HTML on the edge, yet we’re seeing more than 50% misses.

When a post is updated in Wordpress, does every post get purged? Or just that post? We have 8,000 posts on site so this doesn’t sound efficient.

Can anyone shed some light on this?

Thanks,

Do you have any PageRules or headers that will prevent caching for some files?
Can you provide some specific URLs that are not getting cached while they should?

  1. All rules are switched off. Browser TTL is set to 4 hours.

  2. Pages are random i.e. /who-is-daniel-ricciardo has not been updated in over a month, has plenty of traffic yet is one of the most MISS’d HTML pages.

  3. Desktop seems to be the worst offender. 80% of our traffic is mobile, so not sure why desktop has so many misses
    Screen Shot 2022-06-20 at 1.10.27 pm

Just had a look at and I immediately got a HIT served from APO. So I can not reproduce that right now. But there are some things to check to make sure it’s nothing obvious:

  • make sure your site does not randomly set cookies, on which APO and your other caching tool behind Cloudflare are bypassing cache. Since APO and your other tool will bypass cache on certain cookies.
  • make sure you don’t set/change your Edge TTL as APO automatically chooses 30d AFAIK.

But I tbh have to say the situation is not optimal to debug. Would really be cool if we on cache MISS would have better statistics and resons.

I personally would wish for:

URLs that can and should be cached should be tracked by Cloudflare like this:

Reason for MISS:

  • praga no-cache (hardreload or disable cache)
  • headers
  • PageRule
  • cookies

like this you would immediately find the reason for APO bypassing cache, or not building up cache. Maybe that could be a cool feature request - “Reasons for not cached”

3 Likes

One avenue that might be worth looking at is the Cache-Control header sent by your server.

I had a quick look at what I assume is your website (used “inurl” on Google – assuming you’re DMARGE), and the first thing I noticed was an odd value here: “s-max-age=”.

This seems to be mal-formed. First, the correct RFC-specified directive is s-maxage (apparently I can’t include links in posts… see RFC9111 if interested), not s-max-age. Second, the directive isn’t assigned a value.

I have no idea if this is the cause, however, as I don’t know how Cloudflare would handle this.

3 Likes

Okay thanks. We’re looking into both now.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.