Cache everything on wp-content and combining rules

I’m on the free plan and want to put a rule in for cache everything on just wp-content/*
like so:
website.com/wp-content/*
Settings: Cache Level (Cache Everything), Edge Cache TTL (7 Days), Browser Cache TTL (1 day)

I already have 3 rules:

1 to do a 301 from www.website.com to https://website.com/$1

2 to website.com/wp-login.php
security high, Cache Level: Bypass, Disable Performance

3 to website.com/wp-admin/
Security high, Cache Level: Bypass, Disable performance

Would cache everything on the wp-content* cause non logged in users to see pages they should see like I have read with the cache everything rule for the entire site?

Am I able to combine the last two rules so I can free up the 3rd rule for cache everything on the wp-content? Thanks

There are a bunch of posts for Cache Everything with WordPress. @floripare (and maybe @saul) have posted some pretty good advice on this setup.

https://community.cloudflare.com/search?q=wordpress%20cache%20everything

1 Like

May I ask, what resources are being served from /wp-content/? Isn’t it mostly static assets (images, css, js etc)? I don’t believe you have any HTML pages served from within this directory, in which case Cloudflare should already be caching these assets without the need to setup any “cache everything” page rule.

Just to comment, what would be the point of setting “edge cache” to 7 days and “browser cache” to 1 day? If browser cache expires, it means they will just fetch an identical copy from edge cache anyway. Edge cache and browser cache should be the same. The exception being if you are caching HTML pages, in which case you might want a LOW (or 0) browser cache, and a high edge cache, so that you can manually purge html documents when your website changes.

Another thing to note, is that if your web server is setup correctly (following standards), you will already have “cache-control” headers in all your static assets, which instructs Cloudflare to cache the resource for 1+ year on CDN, and also instructs browsers how long to cache the resource. HTML/PHP documents will normally have cache-control headers to set 0, because they should not be cached.

No, because the caching will only apply for resources served from /wp-content/. It won’t affect root, wp-login or wp-admin. Those urls may still cache static assets, but pages will not get cached. Just make sure the 301 rule comes first.

First of all, if a non-logged in user attempts to access /wp-admin/, won’t it automatically redirect to wp-login.php? In which case, it seems pointless to have a specific rule for /wp-admin/. Also, why set “Cache Level: Bypass”? By default, Cloudflare caches STATIC assets (css, js, images), something which is also beneficial for login-areas, and will NOT affect the page output itself, which is served from your server. Finally, why not use Cloudflare “Access” to entirely block access to your wp-login.php, instead of using a page-rule? That essentially means that only you will be able to access that URL.

It’s important to note that Cloudflare already caches all static assets by default, but not html documents (which may contain dynamic data for example from from logins). Therefore, default caching without page rules already does the job, without having to worry about breaking wp-admin. If you indeed want to also achieve html/page caching (which is possible), a better approach might be to just create a rule “cache everything” + “edge cache ttl” for the entire website, and then have rules for “Cache Level: Standard” for /wp-login and /wp-admin … although I see in your case that might require 4 rules.

1 Like

I got this rule from a post you replied to:

website.com/wp-content/*
Settings: Cache Level (Cache Everything), Edge Cache TTL (7 Days), Browser Cache TTL (1 day)

Because caching wp-admin causes wordpress console problems.

So it doesn’t dump the less accessed assets from cloudflare on a daily basis. I don’t want the html cached just the others in wp-content.

No logical reason why caching static assets in wp-admin would cause any issues. I have two WP websites myself setup like this. It could be other Cloudflare-related features like firewall or rocket loader.

No point in dumping browser cache on a daily basis, if it simply causes new requests to identical copies of the cache from the CDN, not served from origin.

With the rule combo you speak of, it WILL cache the HTML anyway.

Ok now I understand what you are saying about wp-admin. The issue I originally had with it is the wordpress dashboard not being accessible with cloudflare turned on. That is why I put that rule for wp-admin. However, it was really the “disable performance” I was using in that rule.

Are you saying you really don’t need that rule for wordpress dashboard to work correctly?

If I put this rule in for wp-content will it cache those assets longer and not dump them on a regular basis causing cache misses?

[website.com/wp-content/* ]
Settings: Cache Level (Cache Everything)

The wp-admin will work with default Cloudflare settings, so it depends on your settings, and if you have any page-rules that affect the wp-admin. In your case, I think not. The only thing you need to AVOID with the wp-admin is caching pages, because wp-admin needs to serve user-specific dynamic pages (from PHP). By default, Cloudflare will not cache html pages. The only way this could go wrong, is if you have a page-rule that includes wp-admin, set to “cache everything” + “edge cache TTL”. Also, you might need to make sure to NOT enable “Rocket Loader”, as I have seen this break wp-admin Javascript functionality.

So yes, unless you have some other page-rules or settings breaking wp-admin, you should not need to set any rules for wp-admin. Default Cloudflare functionality will work, including “standard cache” which caches static files (js, css etc) on Cloudflare.

This question is a bit unclear. First of all, it’s easy to misinterpret the “cache everything” page rule. Standard Cloudflare caching (without “cache everything” page rule), will already cache most assets (images, css, js). With “cache everything” page rule, you are instructing Cloudflare to also cache HTML (pages) output. However, even with this rule enabled, unless you have an “Edge cache TTL” rule or “cache-control” headers (from your origin), html documents will not cache anyway. Likely this rule alone does little or nothing.

In regards to your /wp-content/ directory, that should only be static assets, which Cloudflare will already cache. Setting “Cache everything” rule here will have no effect, and no it will not prevent Cloudflare from dumping them on a regular basis. Unlike other CDN services, Cloudflare decides to keep an item cached or not based on some internal mechanism. When you set edge-cache TTL or user cache-control headers, you are only instructing Cloudflare the maximum storage time.

For Wordpress, default Cloudflare settings are normally sufficient, and page-rules should not provide any advantage to Cloudflare caching. Cloudflare will cache static assets, and provide some basic protection to your website.

The exception is if you want to achieve page-caching in Wordpress, which can improve html loading times drastically, since WP is relatively slow to output pages. It’s dodgy business caching html pages, and you would need to create page-rules to bypass this in wp-admin/wp-login, and then have a rule to “cache everything” + either “edge cache TTL” or set cache-control headers from your server. Then you would also have to deal with the fact that Cloudflare is caching your pages, so any changes you make to the website are not immediately reflected, until you “purge cache” from Cloudflare dashboard.

To conclude, unless you want to use page-caching, there is not much you can do in terms of Cloudflare page-rules to speed up your website any more than it is with default Cloudflare settings. Many things you could do from your WP website of course, like use a caching plugin and serve public css/js scripts from a public CDN like cdnjs.com or jsdelivr.com.

Thank you for the detailed explanation.

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