Cloudflare, quic.cloud and All Other CDNs Kill LiteSpeed Speed Feature

Start » Blog » CDNs Kill LiteSpeed Speed Feature

Restore LiteSpeed's Speed Feature

The LiteSpeed Web Server (LSWS/OLS) is renowned for its award-winning performance and outstanding LScache engine. However, what many users don't knowv —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.

Extra Speed Without Extra Configuration

When it comes to page caching like LiteSpeed LScache, the main goal is to cache the main document, i.e., the dynamically generated source. The main document is the core element of every page request. It is generated dynamically on each request for a URL and contains all the dynamically generated data for that specific request. While the main document is responsible for rendering the webpage, it doesn't contain any data for displaying the content. LiteSpeed LScache and other page caches therefore only cache the dynamic part of a request, not static assets like stylesheets, JavaScript, or images. Static assets are cached by the browser and thus are not affected by the page cache, although the caching behavior of static assets can be controlled through server settings.

Understanding caching

When it comes to caching an HTTP request, there is a distinction between server-side caching and browser caching. Dynamic assets, like the main document, are generally excluded from browser caching. Allowing the main document to be cached by the browser would risk ensuring that updated data might not be displayed correctly because the data would be fetched from the browser cache instead of the server. Static assets like stylesheets, JavaScript, and images, however, should definitely be cached by the browser since they rarely change. Otherwise, the browser would have to reload these assets on every page request, even though they haven't changed, wasting bandwidth and increasing loading times unnecessarily.

Although it is generally not recommended to cache dynamic and especially private data through the browser cache, the HTTP protocol still allows for browser caching of dynamic resources, though the default cache-control parameters don’t strictly mandate that specific resources must be excluded from browser caching. This means that only the server configuration determines which resources —whether dynamic or static— should be cached by the browser, and for how long. Generally, the caching behavior of dynamically generated resources is managed by the CMS, so there’s usually no need for intervention. However, the same is not true for static assets. Most CMSs don't provide specific parameters for this, and those that do may not follow the caching settings recommended by Google PageSpeed. When using optimization plugins, it is important to follow their caching recommendations. If you're not using an optimization plugin, the rule for caching static resources is: “As long as possible," but at least 1 year or 31,536,000 seconds.

Note: Cache-control dictates the caching behavior and lifespan for browser caching, while x-litespeed-cache-control dictates the caching behavior and lifespan of server-side caching for dynamically generated resources, such as the main document.

The mentioned LiteSpeed speed feature allows you to leverage standard HTTP protocol functions to use the browser cache for faster loading, while ensuring that changes to the page content are still reflected. This is achieved through the use of the "etag" response header. The etag header is essentially a checksum in the form of a dynamically generated hash. This hash, when sent as part of the response, informs the browser that the content of a requested URL has been cached by the server under a unique ID (the hash). When the same client (browser) requests the same URL again, it sends the hash ID in the "If-Modified-Since" or "If-None-Match" request header. If the IDs match, the server informs the browser: “The content of this URL has not changed since the last request. Use the content from the previous request instead." Although this results in a re-establishment of the connection, no data needs to be transferred, saving time and bandwidth. It's worth noting that this feature only applies to cached URLs that have been previously accessed by the user. While a cached page can already be loaded quickly, this speed feature makes the loading even faster.

As previously mentioned, this feature does not require any special configuration or activation because it is automatically available when the LiteSpeed Cache plugin's caching function is enabled, but it is disabled if WooCommerce is used.

The CDN Problem

Although all CDNs are affected by this, quic.cloud, being a LiteSpeed service, is especially impacted. The described speed feature is removed or disabled when a CDN is used. As a result, while a CDN speeds up IP address resolution, you lose the speed advantage of previously requested URLs. The time needed to resolve the IP address of the respective host has a bigger impact on load times during the first request of a URL, but why should you have to forgo this speed feature?

Kitt Cache Crawler Solves the Problem

Kitt solves the described issue. While Kitt is designed to speed up, optimize, and reduce the load of the cache warming process, it is much more than just a cache warmer for LiteSpeed. Kitt is smart and has many features to make LiteSpeed even more advantageous. Therefore, Kitt offers a function that can reactivate the described speed feature when using a CDN.

Kitt for WordPress Kitt for WooCommerce