Caching problem with wordpress site

currently i have an issue with the caching of my wordpress page in CF.
Whats the problem(s):

  1. I use the pro plan in cf
  2. dns and all the things works fine
  3. page rules are enabled an on
    • one to secure the admin area
    • one to disable performance with elementor pages
    • one to enable cache wot all /wp-/ pages
  4. WAF is also on
  5. Argo is on
  6. If you need any other info about the setup, please contact me

My Wordpress setting:

  • Cloudflare Wordpress Plugin is installed and enabled

And i think, here is the problem: There was another plugin called Autoptimize that was enabled if i enable install and setup Cloudflare.
The Autoptimize plugin is deactivated and removed.
And then, the problems began!

I put here the result of a Webpagetest:

As you can see, the first test looks completely destroyed.
The second test looks normal.
Why lloks the first test destroyed?
The delivered page contains “optimized” files like content/cache/autoptimize/css/autoptimize_4b728034d747c4548391e97315be9f54.css
and yep, thats a 404, because the file isn´t on the server anymore.

But if i completely purge the CF-Cache, the problem persists.
I can reconstruct the behavior also on my local machine.

1 purge cache on cf
2 kill browser cache
3 open a page → destroyed
4 reload with F5 → normal behavior
5 Goto step 1
6 Goto step 2
7 destroyed

If i enable the developer mode on CF or bypass the dns setting to my origin webserver, then there is no problem with the site, so i believe that the “destroyed” pages are persistent in cf.

But how can i solve such a problem?

Kindly Regards,


i’ve tested some things around, and i think this behavior must be a problem with CF Cache.

  1. I clear the CF Cache
  2. I clear the browser cache
  3. I edit a page on my website and save them.
  4. call with another browser the page.
  5. The changes i did made prior are not visible on the page.
  6. Press F5 and the page looks good, with the changes.

If i check the content-page (html) with devtools when it is destroyed, there are some stupid things:
cf-cache-status: DYNAMIC --> which means cf gets the content from the origin host, but thats not true. If cf gets the page from the origin, where are my changes i made before?
x-via: speedwp/kv --> Whats that? If i google for that string, there is no information about?

If i check a 404 element from this page (a autoptimize*.css) there are also some funny headers:
expires: Wed, 11 Jan 1984 05:00:00 GMT

When i reload the page, the page looks fine.
If i check the response-header of the doc, there ist also the header x-via, but now with:
x-via: speedwp/cache

Currently i don’t now where or what the problem is, but i think it is not a problem of wp…


OK, i don’t know where my second post is?

Another spooky thing:
I’ve activated the CF Firewall.

In the last 24 hrs i see >900 entries from an ipv6 address: 2a06:98c0:3600::103 (for some reasons e.g. sqlinjection tasks …)

A check on iphostinfo says that this ip-address is owned by Cloudflare.

I’m absolutely stumped for an answer.

@CF, could you please restore my second post (between 23:00 and 0:00 CEST on 09th of Oct.).


can you check wp-cache.php in wp-content folder and rename it

i checked it via
find . -name 'wp-cache.php'
over the whole wp-installation.

Nope, there is not such a file.


I didi also checked with the following:
find . -name '*.php' | grep 'optimizly'
nope, also nothing found.

Whats suspect is for me is, that the in one of the help-texts for cf-caching-configurations, i found this text:
Hinweis: Standardmäßig werden von Cloudflare keine HTML-Inhalte zwischengespeichert.
in english:
In standard, cloudflare did not cache any html-content.

But the problematic content is the html, which try to load some js / css thats no more available.

Also the filesize of a problematic html (or from cf-cache) is: 23 KByte in size,
the current working (or what comes directly from my wp-installation) filesize of the html is 26 KByte.

Could it be a problem with argo? If i understand argo, the content with argo is better provided around the world which resulted in better loadtimes …
But in this case argo does not work properly with the purge cache function of cf…


i think i found an issue between (obviously my page) on wordpress and the Cloudflare setting:
Automatische Plattformoptimierung für WordPress -> Automatic platform optimization for wordpress

For me (or my site) this circumstance is fully repeatable.

Working part:

  1. Clean CF-Cache
  2. Disable the feature
  3. All plugins are enabled (also Autoptimize and the Cloudflare-Plugin for Wordpress)
  4. Clean all Browser-Caches
  5. Call any page of the site, all looks fine

Not working (destroyed) part:

  1. Clean CF-Cache
  2. Enable the Feature
  3. All plugins are enabled (also Autoptimize and the Cloudflare-Plugin for Wordpress)
  4. Clean all Browser-Caches
  5. Except the Startpage, any of the page looks destroyed because of loading of non existing css-files in the delivered html.

Is anybody here in this forum to confirm this behavior?
It is exactly this one feature, if i turn this on, the site does not work anymore.

I have open an official ticket on cloudflare, i hope there is a solution.
If anybody need informations about the settings of my install, please contact me or write to this ticket.

Kindly regards,

Same issue here also.

Hi @llueck the issue with CF Firewall will be solved today, we are rolling out the fix for this.


That would be very nice.
I have carried out various tests without APO and clearly see the advantages of TTFB, the other important parameters, especially if the Wordpress hoster does not deliver the pages quickly enough.
Keep up your good work!


Sorry for the confusion, on the step 5 you still hit cached page we serve from KV storage. it’s indicated by x-via: speedwp/kv header. We will rollout a change that will indicate it properly via:
cf-cache-status: HIT.

1 Like

CSUP team should be able to help, it should be a compatibility issue between your CF configuration (Page rules, Argo) and APO, or Wordpress plugins and APO.

1 Like

I’ve wrote an official ticket (1996835) on CF that describes also the problem (and refers to this community ticket).
Since last friday the ticket state is currently open (a colleague of yours saw the ticket and set it to high priority, whatever that means). :wink:

Hopefully this problem is also fixed soon.


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