Low Cloudflare Cache Rate on Cloudflare Pro with APO enabled

On NamibiaExperience.com we are using Cloudflare Pro with APO enabled. It’s a WP website and has the official Cloudflare plugin set up. The cache rate for the last 7 and last 30 days is always around 60%. Having had various sites on Cloudflare APO I have never seen such a low cache rate. Every other WP site I’ve had on APO has had cache rates of over 80%, mostly well above that. I cannot tell from Cloudflare cache analytics why the cache rate would be this low for this site.

Caching report available here: https://drive.google.com/file/d/1kCOyeCMedTwjtOiUuDigMPv0W8uF61Q9/view?usp=sharing

Appreciate it if anyone has any tips for troubleshooting this, or an explanation.


Every WordPress site is a jungle of different trees. A change of a plugin or two, not to mention the theme, can drastically change the cacheability of assets.

The most requested path on your site is by far xmlrpc.php, which by its own nature cannot be cached. Do you use any plugin that makes use of that service? XMLRPC allows for the interaction between WordPress sites and various other platforms. For many functions, it’s been replaced by the current REST API which responds at /wp-json/. Some plugins still make use of xmlrpc.php, such as JetPack for users of WordPress.com. It’s also used by some WordPress mobile apps. But unless you use some plugin pointing there, or you want to be able to edit posts on the go using a mobile app, you should disable it. It has become a honeypot for spammers and hackers, as it is one door to login to your WordPress site admin panel.

Also, try to understand what other “most visited paths” do and if they can be made more cacheable.

I see a translation plugin that makes ajax POST requests, which cannot be cached. If those responses are in fact just translation strings, you should try with the plugin developer if they have a non-dynamic way to serve these translations in a cacheable way, perhaps .by embedding them on the HTML itself.

1 Like

Thank you cbrandt, much appreciate your feedback. I’m going to dig into xmlrpc.php and trp-ajax.php to see what the case is with those. With xmlrpc.php I am on further inspection specifically seeing it getting hammered by connections from China, which accounts for most of the connections and is probably an indicator that it’s already a spam/hack target. So if not used by anything legitimate then I will try and disable it. And have opened a ticket with the translation plugin developer also, to see what can be done there. Thanks again.


If it is used by only the Jetpack plugin, you can easily restrict xmlrpc access to Automattic’s ASN.

1 Like

Thank you, we don’t use Jetpack and couldn’t find any legitimate use of it by anything else, so have just culled it entirely. Will now see how that affects the cache rate over the coming days.