Guide to HTML Full Page Caching with Cloudflare for WordPress

Caching of HTML can significantly reduce resource usage, and provide scaling and performance benefits. As opposed to static resources, like Javascript, CSS and images – HTML if often tailored to the individual that views it. Therefore HTML caching, also called full page caching, is not trivial and there are several pitfalls to avoid.

This article explains how to make HTML caching work with WordPress and Cloudflare.

There are three main components in a successful Cloudflare HTML cache setup:

  1. A way to tell Cloudflare what to cache. For most setups this is done by enabling cache everything in combination with bypass on cookie in a page rule that matches every page on your site.
  2. A way to exclude pages that should never be cached. This is also done via page rules, by setting cache to bypass or standard.
  3. A way to invalidate cache when content is updated. This is usually when things become tricky and hard, but our plugin Servebolt Optimizer takes care of this for both WordPress and WooCommerce.

The required Cloudflare Features for HTML full page caching

The following are the features you need to have to make HTML caching work with Cloudflare.

Page Rules

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.

Cache Everything

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.

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 (wp-*, wordpress-*, comment_*, 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 to cache HTML 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.

Basic Cloudflare Page Rules for HTML Caching

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- (except 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 no_cache cookie

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 no_cache cookie.

If you’re not using Servebolt Optimizer, it is recommended to replace no_cache with 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):

Cloudflare ruleset for HTML Caching for WooCommerce

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 /cart.

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.

Cloudflare Dashboard – Cache App, Purge Cache section

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.

Automagically purge via the Servebolt Optimizer plugin

The Servebolt Optimizer plugin supports purging the Cloudflare cache automatically when content is updated. The plugin is able to do this by hooking into the actions that run every time you update a post, page, product or any other post type. We do the same thing when you update taxonomy terms like categories, product categories, tags etc.

The real magic in Servebolt Optimizer is that we in addition to purging the post itself also purge the term(s) it belongs to. That way you can make sure that i.e the product category page is updated if you update the price on a product in that category.

The setup of Servebolt Optimizer for WordPress and the Cloudflare Cache Purge feature is really simple, and can be done via wp-admin or by using the really simple WP-CLI commands that comes with the plugin. The Servebolt Optimizer also allows for customization through filters and actions if you have a site specific need that the plugin does not automatically handle.

If you need to purge manually this is also possible through both WP-CLI and the admin bar when the integration with Cloudflare is set up.

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