CloudFlare CDN HTML cache?

If you are a web developer working with WordPress, you are probably familiar with the benefits of caching. Caching is a process that saves frequently accessible resources such as images on the visitor's computer rather than on the server. This reduces the load and number of requests to the server, which in turn improves performance.

When you have a slow and underperforming site, one of the most adopted standard behaviors is that of Install CloudFlare.

Thus we have the belief and conviction that CloudFlare can cache the html pages of your blog or ecommerce, product pages, posts, category pages as well as static resources such as CSS, JS, and media such as images.

Nothing more wrong instead. For the uninitiated, CloudFlare does NOT cach HTML pages by default and therefore you will have installed CloudFlare but surely you will not have stored the HTML contents of your site in the CloudFlare Cache.

However, there are ways, some almost necessarily using Business plans starting from $ 200 per month to be able to profitably use the CloudFlare HTML Cache in the most real and common cases of using dynamic sites.

Other much cheaper options exist for doing the exact same thing and we would be happy to go through them together if you ask us for advice.

What is CloudFlare?

Cloudflare is a content delivery network (CDN) that speeds up your website by caching to multiple data centers around the world. It can be used to protect your site from DDoS attacks, to block malicious users, and to provide free SSL certificates.

What are the benefits of Cachare HTML with CloudFlare?

Page speed is an incredibly important factor for UX, conversion rates, and SEO. This case study describes in great detail how we used a basic implementation of Cloudflare's HTML caching feature on an ecommerce website to improve average page load times by 28%.

It was used Cloudflare as a CDN server of your website (HTTP proxy server), you need to check if your web page resources (CSS, js, images, Html content) have been cached by Cloudflare or not.

Cloudflare adds a CF-Cache-Status HTTP header with various header values ​​in the HTTP response to tell you whether your request resource has been cached or not. This article will tell you how to check if Cloudflare CDN has cached your website's html content, css, images, js file or not.

1. What kind of resources will Cloudflare automatically cache?

1. If you don't make any special settings, Cloudflare will only cache static website content with the following file extension. Note that Cloudflare will not cache Html files by default if you don't do special configurations.
2. By default, the Cloudflare CDN caches files with the following file extensions: bmp, class, css, csv, doc, docx, ejs, eot, eps, gif, ico, jar, jpeg, jpg, js, mid, midi, otf, pdf, pict, pls, png, ppt, pptx, ps, svg, svgz, swf, tif, tiff, ttf, webp, woff, w0ff2, xls, xlsx.

2. Check the value of Cloudflare's CF-Cache-Status HTTP header.

We can use various web browser inspectors to check this header value. This example will use Google Chrome.

1. Browse your webpage URL (e.g. https://www.code-learner.com/can-not-find-django-tutorial-django-polls-templates-error/) with google chrome.
2. Right-click the web page, click the menu item Inspect in the pop-up menu list to display the inspector.
3. Click on the tab Network in the inspector window, then select the website asset in the left panel.
4. First, let's select the first website resource which is the URL of the web page. Click Headings in the right panel, we cannot find the header CF-Cache-Status  , but we can see a header cf ray , this means that Cloudflare does not cache this web resource (because this file extension is not included in Cloudflare's default list of cacheable file extensions).
5. But you can set the Cloudflare page rules to customize the caching option. We can also know this from the value of another HTTP header, the control of cache in the image below. Its value contains no-cache , which means that the page is not returned from the cache, it is returned from the original web server.
6. But when you click on the second web resource which is a js file, you can find the header value cf-cache-status è MISS . This means the js file is cacheable but not cached in Cloudflare now. Then it will be loaded from the original web server as well.
7. Now let's click on the web resource gallery.min.css? ver = 4.0.0 (the full URL of the resource is https://www.code-learner.com/wp-content/themes/stargazer/library/css/gallery.min .css? ver = 4.0.0), we can find the value of header of this web resource cf-cache-status è HIT . This means that the web resource is cached on the Cloudflare server. The cached version will be returned.

3. Other CF-Cache-Status header values.

1. Besides HIT , MISS and unspecified, the header CF-Cache-Status has other values ​​like EXPIRED, STALE, IGNORED, REVALIDATED, UPDATING . You can go to Cloudflare to find all the explanations on the values ​​of the CF-Cache-Status header .

The problem with CloudFlare that it does not Cacha the HTML and the reduced performance.

Caching HTML can significantly reduce resource usage and provide scalability and performance benefits. Unlike static assets, such as Javascript, CSS, and images, HTML is often customized to the individual viewing it. Therefore, HTML caching, also called full page caching, is not trivial and there are several pitfalls. to avoid.

This article explains how to get the HTML cache with WordPress and Cloudflare.

There are three main components to properly configuring Cloudflare's HTML cache:

1. One way to tell Cloudflare what to cache. For most configurations, this is done by enablingcache everythingin combination withbypass on cookiea 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 the page rules, by setting the cache to bypasso standard.
3. A way to invalidate the cache when the content is updated . This usually makes things difficult and difficult.

The Cloudflare features required for HTML Full Page Cache caching

Below are the features needed to make HTML cache work with Cloudflare.

Page rules

By default, Cloudflare it does not cache HTML. To enable HTML caching you need to use the page rules and, more specifically, the Cache Everything setting. With this, you can enable HTML caching by creating a page rule that caches everything.

However, there is a small problem with this technical approach, the precondition is that all the content that is cached by this page rule must meet two criteria. HTML must be static, which means that it does not change over time (such as the first page of a news story changes continuously).

The other criterion is that the content is anonymous. This means that it is the same content intended for any visitor to this resource, therefore non-personalized pages for logged in users, for example, such as checkout, reserved areas, wishlists and the like.

In summary, this basically means that caching all settings alone is not enough.

Cache everything

The risk of caching everything is always that of being able to cache content that is not intended for the next visitor. For example, if you log into your WordPress admin, it blindly caches everything and visits your first page. A random next visitor would see the page that was meant only for you, with the WordPress edit bar at the top. This is why the Ignore cache setting on cookies is required.

Ignore the cookie cache

To access a website, cookies are required 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 to the origin server, since the user has a certain cookie. With this option enabled, you can provide cached responses to anonymous visitors, while you as an administrator or a customer registered in your WooCommerce are served a bespoke HTML page that will not be cached.

Choose the correct Cloudflare subscription

The essential elements for making the HTML cache work on Cloudflare are the page rules and the Bypass Cache on Cookie setting. This means that if you want to cache HTML on Cloudflare, you are looking the Business plan starting at $ 200 per month, without any add-ons.

Tiered caching structures Cloudflare caches in two tiers in front of your origin (instead of just one), which can significantly reduce worldwide response times, as well as save even more resources on the origin server.

How to configure Cloudflare Business for HTML caching for WordPress

When you plan to take advantage of Cloudflare for HTML caching, we recommend that you reduce the amount of plugins you use for optimization, aggregation, caching and the like on your website.

One reason is that the more plugins and features you use, the more complex it becomes and the harder it becomes to troubleshoot. Another reason is that optimizations are largely done much more efficiently on Cloudflare than using PHP in WordPress. In Cloudflare Business plans you will also have unlimited workers included, which can be leveraged to optimize fonts, resize images and so on.

There is nothing more annoying than trying to debug cache problems on a CDN. For example, a visitor would report an error and when you try to hit another CDN node, the results could be completely different.

Set the page rules

You will need a set of rules in the rules section of the Cloudflare page, instructing Cloudflare how to process various requests. The first page rule that matches the incoming request is the one that will be applied.

The example below is an absolute minimum setup, which does the necessary groundwork to make a standard WordPress function as expected.

Explanation for these rules:

Rule 1 enable Cache Everything for all requests going to anything in the /wp-content/folder, this will include your themes and images.

2 rule Ignore the cache for all requests starting with /wp-(except wp-content, which is handled by the first page rule). This allows you to log in ( /wp-login.php) and work in the administrator ( /wp-admin/*) without running into caching issues. When you log into the Control Panel, you will get the no_cachecookie

Rule 3 apply 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_cachecookies.

It is recommended to add no_cache wp-*|wordpress-*|comment_*| woocommerce_*in the bypass rule.

Additional rules required for WooCommerce or other dynamic endpoints on your site

If you're running WooCommerce, there are a couple of other endpoints that need to be excluded from caching. The cart and checkout are dynamic by design and cannot be cached. Routes may vary, so you need to check which routes 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):

Checkout often involves multiple steps, so the /checkout/*wildcard rule is used to bypass the cache. And this example has the shopping cart page up /cart.

Further customization of the page rules

All sites are different, and there are usually certain paths and requests that you would like to exclude from caching. Both plugins and themes sometimes require customization. Also, API requests are generally not something you would like to cache.

Often you will also want to apply caching policies that are efficient for your site. There are no general rules, but online testing tools always complain about setting cache expiration dates very far away.

The Expire Cache TTL is a setting that tells Cloudflare how long they should keep an asset in their cache. For example, for static content, it's often a good idea to set it to the maximum setting (one month). For HTML you may want shorter times depending on your use case. Ask yourself the question, when and how often you want this HTML to be updated. A good thing about Edge Cache is that we can check it and delete items from it when required. This can be done either via the control panel, or by using for example Servebolt Optimizer, which will automatically update relevant content.

We can also check the TTL of the cache of the browser using page rules. Browser Cache is special, because we can't control it like Edge Cache. It cannot be deleted by clicking a button. The only way to get around the browser cache is to force a page to reload (which will cause the page to reload from the server to the browser) or to let it expire. The advantage of the browser cache is that it is the closest cache to the users, so it will make the HTML load in fractions of a second because it does not require any network traffic.

There is also a cache control source setting that allows you to control the CDN cache from the source web server. This is a very cool feature for advanced users, who know how to manipulate headers and train Edge cache using headers.

Cloudflare's “Bypass Cache on Cookie” and “Edge Cache TTL” functionality

There are several ways to approach the problems described above, but in this case we needed a simple solution that didn't require too many development resources.

Hamlet Batista in  this awesome article on HTML caching for ecommerce websites , suggests that a solution for dynamic content elements such as a logged in user's name would be to add this information to the page via JavaScript, rather than including it in the original HTML. In this way, HTML files without dynamic elements that work for all users could be cached and dynamic elements could be added individually for each user on the client side. Our problem with this approach, while it sounds like a great solution, is that it would require a significant change in how some store elements are programmed.

An alternative suggested by Hamlet is to enable HTML caching only for users who are not logged in. If we apply this idea to our case, with dynamic content elements for logged in users and for users who have added products to their shopping carts, this would mean that we would have to find a way to activate the HTML cache just to users who are not signed in and who have not added anything to their shopping carts.

Cloudflare offers a solution for caching HTML pages only for certain users , called “Bypass Cache on Cookie” (available to users of the Business and Enterprise plan ). The only additional element you need on your website to use this feature is a cookie that is set whenever you want to exclude a user from HTML caching. In our case, we needed a cookie that was set every time a user added a product to the cart or logged in and that was deleted every time the cart was empty or the user logged out.

Depending on the CMS or eCommerce system you are using, there are several ways to set cookies: you may even get lucky and the cookies you need already exist. If you don't know how to set the cookies necessary to implement HTML caching on your website, for example cone with Google Tag Manager

TTL Edge Cache Cloudflare is a feature that allows us to set a time interval after which the cache is emptied and Cloudflare fetches a new version of the page from the origin server the next time the page is requested by a user. We decided to use this feature to expire Cloudflare's cache as often as prices are updated on the website, every 30 minutes.

The use of the "Bypass Cache on Cookie" features (to exclude logged in users and users who have products in the cart from HTML caching) and "Edge Cache TTL" (to expire the cache after a certain time frame).

How to clear the Cloudflare cache

Let's start with how to avoid deleting the cache, if you want to always maintain the best possible performance.

The button Delete everything it's very comfortable, but on the other hand it's a performance killer. The button is very efficient and does exactly what it says: it deletes every cached item for the entire zone (domain) on every CDN node in the Cloudflare network. This means that all CDN nodes must rebuild the cache by fetching all resources from the source again. This is time consuming and reduces performance for the end user.

Therefore, the best option is to use the custom deletion , if possible. This feature only invalidates specific paths, instead of also invalidating all your static elements and all other HTML pages.

Automatically delete via plugins.

Some plugins are able to do this by hooking on to actions that are performed every time you update a post, page, product or any other type of post. We do the same thing when you update taxonomy terms such as categories, product categories, tags, etc.

The real magic is that in addition to deleting the post itself, we also delete the terms it belongs to. This way you can make sure that, for example, the product category page is up to date if you update the price of a product in that category.

How to replace CloudFlare with an alternative to do HTML Caching?

As we just saw CloudFlare caches static content like images and CSS files, but not HTML pages. Varnish can cache both. This means that if you are using CloudFlare as a CDN, you will still need Varnish for optimal performance.

Cloudflare is a global content delivery network (CDN). It's not quite the same as a caching service like Varnish.

Trying to use Cloudflare for caching can cause problems because it doesn't cache HTML pages.

Varnish on the other hand is a caching service. It caches HTML pages and doesn't put them back into cache unless you tell them to.

Cloudflare can help speed up your website, but only if you have a lot of traffic. If you don't have enough traffic, Cloudflare reduces the performance of your website, because it will have to make more requests to your server to get the content.

Varnish is a caching web proxy. It sits in front of your server and any web traffic can be cached so the user doesn't have to wait for it to arrive from the application server. Varnish is known to be faster than other caching solutions, because it is closer to the end user and has lower latency.

The difference between Varnish and Cloudflare is that Cloudflare does not cache HTML pages. This is why Varnish might be the best replacement for Cloudflare.