Folks often come to Cloudflare’s Community forum to ask for the best page rules to optimize their WordPress website. This post will discuss how to cache the HTML generated by WordPress at Cloudflare with only two page rules. Caching the HTML results in a significant speed improvement, but should be used only for sites that are informational in nature, and do not require user interaction.
- What Are Page Rules?
- Static WordPress Sites
- Matching Domain and Subdomains
- First Page Rule
- Second Page Rule
What are Page Rules?
Cloudflare page rules in most cases allow you to create exceptions to the configurations you set elsewhere on the Cloudflare dashboard. For instance, you may have the security level set to medium at the dashboard’s Firewall app. That will apply to the whole zone, which means any URL at your domain and its subdomains.
With a page rule, you can set a different security level to apply only to parts of your zone, like a subdomain, a subdiredory or a group or URLs following a wildcard pattern. For instance, you could set security level to high for your back end by creating a page rule with the setting for the URL pattern /wp-admin/*.
For any given request, Cloudflare will only process one page rule. That means order is important. The rules containing the most specific URL patterns should normally come first, and the most generic ones, last.
In our specific case, we want to have a rule at the top for the back end, and a second rule (and perhaps a third) for the front end of your site.
Static WordPress Site
If you have an WordPress website that is informational in nature, without user interaction (no comments, and no e-commerce), you can set two or three page rules to enable “cache everything” on your front end.
Cache everything is a setting that will make Cloudflare cache the HTML generated by your WordPress site. By default, Cloudflare does not cache HTML, and that means every visit to your website will be a visit to your origin server. With a page rule with cache level set to cache everything, Cloudflare will cache the HTML for the URLs that match the pattern you defined at the page rule.
Matching Domain and Subdomains
If you are new to page rules, you should become familiarized with how the wildcard can be used to match the domain or subdomain part or your site URLs, as well as their path. If you already know how to create page rules and just want to check the proposed page rules for WordPress, you should skip to First Page Rule or Two Page Rules Solution below.
Matching the Domain
Because we want to cache the HTML for all of your front end, we will set this pattern as
example.com/*
If the canonical version you set for your domain includes the www., you would have instead
www.example.com/*
Any of these two patterns will include all requests for URLs matching the given domain name, but will not include URLs for any subdomains.
Matching Subdomains
If you have more than one installation of WordPress, each using a separate subdomain, you can change the pattern to:
*example.com/*
In the above example, the page rule will apply to all URLs in any of subdomains of example.com, as well as the root domain.
If you prefer to exclude the root domain, but include any subdomains, you should use instead:
*.example.com/*
First Page Rule
Matching the Front End
Whatever choice of domain/subdomain matching pattern you chose, the /* part of the page rule means it will match all URLs under the matching domain, both the front and back end of your site, except for the URLs that match another page rule. We will create below a page rule for the back end, so here we should add settings that are relevant to the front end of your site.
The front-end page rule at oba!press have the following settings:
Always Online: On Cache Level: Cache Everything Edge Cache TTL: a month Browser Cache TTL: a day
The page rule looks like this on the editing screen at Cloudflare:
Settings Explained
Always Online: On
The Always Online setting is optional. This is normally set at the dashboard, to apply to the whole zone. But every now and then we may need to debug an issue somewhere on the site, like a test.example.com subdomain, and having this setting here means we can turn it off on the zone level but still count on the Always Online feature for our main, front end pages.
Cache Level: Cache Everything
This is the most important setting for our use case. Cloudflare by default does not cache HTML pages. We want Cloudflare to cache the HTML pages generated by WordPress, so that our origin server doesn’t need to regenerate it every time a visitor comes by.
Edge Cache TTL: a month
WordPress will send a header instructing browsers and proxies like Cloudflare not to cache the HTML. That would essentially turn the previous setting off. To override the Cache Control header set by WordPress, you can use the setting Edge Cache TTL. For the purpose of the Cache Everything setting, any value can be used here. But since we can purge Cloudflare’s cache of our site at any time, we want this to be the highest value possible, which is a month for the Free Plan. Also, Cloudflare recommends that you set the Edge Cache TTL on a Cache Everything page rule for at least the minimum interval its crawlers visit your site for the Always Online feature to work properly. That means 14 days on the Free Plan, 7 days on the Pro Plan, and 2 days on either a Business or Enterprise Plan.
Browser Cache TTL: a day
This optional setting will instruct browsers to cache the HTML for a day. Since we cannot purge the HTML cached by browsers, you should not set this to a very high amount of time. We use a day here, but you need to adjust depending on how often you make changes to your website content. As for other files on your WordPress site, don’t worry. Cloudflare will pass to the browser the higher between what your origin sets and the Browser Cache TTL setting. So if your .htaccess file or WordPress configuration sets a cache period of 1 year for JavaScript files, for instance, this higher value will be passed on to browsers instead of the one day value in this setting.
Other Settings
Optionally, you may want to try and use different settings within this page rule. Since the page rule is meant for the front end, make sure the settings you apply will be both necessary and useful. Most settings that can be set at the dashboard level should be set there instead.
Second Page Rule
A Rule for the Back End
To avoid caching the HTML of pages on your WordPress back end, typically the pages that start with /wp-admin/, you need to set a separate page rule. Assuming for instance that you decided to use *example.com to match both your root domain and all your subdomains, you could create the second page rule as follows:
*example.com/wp-admin*
However, the solution above only include URLs at the /wp-admin/ level. But there are WordPress pages that should not be cached that are not located under /wp-admin/, such as the /wp-login.php page.
What we use instead is the following pattern:
*example.com/wp-*
This includes not only /wp-admin/, but also /wp-login.php and /wp-content/, where plugins may have some files that need to be accessed but not cached, such as json files.
With /wp-* we match all the above-mentioned URL paths. Since this pattern includes the /wp-content/ path, where image and other static files are located, we should not include in the page rule any cache level setting, and let Cloudflare cache these URLs according to its default caching.
This way, images, CSS and JavaScript files at /wp-content/ will be cached by default, while the HTML of internal, back end pages at /wp-admin/, as well as the HTML of /wp-login.php and other non-static content will not be cached by Cloudflare.
Though we refer to this page rule as “second” in this post, it should be set as the first in terms of the order among your page rules, so that it triggers whenever a page under /wp-* is requested, and the more generic, front-end page rule for /*, does not apply.
At oba!press, we use the following settings for our back-end page rule:
Rocket Loader: Off Always Online: Off Security Level: High Disable Apps
This page rule looks like this on the Cloudflare Page Rule editing screen:
Settings Explained
Rocket Loader: Off
Rocket Loader optimizes the delivery of your site’s JavaScript files. It may interfere with some plugins, especially page builders. So we turn if off on the back end of our WordPress sites.
Always Online: Off
If your server is for some reason unavailable, it makes no sense seeing an Always Online version of your WordPress back end.
Security Level: High
If you set the security level of your zone to medium or low, you may want to set it as high for the back end, as that’s the part of your site that’s most targeted by bots will bad intentions.
Disable Apps
If you use now or intend to use in the future any of many apps available on Cloudflare, you should disable them for the back end, as they may be a distraction on your editing screens, and may also conflict with some plugins and page builders.
Cache Level
Notice that we do not use the Cache Level: Bypass setting. This is simply not needed. Cloudflare by default does not cache HTML. Since only one page rule triggers for any given URL, and this page rule will be the only rule triggered for the back-end URLs, they should never trigger the “cache everything” page rule. Therefore, setting a cache level here is unnecessary.
Also, as explained above, our back-end pattern matches other WordPress specific files that should not be cached, without compromising the caching of static assets, such as images, and CSS and JavaScript files.
Third Page Rule
In a Cloudflare Free Plan, you are allowed only 3 page rules, with the option to buy more if needed. The two page rules above cover respectively the front end of your site and the URLs beginning with /wp-*.
You can then use the third page rule available on the Cloudflare Free Plan for special, temporary needs, such as bypassing the cache on preview pages created by WordPress when editing a page or post. You could use the following pattern:
*example.com/*?preview=true*
Another use for the third page rule is to redirect to the canonical version of your site. So if you decided the canonical URL of your site should start with www., you could create a page rule to redirect any requests for the root domain (without www. and without any other subdomain):
example.com/*
With the setting:
Forwarding URL 301 - Permanent Redirect www.example.com/$1
Or the other way around, from www.example.com to naked domain:
www.example.com/*
With the setting:
Forwarding URL 301 - Permanent Redirect example.com/$1
Comments
Please send any comments as replies to the tweet below. Click on the date of the tweet to open it on Twitter.