This article explains how to make HTML caching work with WordPress and Cloudflare.
The required Cloudflare Features for HTML full page caching
By default, Cloudflare is not caching HTML. To enable caching of HTML you need to use Page Rules, and more specifically the Cache Everything setting. With this, you can enable caching of HTML by making a page rule that caches everything.
There’s a slight problem with that though, the precondition is that all content that is cached by this page rule has to fulfill two criteria. The HTML has to be static, meaning that it does not change over time (like a news front page for example is continuously changing). The other criteria is that the content is anonymous. This means that it is the same piece of content that is intended for any visitor to this resource. In sum, this basically means that the cache everything settings alone is not enough.
The risk of caching everything is always that you might cache content that is not intended for the next visitor. For example, if you log into your WordPress admin, cache everything blindly and visit your front page. A next random visitor would get to see the page that only was intended for you, with the WordPress edit bar at the top. That’s why you need the Bypass Cache on Cookie setting.
Bypass Cache on Cookie
To log in to a website, cookies are needed to maintain a link between your computer and the server. When you have this cookie, it is sent with every request you make to the server. This means that you can tell the server to pass the request through to the origin server, given the user has a certain cookie. With this enabled, you can deliver cached responses to Anonymous visitors, while you as an Administrator, or a logged in customer in your WooCommerce, is getting served a tailored HTML page that will not be cached.
The Servebolt Optimizer plugin takes control over what to cache and what not to cache, and provides a cookie named no_cache if content should not be cached. If you are using this plugin, this simplifies your setup and you can rely on this one instead of all the various cookies WP (
woocommerce_* ). The other benefit is that the
no_cache cookie also works with the upstream Servebolt origin webserver.
Choosing the correct Cloudflare subscription
The essentials to make HTML caching work on Cloudflare are Page Rules and the Bypass Cache on Cookie setting. This means that if you want HTML caching on Cloudflare, you are looking at the Business plan starting at $200 per month, without any addons.
Servebolt is an Enterprise Cloudflare partner and provides custom Cloudflare Business plans. The Servebolt business plans by default include a feature called Tiered Caching. This is normally a paid addon in the Argo Routing application, and is an essential performance enhancing feature if you are serving the US or other large geographic regions.
Tiered caching structures the Cloudflare caches in two layers in front of your origin (instead of just one), which can significantly reduce the response time across the world – in addition to saving even more resources on the origin server.
Ready to see how fast your site can be?
How to configure Cloudflare Business for HTML caching for WordPress
When you are planning to leverage Cloudflare for the HTML caching, we recommend that you reduce the amount of plugins you use for optimization, aggregation, caching and such on your website.
One reason for this is that the more plugins and features you use, the more complex it gets – and the harder it gets to resolve issues. Another reason is that optimizations are largely done much more efficiently on the Cloudflare edge than by using PHP in WordPress. On the Servebolt Cloudflare Business plans you’ll also get Unlimited workers included, which can be leveraged to optimize fonts, resize images and so forth.
There’s nothing more annoying than trying to debug cache issues on a CDN. A visitor would report some error, and when you test this hitting another CDN node – the results could be entirely different.
Setting up the Page Rules
You’ll need a set of rules in the page rules section of Cloudflare, that tell Cloudflare how to process various requests. The first page rule that matches the incoming request is the one that will be applied.
The following example is an absolute minimum configuration, that does the required basics to make a standard WordPress function like intended.
Explanation for these rules:
Rule 1 enables Cache Everything for all requests going to anything in the
/wp-content/ folder, this will include your themes and images.
Rule 2 Bypasses the cache for all requests starting with
wp-content, which is dealt with by the first page rule). This makes it possible for you to log in (
/wp-login.php), and work in the admin (
/wp-admin/*) without running into caching issues. When you log in to the Control Panel, you will get the
Rule 3 applies the default policy for the rest of the requests. This is the rule that enables HTML caching for everything, with the exception of bypassing the cache if you have the
If you’re not using Servebolt Optimizer, it is recommended to replace
wp-*|wordpress-*|comment_*| woocommerce_* in the bypass rule.
Additional required rules for WooCommerce, or other dynamic endpoints on your site
If you’re running WooCommerce, there are a couple of more endpoints that need to be excluded from caching. The cart and checkout are by design dynamic, and can not be cached. The paths may vary, so you need to check what paths are in use for your cart and checkout.
The following is a standard example where we have added two more page rules (the first two):
The checkout often involves multiple steps, therefore the
/checkout/* wildcard rule is used to bypass the cache. And this example has the cart page on
Further Customization of Page Rules
All sites are different, and there are usually certain paths and requests you’d like to exclude from caching. Both plugins and themes sometimes require customization. Also, API requests are generally not something you’d like to cache.
You’d also often want to apply cache policies that are efficient for your site. There are no general rules, but online testing tools always nag about setting very far future cache expiry dates.
The Edge Cache TTL is a setting that tells Cloudflare how long they should keep an asset in their cache. For example for static content, it is often a good idea to set this to the maximum setting (a month). For HTML you might want shorter times depending on your use case. Ask yourself the question, when and how often do you want this HTML to be refreshed. A good thing about the Edge Cache is that we can control it, and purge items from it when required. This can be done either through the control panel, or by using for example Servebolt Optimizer, that will automatically refresh relevant content.
We can also control the Browser Cache TTL using page rules. The Browser Cache is special, because we can not control it like the Edge Cache. It cannot be cleared by clicking a button. The only ways to bypass the browser cache is to force-reload a page (which will make the browser re-load the page from the server), or let it expire. The upside of the browser cache, is that it is the cache closest to the users – so it will make HTML load in just fractions of a second because it doesn’t require any network traffic.
There is also an Origin Cache Control setting that allows you to control the CDN cache from the origin webserver. This is a very nice feature for advanced users, that know how to manipulate headers and instruct the Edge cache using headers.
How to purge the Cloudflare cache
Let’s start with how you should avoid to purge the cache, if you want to maintain best possible performance at all times.
The Purge Everything button is very convenient, but on the other hand it is a performance killer. The button is very efficient, and does exactly what it says: it purges every cached item for your entire zone (domain) on every CDN node in the Cloudflare network. That means, that all CDN nodes need to rebuild the cache by fetching all assets again from the origin. That takes time, and degrades performance for the end user.
Therefore the better option is to use the Custom Purge feature, if possible. This feature only invalidates the specific paths, instead of also invalidating all your static elements and all other HTML pages.
If you’re using the Servebolt Optimizer plugin, smart purging is automatically done by the plugin.
How to verify that HTML caching is working
We’ve written a separate article about Servebolt’s Caching and Cache policies that help you verify whether HTML caching is working.
Give us your feedback on this article
Did this help you?
We have launched in the UK! 🇬🇧
Servebolt Cloud UK is now available to all clients. Our London data center will ensure that all clients with their majority of visitors in the UK experience extremely fast websites!