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
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?
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 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:
Thank you so much for your reply @cbrandt It makes sense for me now, and it seems to really work! I would have loved if the wordpress plugin and it’s suggested settings set this up automatically
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)
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: example.com/*
I assign Workers script: None (it’s in there, as a “no script assigned”) to routes example.com/wp-login.php* and example.com/wp-admin/* (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.
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, 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 (*.example.com) and only route the worker to the canonical version of your website, either example.com or www.example.com, 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.
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. 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
And I don’t even think that such selling points, are points that would sell any better than a slick design
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?
It makes sense for me now, and it seems to really work! 
I would have loved if the wordpress plugin and it’s suggested settings set this up automatically 
I don’t even know if that’s possible, but hey, we can always dream, can’t we?