Recommended CloudFlare Page Rules for WordPress Sites

caching

#1

Hello,

I want to enable ‘cache everything’ while treating admin and logged in users differently. On this community page, I found a method. Could you please advise whether this approach is recommended for free plan users on WordPress sites?

mydomain.tld/wp-admin
Cache Level - Bypass

mydomain.tld/*?*loggedin=true
Cache Level - Bypass

mydomain.tld/*
Cache Level - Cache Everything

Kind regards,


#2

Nope. That URL format just isn’t there. That post says you’d have to re-code the site to add the “logged-in” part.

One caching strategy that really helps me in this situation is just to cache everything for wp-content* and wp-includes* and set a really high Browser expiration time and a long Edge Cache TTL.

That covers most of your content, yet maintains the dynamic portions of your site. Just about all that would be left is the pure HTML portion, which should be pretty quick to deliver from your server for all visitors. A local caching plugin should handle the rest. Set that plugin to not cache for logged in users.


#3

Thank you for your response and the direction.

I am really a novice and, though I understand your idea, may I request for specific urls and order for these rules - wp-content and wp-includes?

Kind regards

PS: That link I shared from another post provided the rules I mentioned above. Screenshot for quick reference.


#4
  1. Go to Page Rules
  2. Create a new rule that matches example.com/wp-content/* and add a setting to Cache Level to Everything and another setting for Edge Cache TTL to 1 week (or more), and another setting for Browser Cache to a week or so.
  3. Create another new rule that matches example.com/wp-includes/* with the same settings as above.

Order doesn’t matter if those are your only two rules.


#5

Thank you very much for the guidance. In addition to these two rules, I realize there’s a folder (under /wp-content/) that I do not want to cache. I have built the exception as:

1. *.example.com/wp-content/exception/* 
    Cache Level: Bypass
2. *.example.com/wp-includes/*
    Cache Level: Cache Everything, Edge Cache TTL: 1 week, Browser Cache: 1 week
3.  *.example.com/wp-content/* 
    Cache Level: Cache Everything, Edge Cache TTL: 1 week, Browser Cache: 1 week

In addition, as you recommended, the site uses cache plugin for everything else.

Does this look okay or do you see any problem/s with this approach?

PS: Even after these page rules, I do not notice a perceptible change in speed with tools such as gtmetrix or pingdom. Wonder why.

Kind regards,


#6

Remove the first period in your rules so it’s *example.com…blahblah.

Once it’s all set up, those test tools have a waterfall view or full list of everything that loads, often with a little “open” triangle to show you the full details for that object. You should see a header that says something like cf-cache-status of HIT/MISS/EXPIRE/etc.

Cloudflare cache can take a few visits to populate before getting a HIT status.


#7

Thank you again for your helpful response. I have revised the rules to remove the dots in them.

For some reason, the test results differ. On gtmetrix and pingdom, I see the protocol as http/1.1 while on webpagetest, it says http/2. Besides, none of the headers show cf-cache-status header response.

PS: my site is at Backpacking Series | Home Page

All suggestions are welcome.

Kind regards,


#8

From my Chrome Dev Tools, I’m seeing EXPIRED for the cf-cache-status for files in wp-content and wp-includes. Load time was about ten seconds for my first visit. Second visit was 2.6 seconds. The ?custom-css call is really slowing things down. See if there’s a way to turn that off because it’s not cached, and CSS shouldn’t be dynamic.


#9

Thank you @sdayman

That was an excellent recommendation! I deactivated Jetpack’s Custom CSS module and enabled http keep-alive (to reduce the number of requests) and found a noticeable improvement on pingdom.

PS: I am unable to locate cf-cache-status that you mention.

Kind regards


#10

If you look at a speed test, scroll down then open up a request for one of your CSS files, you’ll see the cache status in the Response Headers section:


#11

Thank you @sdayman Found it as a HIT! :slight_smile:


#12

This topic was automatically closed after 14 days. New replies are no longer allowed.