Kitt Cache Crawler Blog

In a previous post, we analyzed the question of whether it is possible to warm up the CDN cache of Cloudflare and Quic.cloud. Regardless of the challenges and the specifics of warming up the cache of a Content Delivery Network, the CDN cache warmup behaves fundamentally the same as any other cache warmup. In any case, it always requires an HTTP request, regardless of how the request is executed, as long as it uses the GET method. However, the effort required for CDN cache warmup is considerably higher, and would generally exclude the possibility of performing a cache warmup. After many tests, we have found a way to drastically reduce the effort, especially the time required, for this task. With a special version of the Kitt Cache Crawler, we are working on a cache warmer for Cloudflare.

The LiteSpeed Web Server (LSWS/OLS) is renowned for its award-winning performance and outstanding LScache engine. However, what many users don't know —largely due to LiteSpeed’s failure to highlight it— is a special speed feature that is particularly noticeable with WordPress. Typically, this feature requires no configuration because it is a standard function of the LScache engine. However, to make use of it, you need to use a caching plugin for WordPress, for example. If you use Cloudflare, quic.cloud, or another CDN without CDN caching, this speed feature will be disabled by the CDN provider. In this post, we will clarify what this feature is and explain how to reactivate it.

As part of a proof of concept, we tested the cache warmup options of CDN nodes in an extensive test procedure. Although Cloudflare provides over 1.5 million IP addresses, only a fraction of these IP addresses are actually used to cache the content of a page for a CDN. At quic.cloud, it is less than 0.1%, which primarily speaks in favor of CloudFlare. Not only an active cache on a CDN node, but also already cached content is crucial to benefit from the advantages of a CDN. Find out in this post what the goal of this proof of concept was and whether you can achieve real advantages by using a CDN.

Increasingly, it is being observed that many users of the LiteSpeed Cache plugin for WordPress are also using Cloudflare APO, despite clear warnings from LiteSpeed Cache about potential conflicts. This warning is not arbitrary and does not aim to block competing cache plugins. But what are the actual reasons for these conflicts? This post will address these questions and more.

Can the cache of quic.cloud or CloudFlare CDN Nodes be warmed up? Yes, this is technically possible, but is warming up the cache of a CDN node also meaningful? In this post, we'll explore whether it's feasible to warm up the cache for quic.cloud, CloudFlare, Hostinger, or Bunny CDN nodes, and whether the effort is worth it.

In this post, we analyze the LiteSpeed Guestmode, a feature of the LiteSpeed Cache Plugin for WordPress that promises high PageSpeed scores. After reading this analysis, you will understand why the LiteSpeed Guestmode doesn’t provide the expected benefits and why it actually cannot improve the PageSpeed score.

In the realm of web performance optimization, caching plugins like LiteSpeed Cache are indispensable tools. They enhance website loading times and reduce server load. But what happens when such technology harbors a serious security vulnerability? This post sheds light on a critical flaw in the LiteSpeed Cache Plugin for WordPress that, if exploited, could potentially lead to attacks on external hosts.

In this post you will learn how you can further improve the LiteSpeed LScache plugin for WordPress by using avif images instead of webp images and converting them on your own server. With the avif format, the file size is reduced by a further 50% compared to webp images, without affecting the image quality. This post also describes how you can become independent of quic.cloud and thus free yourself from known limitations of quic.cloud.

If the LiteSpeed Cache Plugin displays a warning that the built-in crawler is not enabled in the server settings, then this is not strictly speaking a deactivation. In the event of deactivation, the server only responds with a specific HTTP status code when the cache plugin sends a specific request to the server. This means the deactivation therefore does not take place on the server, but in the LiteSpeed Cache Plugin. It is therefore comparatively easy to modify this request only slightly in order to cancel the deactivation.