Configuring LiteSpeed Cache with WordPress

Knowledgebase Article

Configuring LiteSpeed Cache with WordPress

We're big proponents of LiteSpeed Cache for WordPress, a server-side page cache that stands out from the standard ones. Its server-level storage streamlines your pages' delivery by the web server, making your site quicker and more capable of handling traffic. However, implementing and configuring it might be a challenge for some. This article aims to guide you through its key features and configuration.

Advantages of LiteSpeed Cache:

Speed: Significantly reduces overhead, enhancing site speed.
Efficiency: Minimises server impact, allowing more traffic.
Ease of Implementation: Basic setup requires no special configuration, but advanced users can fine-tune a vast range of settings.

Additional Configuration Options:

LiteSpeed Cache is not just about caching. Its myriad additional settings can make your site exceptionally fast but can be overwhelming. This guide will help you navigate them.

Common Misconceptions:

If LiteSpeed Cache doesn’t seem to work on your site, it's not usually a compatibility issue but rather a need for better adjustment of settings. We'll help you understand how.

Preparation:

Before diving in, ensure the following:

Up-to-Date WordPress: Make sure your WordPress version is current.
Latest Compatible PHP Version: Utilise the latest compatible PHP version, with OpCache enabled.
Proper Cron Job Configuration: Configure WordPress to use an actual cron job instead of the default wp-cron.php.

If you're uncertain about these points, refer to our companion article with 9 steps to optimise your website.

Now, with everything in place, let's dive in! This walkthrough will help you harness the powerful features of LiteSpeed Cache to optimise your site.

Note: This guide isn't meant to replace LiteSpeed's own comprehensive documentation. Instead, we'll highlight specific features and provide recommendations for setting them up on our platform.

We'll include links to LiteSpeed's documentation for further reading where relevant. We strongly encourage you to explore their detailed, screen-by-screen guides, which cover every single feature.

This guide focuses on explaining key features that we recommend for most sites. Additionally, we'll explore some advanced features that can significantly enhance site speed.

Step 1: Enable LiteSpeed Cache in cPanel

The first step is to enable LiteSpeed Cache in cPanel.

1. Login to your cPanel and go to Software → LiteSpeed Cache or simple search for LiteSpeed in the Search tab.

2. Click the LiteSpeed Cache icon, and you'll arrive at this page

3. Click on Enable LiteSpeed Cache.

LiteSpeed Cache is now enabled for your account, however nothing will be cached until the plugin is also installed in WordPress.

Step 2: Install the WordPress Plugin

Before you proceed to install any new plugins, it can be a good idea to create a Staging Copy of your website.

Although in its basic form LiteSpeed Cache shouldn't cause any breaking issues for a website, any time you install new software into WordPress, this cannot be ruled out. It is always safer to test new plugins in a staging copy of your site.

This is particularly true of LiteSpeed Cache, as it also provides advanced level optimisation features which, if turned on or mis-configured, can cause display or functionality problems until fine tuned.

If you would like to extensively test features of LiteSpeed Cache to get an optimal setup, you should be doing this on a non-production staging copy.

1. Login to your WordPress Dashboard and from the left side menu, click: Plugins → Add New

2. Search for LiteSpeed Cache and click Install Now

3. Finally, click Activate to enable the plugin.

You've now installed and Activated the LiteSpeed Cache plugin. Your website won't yet be cached, everything will be turned off by default.

If this is an existing site, which was previously using an alternative cache plugin, this should also be Deactivated and ultimately Deleted once you are happy that LiteSpeed Cache is working. You cannot use LiteSpeed Cache alongside another caching plugin.

Step 3: Generate your Domain Key

For many of the super neat functions of LiteSpeed Cache a Domain Key is required.

This will allow you to use some of the features that can really speed up your site, such as Image Optimization, Critical CSS Generation (CCSS), Unique CSS (UCSS), Low Quality Image Placeholder Generation (LQIP), and Content Delivery Network (CDN) services.

It's usually a good idea to request your Domain Key first of all, so that you're able to make use of these features.

To request your domain key:

1. Navigate to the General page.

2. Click on Request Domain Key.

3. This will send a request to LiteSpeed to generate a unique domain key for your website. You'll see the following message to understand that this has been sent.

4. Refresh the page, and if your domain key has been generated you'll see some asterixis in the domain key box.

Step 4: Register for QUIC.cloud (Optional)

QUIC.cloud is a Content Delivery Network (CDN) and Online Services provider for WordPress created by the team at LiteSpeed Technologies. The CDN is used to speed up your site globally by edge caching the site at a number of global POPs. The Online Services component is used to power some of the advanced optimisation features, such as image optimisation, critical CSS generation and so forth. The processing is all done on LiteSpeed's servers and then sent back. For more details on QUIC.cloud, please see this link. QUIC.cloud is a paid service but the CDN and Online Services both have a free tier. You can see the pricing for their CDN here, and Online Services here. As a Kualo customer, you'll automatically get the following free every calendar month:

· 10GB CDN Data Transfer

· 10,000 Image Optimization Requests

· 2,000 Page Optimization Requests

· 1,000 Placeholder Image Generation requests

Generally speaking, unless your website has a very tiny audience, 10GB of monthly CDN data transfer may not be sufficient for the majority of websites without incurring an additional fee. The Online Services free quotas (for image and page optimizations, and placeholder image generation) are usually sufficient for most websites, unless you have a very large number of pages or images. As such, we recommend registering even if only for Online Services, and as standard, the CDN functionality will be disabled anyway unless you specifically turn this on.

It can be worth considering this if your website has an international traffic profile, as the CDN can dramatically speed up the speed of your website for your global audience. Signing up for QUIC.cloud is easy, and you won't need to supply any payment info, and will be able to use the free tier only. To do this:

1. Click the Link to Quic.Cloud button.

2. You'll be directed to the QUIC.cloud website where you can register for an account.

3. Enter your email address or sign in with one of the single signon options.

4. Complete registration, and then go back and press the button to Link to QUIC.cloud. Once linked, the button will change to look as follows:

5. You can click this button to access your dashboard. Click into the website in question and you'll see an overview screen that details your current usage.

6. You can navigate to the additional tabs at the top to see a breakdown of your usage in each area. You'll also see the free tier quotas that have been applied.

Step 5: Turn on LiteSpeed Cache

For the majority of users, the simplest way to get started with LiteSpeed Cache is to use one of their profile presets.

To do this:

1. Navigate to the Presets page in the LiteSpeed Cache menu.

2. On this page, you'll see a table containing a number of pre-set configuration options, and some descriptions detailing what this will do.

In order to use any of these presets, you'll first need to have requested your Domain Key. The presets won't be properly applied in the case that you haven't done this. Additionally, some functionality like Image Optimization won't work if you also haven't registered for QUIC.cloud.

It's important to understand that some of these pre-sets will make adjustments to LiteSpeed Cache that may not be compatible with your site without further tweaks.

· The Essentials preset is a no-risk option, which definitely won't cause any breaking changes to your site.

· The Basic preset is a low-risk option, which probably won't cause any breaking changes to your site.

· The Advanced preset is a medium risk option, which is unlikely to cause conflicts, however it's possible that it may cause conflicts with CSS/JS which may need to be rectified (more on this later).

· Both the Aggressive and Extreme presets are almost certainly going to cause conflicts which will need to be adjusted with finer tuning.

It's usually best to configure LiteSpeed Cache on a development or staging website, so you can test our all of the powerful features and make appropriate tuning adjustments without impacting how your website looks to visitors.

However, if you're implementing LiteSpeed Cache on a live production website then we'd suggest that you opt for either Essentials or Basic.

We'd suggest only proceeding with using Advanced or higher level presets if you're working in a development or staging site, or if you're completely happy that setting one of these presets may cause a display or functionality problem until you resolve this later.

If you're the kind of person who likes to understand every feature, start with the Essentials preset and then you can review all of the options and test one at a time.

When you set a preset, LiteSpeed Cache will take a backup of your current configuration, so you can easily revert if something breaks.

Step 6: Check LiteSpeed Cache is Working

Once caching is enabled, you'll want to make sure that LiteSpeed Cache is working and caching your page.

We'll do this step before we move on to a visual check to make sure it's still loading ok.

To do this, you can use a handy tool created by the LiteSpeed team.

1. Navigate to → https://check.lscache.io

2. Enter your website URL in the search box, and press Check.

3. You'll get a response to indicate if LiteSpeed Cache supported, and whether there is a cache hit.

If everything is working as expected, the output should indicate both that it is supported, and that it has detected a cache hit.

If you don't get a cache hit, try running the check again - it may be that nobody has accessed the site since you enabled caching.

If you continue not to get cache hits, take a look over LiteSpeed's troubleshooting guides for further help, and if this doesn't help, do feel free to contact us.

Step 7: Test your website is working as you expect

Now that LiteSpeed Cache should be operational, it's time to test that the website is looking and functioning as you expect.

If you opted for an Essential or Basic preset, then in all probability the site will load without any issues.

If you opted for a higher level pre-set, then you may expect some issues.

We suggest testing:

· That the site looks and loads as you expect

· That forms are functional

· If you're running an e-commerce website, that order functionality and checkout is working

· If you have a page with highly dynamic content or which may be unique to each visitor, check this is loading as you expect.

If things aren't working as you expect and you're making changes on a production website, you may either to choose a lower level preset and test again.

If you're working on a development/staging website, or if you're happy to work through any functionality issues, we'll explore this in the next section.

For the purposes of this tutorial, we've selected the Advanced configuration.

Step 8: Cache Configuration

If the Cache is working, then you may wish to tweak some of the Cache configurations.

1. Open the Cache link within the plugin menu.

2. You'll arrive at a page titled LiteSpeed Cache Settings, which will contain a number of tabs. We'll start by looking at the first four tabs, which contain the most basic cache settings.

The First Four Cache Tabs

Cache Tab

The first option on the Cache tab turns the caching functionality on and off. The remaining settings allow you to decide what types of content will be cached.

For most use cases we'd recommend leaving all of these items enabled except "Cache Mobile" assuming your site is responsive (i.e. automatically adjusts to different devices).

You can check LiteSpeed's documentation for a detailed explanation of each of these options.

TTL Tab

TTL stands for “Time to Live” and it refers to the number of seconds a page can remain in cache before it is considered stale. Once a page reaches its TTL, it is purged from cache.

LiteSpeed has different caches for logged out and logged in users. Logged out users will see the public cache, which will have a default TTL of 604800 seconds, which is equivalent to 1 week.

This means that public pages will be stored in the cache for one week before expiring and being purged. This is generally a good setting, though you can increase this if you'd like pages to stay cached for longer.

Logged in users use a separate cache called a Private Cache. The default TTL for logged in users is 1800 seconds, or 30 minutes. Caches stored in the Private Cache are stored to be unique per IP and session ID, meaning that there's no risk that a user will see unique content designed for another logged in user.

It's important to understand that if you make any changes to a page in your WordPress admin, that page will automatically be purged from the cache - so you don't have to worry about the site showing visitors stale content. Similarly if you make changes that impact multiple pages, all of the affected pages will be purged.

If you would like a deeper understanding of how content is cached and purged, take a look at this blog post. It's written at a high-level, so you can get the gist without knowing a lot of jargon.

There's rarely a need to tweak any of the settings on this page, but you can check LiteSpeed's documentation for a detailed explanation of all of the options.

Purge Tab

There are sometimes situations where pages should be purged before their natural expiration. For instance when content changes or when you upgrade WordPress.

This section allows you to define the rules for that behaviour.

If you write a new post, tag it “brownies,” and publish it in the “recipes” category, several pages will change: the home page, the recipes category archive page, the brownies tag archive page, your author archive page, and probably some other pages, depending on your theme.

All of the affected pages will need to be purged in order to avoid serving stale content. These settings give you an opportunity to adjust the rules to fit what is needed by your site.

The default selections should work for most sites, but you can change them if you need to. Hop along to LiteSpeed's documentation on this page.

Excludes Tab

You may have pages that you don't want cached at all.

These options allow you to exclude specific parts of your site from being cached.

Again, for most sites, there will be no need to change these settings. They are provided to allow you to make custom exceptions to the cache rules.

If you'd like to change any of these settings, take a look at LiteSpeed's documentation.

The Other Cache Tabs

The rest of the Cache tabs (four or five, depending on whether you have WooCommerce enabled) cover more advanced types of caching.

ESI Tab

ESI stands for “Edge Side Includes” and is a method through which you can “punch holes” in public content, and fill them with private or uncached content.

ESI is useful for things like shopping cart widgets and personalized greetings, but is disabled by default.

Unless you find that parts of your page are getting cached that shouldn't be, it's best to leave this turned off as turning on ESI can reduce the effectiveness of caching, so should be used only when necessary. Go in-depth here.

Object Tab

The settings on this tab allow you to control an external object cache (Memcached or Redis). At Kualo we support both Redis and Memcached on certain plans.

If your plan supports it, you'll definitely want to configure this.

Object Caching can significantly improve the backend speed of the site, and can help speed up certain aspects of the front end which may not be possible to speed up using page caching.

We'd suggest using Redis over Memcached for best performance.

Hop along to our separate article on how to configure this, and make sure that you enable it in cPanel first. If it's not available to turn on in cPanel, it's likely because your plan doesn't support it.

If you'd like to use it but find it's not available in your plan, please get in touch so we can advise about any costs.

Browser Tab

Browser cache is a client-level cache for static files.

With browser caching enabled, static files (like images) are stored locally on the user's device the first time they are requested.

After that, the content is pulled from their local storage until the browser cache expires. The settings on this tab control the browser cache.

Since it will mean that visitors browsers will not request a new static file until that cache period expires, you'll want to do this only once your site is in production and you're satisfied you won't be overwriting existing images or making changes to static files such as JS or CSS files.

You can also do a force refresh on your browser to forcibly request files from the server, this is done by pressing the shift key and then reloading the page.

Check out LiteSpeed's documentation on this tab for the juicy details.

Advanced Tab

There's usually nothing you need to configure in this tab unless you know what you're doing. The exception might be if you have multiple WordPress installations running in a sub-folder (note, not separate subdomains or domains).

Hop along to LiteSpeed's documentation for more info.

That wraps up the Caching component of LiteSpeed Cache. As you can see, most of this should work out the box without any configuration needed.

If you're happy with your site speed now, you could stop here. If you want to dive deeper, read on for more advanced in-page optimization.

This can be a more time intensive process depending on how far you'd like to take things.

Step 9: Page Optimization

Page Optimizations are all about improving the efficiency of the code itself.

When properly configured, these options can considerably improve the speed at which your site loads, and help you achieve very high PageSpeed scores (Google's measure of a well-optimized site).

This in turn can have a significant improvement on your user experience, and can also help improve your search engine ranking.

Finally, efficient code is also one way to ensure that your website is more sustainable.

However, there be dragons ahead….

The Page Optimizations features of LiteSpeed Cache offer an excellent way to make your site faster and improve efficiency, but misconfiguration can lead to your site displaying incorrectly or functionality being impaired.

For this reason we recommend tweaking Page Optimizations in a development or staging copy of your site, rather than making them on a production site.

Once you're happy with the configuration you can export and import it into your production site in the knowledge that it will work as anticpated.

To access Page Optimizations, select Page Optimizations from the LiteSpeed Cache menu.

You'll see a range of tabs with different settings.

Before we get into the settings below, it's important to understand that when you change many of these settings, you might not see the results of your change immediately.

This is because LiteSpeed will still be loading your site from its cache.

Therefore as you adjust each setting, you should:

1. Run the Purge All command. You can do this by accessing the LiteSpeed menu in the top navigation bar, and pressing Purge All.

2. Open up an Incognito window in your browser to test the results. In Chrome you can do this by navigating to File → New Incognito Window, and then loading up your website.

You'll always want to test the performance of your site in an Incognito window where you will not be logged into the WordPress admin area. If you load your site in a regular window, you'll still be logged in and will experience the site as a logged in user. This will have a different (and slower) response time than would be experienced by a user who is not logged in.

Keep in mind that after you run the Purge All command, everything that was cached by LiteSpeed Cache will be purged. This may mean the initial page load is slower, as it will be generating the page content dynamically in PHP.

Refresh the page to then see the cached page response.

We suggest that you change one setting at a time, review the results, and then test the site in your incognito browser.

CSS Settings Tab

When adjusting CSS settings you may need to run a Purge All command to clear the existing caches, to ensure that any CSS/JS changes are purged. If you are availing of Critical or Unique CSS features explained below, these won't be cleared on a Purge All and will require you to specifically purge UCSS or CCSS if you make changes to how those are generated.

CSS Minify

This is all about reducing unnecessary weight from your CSS files, which control how the website looks and feels.

Turning this on will strip out any extra white space characters, new line characters, and comments from all included CSS files.

This will help make your CSS files smaller, reducing the amount of data that has to be downloaded by a visitor when they access your website.

This makes your site faster, and will also improve your sustainability as your site will be transmitting smaller files across the internet.

This option is usually safe to turn on, and will be turned on as part of the Advanced preset and above.

CSS Combine

On a WordPress website, you may have many individual CSS files generated by your theme and various plugins you may use.

This setting will merge those individual CSS files into a single CSS file.

We actually recommend that you turn this setting OFF, as:

· Merging CSS can sometimes cause display problems.

· On our servers, it is often faster to transmit separate CSS files, provided your site is configured to use https://.

This reason it's faster is because when your site runs over https:// it will transmit files using the HTTP/2 protocol (or HTTP/3 where the visitors browser supports this).

These protocols support asynchronous file transfers, meaning that multiple files can be transferred to the users browser simultaneously. It's usually faster to send many small files rather than one larger one.

If your site isn't using https:// and is showing an Insecure warning in the browser address bar, we'd suggest that you convert your site to use https://. Your site will generally load much faster over https:// than over http://.

Generate UCSS (Unique CSS)

This is an advanced feature that can cause visual display issues that require tuning to resolve.

QUIC.cloud Required! This feature requires that you have generated your Domain Key and connected your QUIC.cloud account. If you don't do this, it will not work.

It's additionally recommended if you use this setting that you have an actual cron job set up on your WordPress installation so that UCSS can be generated in the background.

Remember 2 minutes ago when we just told you not to combine CSS?

Well we're about to tell you the opposite, but for good reason.

Unique CSS (UCSS) is a QUIC.cloud service that can be used along with the CSS Combine setting, to create a single streamlined CSS file for each page of your site.

This combined file will potentially be unique for each page, because it will only include the CSS that is needed to render that specific page.

The benefit is that by only including necessary CSS, the size for each combined CSS file remains small and processing time may be significantly reduced. For more details on UCSS and how this can benefit your site (and in particular PageSpeed sore) please see LiteSpeed's introductory article on UCSS.

Display problems after enabling UCSS? The way UCSS is generated is by looking at the CSS selectors on the page HTML code. This works in the vast majority of cases, but there may be some selectors that aren't initially displayed in the HTML code. Some may only appear after a user scrolls, or after a JavaScript action runs. If the you turn on UCSS and find that there are display issues, you may need to identify which CSS selectors are not present in the HTML code but which are included later on. You can add these CSS selectors into the UCSS Whitelist box. For more details on how to debug issues when using UCSS, please see this article from the LiteSpeed team.

UCSS Inline

This setting will place your Unique CSS inline, embedded in the HTML code.

We recommend keeping this OFF, as it's often still more efficient to load CSS as a separate file.

CSS Combine External and Inline

Since we don't usually recommend combining CSS (unless you're using UCSS) we also suggest this is turned OFF. It is not usually needed if you are using UCSS as those inline styles will likely be unique to the page itself.

Load CSS Asynchronously

This is an advanced feature that can cause visual display issues that require tuning to resolve.

QUIC.cloud Required! This feature requires that you have generated your Domain Key and connected your QUIC.cloud account. If you don't do this, it will not work.

It's additionally recommended if you use this setting that you have an actual cron job set up on your WordPress installation so that Critical CSS can be generated in the background.

This feature can significantly improve your PageSpeed scores and increase the speed at which your site loads.

Under normal circumstances, a web page will load your CSS first, followed by your HTML code. This ensures that your website styles are loaded, followed by the HTML content.

It is done in this order so that when the HTML content loads, your browser already knows how to lay that content out as the styling data has already been read and interpreted by the browser.

Forcing the CSS to load first creates a delay as the browser has to wait for the CSS to load before it can start rendering the HTML.

This setting will allow CSS to load Asynchronously, so effectively it can be delivered at the same time as the HTML code, increasing the speed at which your page loads and your all important PageSpeed score.

The problem is that the page may start to render before all of the CSS has been downloaded.

This can result in a Flash of Unstyled Content (FOUC). In other words, the page loads without styling, and then the page re-adjusts when the styles are loaded.

A FOUC can make for a jarring user experience as the page re-arranges itself to have proper styling.

The folks at LiteSpeed have therefore created a solution to avoid this FOUC, by automatically generating what's known as the Critical CSS.

Critical CSS is the collection of styles that are required in order to properly display above-the-fold content, that is to say, the content that will be visible in the users browser when the page loads.

To prevent a FOUC, these styles are inserted inline into the HTML code and are processed with the HTML, eliminating the problem of unformatted content.

You can read more about Asynchronous CSS Delivery, Critical CSS and FOUC on LiteSpeeds blog post.

Still seeing a FOUC? This feature is a fantastic tool to improve site performance, but there are some gotchas that you need to be aware of and may require developer involvement.

· Critical CSS takes time to generate, and depending on your settings may only happen when the WordPress cron runs.

· Some CSS rules may not be visible in the HTML code until a subsequent action takes place. It may be necessary to add these rules manually.

If you still see a FOUC and wish to use this setting, we suggest reading LiteSpeed's documentation on how to resolve such issues.

CCSS Per URL

As standard LiteSpeed will generate Critical CSS per post type, so in other words, one CSS file per page, post or product.

Setting this option to ON will generate Critical CSS for each URL.

We'd only suggest turning this ON if you have dramatically different styling for each page type. In most cases, this won't be necessary.

This option can cause issues with page builders. If your site uses a page builder, this option may cause display issues.

Inline CSS Async Lib

We generally recommend to keep this OFF, otherwise it can cause font display issues in most cases.

Font Display Optimization

We suggest setting this to DEFAULT. Setting it to SWAP can cause font display issues, where font appearance can change during the page load.

JS Settings Tab

The Javascript Settings tab allows you to optimise your sites Javascript delivery, which can help improve your sites PageSpeed scores.

These settings can cause issues on some sites, and so as with CSS settings, you should proceed in a development site or otherwise proceed in the knowledge that some of these settings may cause functionality or display issues. You can always revert a setting if this happens.

JS Minify

As with the CSS minification option, this setting removes unnecessary data from your JS files, such as spaces, line breaks and comments.

It's usually safe to turn ON, and will be on if you chose the Advanced profile.

This will reduce bloat from your JS files and make them smaller and faster to download, and help increase your PageSpeed score.

JS Combine

As with CSS combine, provided your site is loaded over https://, we recommend leaving this setting OFF. It's usually faster to serve up individual files on our servers.

JS Combine External and Inline

If you do want to combine your JS into a single file, this option also makes sure any inline JS is also included in that file. It can help reduce problems that may occur with combining JS files. We'd usually recommend you don't do this, however, and set to OFF.

Load JS Deferred

This option can have a significant impact on your PageSpeed score, however, it can also cause problems for some sites.

Enabling this option can eliminate or greatly reduce the Eliminate Render Blocking Resources that you might see in your PageSpeed report.

Both the Deferred and Delayed options hold all JavaScript processing until after the HTML is finished loading. The difference is in the timing.

· Deferred runs the JS as soon as the HTML is finished loading. This is the classic mode for deferred JavaScript.

· Delayed doesn't run the JS until it detects user activity (like a key click or mouse pointer movement).

Both options should improve your page speed score, but Delayed has the greater potential for improvement, as it has the effect of removing JS entirely from the page speed score calculation.

You'll need to throughly test all functionality on your site after enabling this option.

What to do if your site has issues after enabling these options?

If your site has reduced functionality or visible problems after deferring your JS, then this can usually be resolved with additional tweaks. For instance, the problem may be caused by the deferral of one particular Javascript file, but all of the rest of them can safely be deferred.

LiteSpeed Cache gives you the flexibility to exclude certain Javascript files from being deferred.

We'd suggest reading their detailed documentation on how to accomplish this.

HTML Settings Tab

HTML Minify

As with CSS and JS minification, this is removing unnecessary code. It is usually safe to use.

DNS Prefetch & DNS Prefetch Control

These tools can speed up loading of resources that are loaded from different external domains, and can also speed up link clicks to external websites.

Your website may load a number of resources from different domains, including Javascript and CSS. Traditionally, those resources will be requested when loaded by the browser, and the browser will need to do a DNS lookup to find out the IP address to request those resources from.

Whilst DNS lookups are often fast, they can be somewhat slower on mobile connections.

This setting will instruct the browser will pre-fetch the DNS ahead of the resource being requested. This means when it actually comes to make a request to that domain, it won't have to do a DNS lookup, shaving off an extra few milliseconds.

You're effectively giving the browser a heads up so it can get to a resource faster; it's a bit like saving a number in phone's address book, rather than having to look it up in a directory and type it in each time.

The difference between the two is that the DNS Prefetch option allows you to specify a list of domain names that you'd like to run DNS pre-fetch for.

You can check this by opening up Developer Tools in Chrome (use an incognito window so that you're not loading Admin Area resources). Open up a page on your website, and press the Sources tab in Developer Tools.

You'll see a list of resources your page has requested. The ones with a cloud symbol (excluding your own domain) come from 3rd party domains.

In the above example, the domain fonts.bunny.net as the only external domain we are loading a resource from. This needs to be entered in the following format:

//fonts.bunny.net

If you had a resource with the domain www.myresource.com, this would be entered as:

//www.myresource.com

DNS Prefetch Control is a wide lookup, LiteSpeed will review all of the external domain names in the HTML source and automatically pre-fetch the DNS for all required domains without the need to manually specify this.

For more details on DNS Prefetch please take a look at this page.

We'd recommend that you turn on DNS Prefetch Control, doing so will not cause any harm to your page.

HTML Lazy Load Selectors

If you've got very long pages you may be loading HTML that the visitor well never reach, because they simply never scroll that far.

Using HTML Lazy Load Selectors allows you to further minimise the amount of HTML code that is transmitted, as LiteSpeed will only render that HTML content as the user scrolls down the page and approaches that selector. It will load it before that part of the HTML approaches the viewport (i.e. before it becomes visible).

By minimising the amount of HTML that is loaded by the browser initially, you will speed up the initial page delivery, without impacting usability. This can also help to improve your PageSpeed score as Google won't count this HTML in your page weight.

You should use this carefully as you need to be careful not to specify HTML that might be too high up in the page, and certainly avoid anything that would need to ever be displayed ‘above the fold'.

The first job is to identify which selectors to use.

You can do this by inspecting your HTML code with Developer Tools again in an Incognito Window. Use the Inspector :inspector: tool and then locate the element you want to Lazy Load. In the source, make sure you're selecting the most appropriate parent element (usually a div or section) so that you're not being too granular (i.e. just choosing an image or child div).

Right click it in the code, and press Copy Selector. This will copy the selector in question.

It may be an ID (in the format #footer or similar) but can also be a class (in the format .page-footer or similar). If you're choosing a class rather than an ID, be careful that it's not a class that's used widely on the page which may impact content higher up.

You can then place this selector into the HTML Lazy Load Selectors section and that HTML block will then won't be loaded initially, and will be ‘lazy loaded' as the user navigates down the page.

A good use for this may be to lazy load your footer or comments section, which will typically be much lower down the page.

Remove Query Strings

This option will improve how well your site can be cached by removing query strings from static resources. For instance, sometimes a theme might append a query string to a CSS file or similar (such as version=?1234). This is often unnecessary and we can cache the same file in LiteSpeed.

This option is generally safe to use, but there may be edge cases where a static resource requires a specific query string.

If you do have static resources that require a query string to load properly, you can ensure that these are called with the query string by appending &_litespeed_rm_qs=0 to the static resource. The important query string can then be preserved. You may need to edit this in the theme itself.

Load Google Fonts Asynchronously

This can help improve PageSpeed scores, but it may have the effect of causing fonts to display and then visibly change after the page loads. LiteSpeed will automatically add a pre-connect to Google so that this happens quickly, but if you find it too jarring and have fonts above the fold, you may wish to keep this setting OFF.

Remove Google Fonts

Google Fonts will be completely removed from your site. This will improve speed and PageSpeed but may cause font display issues if you don't have a local copy of the font. Usually we'd advise keeping this OFF unless you know what you're doing or aren't actually using Google Fonts but they're being included somehow by a plugin/theme.

Remove WordPress Emoji

This is usually safe to turn ON. The vast majority of users will be on modern browsers that already understand how to display Emoji's natively, so this removes the need to specifically add these in. Turning this off will mean visitors on really old browsers might not be able to see Emoji's in comments or posts, if you even use these.

Remove Noscript Tags

This is usually safe to turn ON. These tags may be used for compatibility with older browsers that don't support Javascript. These are so few and far between that it's simply often not worth catering to them any more, and will help remove redundant code from your site.

Media Settings Tab

QUIC.cloud Required! Many image optimisation features will require QUIC.cloud. So make sure that you have generated your Domain Key and connected your QUIC.cloud account. If you don't do this, some of the functionality won't work.

It's additionally recommended if you use this setting that you have an actual cron job set up on your WordPress installation so that images can be optimised in the background.

The Media Settings tab is where you can optimise images and embedded content. It's a really important section to help ensure your website is as optimised as can be with the best possible PageSpeed score, and so you'll want to pay attention to this section.

Lazy Load Images

This is a great feature that can dramatically improve your PageSpeed score. Without Lazy Loading your images, every single image in your website will be requested from the server, regardless of whether the visitor actually scrolls far enough down your page to see them.

This means that you're transferring image data across the internet regardless of whether they're ever going to be seen.

By Lazy Loading your images, they're only requested just before the visitor scrolls far enough down the page so that they'll soon enter the viewport. This improves your code efficiency as you're making your website lighter, and improves your sustainability as you're significantly reducing the amount of data that your website needs to transfer.

We recommend turning this ON, however to ensure this works well, you may to do some additional work to exclude some images from Lazy Loading. Specifically, any images that display above the fold should be excluded.

The easiest way to do this is to let LiteSpeed handle this automatically.

This can be done in the VPI Tab.

In this tab, you'll find:

Viewport Images: Set this to ON

This will automatically exclude images that are above the fold from being Lazy Loaded.

Viewport Images Cron: Set this to ON

This will automatically send requests to QUIC.cloud to process Viewport Images via the scheduled cron.

QUIC.cloud Required! To use the Viewport image features you will need QUIC.cloud enabled, and you'll need an actual Cron Job set up.

When you enable this you'll see a list of URLs queued up to send to QUIC.cloud so it can determine which images need to be excluded from Lazy Loading.

You can press:

To process these right away. Otherwise, it will start processing the list when your scheduled cron job runs.

Once these have been processed, Lazy Loading should in most cases be fully functional (you may need to clear all caches to see this).

If you still have images that are being lazy loaded which you'd rather weren't, then you can also fine tune this.

We'd suggest taking a look over LiteSpeed's blog post which explains in detail. In brief though, you can add excludes in two ways:

· By adding data-no-lazy="1" to the elements you'd want to exclude.

· By adding the path to the images you'd like to exclude under the Media Excludes tab → Lazy Load Image Excludes box. If you do this, we suggest using a partial match. For instance if you name all of the images you want to exclude a certain way, such as imagename-lazyexclude.png, then you could simply add a partial match for any image with imageexclude in the file name.

· You can add a class to images you'd like to exclude, and then add that class to the Media Excludes tab → Lazy Load Image Class Name Excludes box.

· Similarly, you can add a class to a parent element. Such as your nav bar, or the sections of your page that always appear at the top above the fold. You can then include that class under the Media Excludes tab → Lazy Load Image Parent Class Name Excludes box. Every image within that parent will then be excluded from lazy loading.

One thing to note with Lazy Loading is that if a user scrolls very quickly, or if you have a script in place that allows a user to automatically scroll down page when they press a button, they may see the images appear as they scroll.

You can address how this looks by adding some custom CSS into your website to alter how lazy load images appear, for instance by having them softly fade in. LiteSpeed provide some CSS code for this in case you'd like to use it.

We'd strongly recommend you lazy load images to ensure your site is well optimised, but also so you can do your bit for the planet and avoid unnecessary file transfers.

Basic Image Placeholder

This can be used to specify an image placeholder to show in the place of the image, before it's lazy loaded. This is a complex setting as it requires you to generate a base64 image, if you don't specify this a grey image will be used. We'd suggest not worrying about this setting as LiteSpeed have a better solution below, provided you're using QUIC.cloud - called LQIP.

It's worth noting that these placeholder images will only ever be seen if a user scrolls fast enough that the image hasn't been able to load yet.

Responsive Image Placeholder

We'd suggest turning this ON if you decide to use Lazy Load Images and aren't going to use QUIC.cloud. This will ensure the placeholder image is set to the same dimensions that the original image would be.

Similar to the Basic Image Placeholder, the setting below this, Responsive Placeholder SVG, allows you to insert a custom SVG image that can be used. You can use this if you need to and know what you're doing, the default will otherwise just be a grey image, or you can customise the colour using the next option: Responsive Placeholder Colour simply by picking the colour you like the best.

If you're using QUIC.cloud, skip this and head to the LQIP section below.

LQIP Cloud Generator

If you're connected to QUIC.cloud, then this option will be much better than using a standardised placeholder image. Rather than use a default placeholder image for all images, LiteSpeed will actually generate a very small, low resolution image that will load in its place.

This way, before the Lazy Loading takes place, the image will appear to look like the original image, but it will appear slightly blurred as it will be a very minified low resolution version of the image. When lazy loading takes place, the image will adjust to become crystal clear, and often before the user has even scrolled that far.

Using this setting will override the above placeholder options, so there's no need to configure them at all.

If you use LQIP, you can adjust the next few settings too.

LQIP Quality specifies how low quality you'd like this image to be. The default setting is 4 and this is usually fine to keep as is, but if you'd like to have the lower quality images a little less blurry, you can set this higher. Keep in mind that the higher you set this, you'll be increasing your sites weight and negating the benefit of using Lazy Load Images.

LQIP Minimum Dimensions specifies the minimum size image that you'll generate an LQIP image for. There's limited benefit for doing this for very small images. The default is 150x150px and we'd suggest keeping this as is. That way LQIP will only process images that are large enough to warrant this.

Generate LQIP in Background allows LQIP images to be generated by your cron job. You should set this to ON otherwise LQIP may slow down your page execution, as they'll be generated whilst the visitor waits.

Ensure that you have an actual cron job in place so that LQIP images are properly generated in the background.

Lazy Load Iframes

Many sites load content within Iframes, such as 3rd party widgets, or YouTube videos. These can sometimes be very heavy, and so in the same way as there's no sense loading images if the user never scrolls that far, the same is true of this content.

We'd recommend using this if you know that your site loads 3rd party content in Iframes or uses embedded video.

You'll need to apply similar tuning as you did with images, using the Media Excludes → Lazy Load Iframe options.

Add Missing Sizes

If you're using Lazy Load Images it's worth turning this ON. This setting will explicitly set a width and height on image elements where none is set, helping avoid layout shifts and improve your PageSpeed score. This is usually safe to enable and improves the experience, but if it causes problems you can turn it off very easily.

Has Lazy Loading negatively impacted your PageSpeed score?

If you run your PageSpeed analysis and find that your PageSpeed score reduces after enabling Lazy Loading, it's likely due to above the fold images being lazy loaded. You may see new warnings in the PageSpeed report, such as: Largest Contentful Paint image was lazily loaded: Above-the-fold images that are lazily loaded render later in the page lifecycle, which can delay the largest contentful paint. This warning suggests that there are images on the page that are being Lazy Loaded which are above the fold. If you've got Viewport Images set to ON but this warning still shows, then it may be that LiteSpeed hasn't been able to do this automatically for your website. You will need to selectively include above the fold images by using one of the methods described above to exclude them.

Localization Tab

This tab allows you to minimise dependency on 3rd party resources, thereby reducing the number of connections required to other services.

Gravitar Cache

WordPress uses Gravitars to automatically generate user avitars (profile images) based on their email address.

By caching these, you can minimise lookups to Gravitar.

This is very safe to turn ON and we'd recommend doing so. You can additionally set Gravitar's to generate via Cron and adjust how long these will be cached for, the default is 604800 seconds (1 week). You could probably set this much higher in reality - as people don't tend to update their Gravitar with much frequency if at all! Consider setting it to either 3 months (7890000 seconds) or 6 months (15780000 seconds).

Localize Resources

This is a more advanced feature that alllows you to use a local copy of static resources that would usually be hosted remotely. Your site may for instance use remotely hosted JS or CSS files. If your site loads these remotely, then you have no way to optimise them. By localising them, you can ensure that they are well optimised.

In order to use this feature you would need to turn the feature on, and then list the full URLs to the resources you need.

LiteSpeed will then adjust your HTML to use local copies of these resources.

You'll need to thoroughly test that your site works properly after making this change.

The localized resources will remain local until the cache is cleared, so one negative to doing this would be that if the vendor changes the content, it won't update until your cache is purged. This could lead to you having out of date CSS/JS files if the source file changes.

Step 10: Image Optimisation

QUIC.cloud Required! To get the most out of LiteSpeed's image optimisation features, you will need QUIC.cloud enabled, and you'll need an actual Cron Job set up so that image optimisation can happen in the background. Image Optimisation can be used without a QUIC.cloud account, but your images will be processed with a much lower priority.

Often when site admins add images to WordPress, those images are not particularly well optimised for display on the web. We sometimes get people logging complaints about their website being slow, only to find that they have several megabytes of images in use on a single page, usually because those images have been uploaded using high quality originals.

LiteSpeed's image optimisation features allow you to optimise existing images, and automatically optimise images as they are added to your site. This means that you can rest assured that the images on your website are always as optimised as can be for display on the web without having to go through the hassle of optimising images pre-upload using image editing software.

Using optimised images will usually mean that your site will:

· Load faster

· Transmit less data across the internet, making it more sustainable.

You have control over how extensively you'd like LiteSpeed to optimise images, and it can be done without any visible loss in image quality.

You should NOT use any other image optimisation plugin at the same time as using LiteSpeed's image optimisation. This can cause undesirable behaviour or result in a huge duplication of files.

Before we begin, it's worth noting how LiteSpeed optimise images. The optimisation itself is done on LiteSpeed's own servers. This means that your images are transferred to their processing servers, where they are processed, and once completed the optimised images are downloaded. Images will be sent to LiteSpeed's image processing server in batches, so it may be that it takes a few runs to optimise all of your images, particularly if you have lots of images on your website. LiteSpeed start with small batches to make sure that everything is working properly, and these batches are gradually increased in size until they reach 200 images in a single batch.

The original images are preserved, just in case you ever wish to restore to them.

If you have a QUIC.cloud account connected, your images will be processed with a higher priority, so it's well worth getting that hooked up.

Image Optimization Summary Tab

When you first load the Image Optimisation page, you'll land on the Summary tab, and see a screen similar to the following (assuming that you have previously applied at least the Basic Preset, which includes configuring Image Optimisation).

Provided you have a cron job set up, then your images should automatically optimise in the background and this page will update to show you how many images have been processed so far. In the above example, every image has already been optimised.

This page gives you an easy way to:

· Switch between using optimised and original files

· Calculate the size of the original files, and optionally remove them. You may wish to do this if you are happy with the optimisation and need to free up disk space in your hosting account. This is irreversible so only proceed with this step if you must.

Image Optimisation Settings Tab

This tab is where you can configure how images are optimised.

Auto Request Cron / Auto Pull Cron

You'll always want these options to be set to ON and also ensure that your WordPress has a proper cron job in place. Image optimisation requires uploading and downloading images from LiteSpeed's server, so it's important that this is handled as a background task by cron. If you don't have a proper cron job in place, if image optimisations are required this will happen when PHP executes, i.e. when a page loads, and may slow down the loading of that page.

Optimize Original Images

This should be set to ON for Image Optimisation to work.

Remove Original Backups

This option will automatically remove the original images after they have been optimised. We'd recommend keeping this OFF, just in case, however you may enable it if you're tight on disk space. Keep in mind that if you do enable this and need to revert to original images, your only recourse will be to re-upload them.

Optimize Losslessly

We'd recommend setting this to OFF so that you use the default "Lossy" compression. Setting this on ON may improve the image quality as the files will have no visible change, but the difference may be negligible, and the file sizes will be much larger.

Lossy compression might sound scary, but the reality is that the images still look great and the file size savings can be significant.

You can also control the image compression ratio, using the WordPress Image Quality Control setting lower down the page. The default value is 82%, setting a lower number will further reduce the file size but if you're using Lossy compression the image quality may worsen.

Preserve EXIF/XMP data

Set this to OFF so that any unnecessary metadata is stripped from your images, such as GPS locations. You almost certainly don't need these if they're present and they'll only be increasing the file sizes.

Image WebP Replacement

WebP images are modern image file formats that use significantly smaller file sizes. They're not supported by all browsers, but if the browser supports WebP, it will be much faster. Using WebP images will also increase your PageSpeed scores.

You can read more about WebP here.

Enabling this option will ensure that LiteSpeed will start to create WebP versions of your images.

If you already had image optimisation set up, it won't convert any images that have already been converted to WebP. So you'll need to destroy all optimisation data and start over from scratch.

As WebP is only supported by certain browsers, LiteSpeed will create a cache vary for those browsers that are known to support it. That cache vary will be used if ever someone accesses your site with a compatible browser, and another version will be used if someone accesses your site with an older browser that can't yet support WebP. This ensures that you never deliver a version of your website with WebP images to a browser that cannot support it.

Please see LiteSpeed's docs for detailed information on WebP and how to make sure it's working properly.

Step 11: Set up the LiteSpeed Crawler

LiteSpeed can only cache a page when it is accessed by a visitor.

If you purge your entire cache, content updates invalidating some of the cache, or the cached page expires, the page will load dynamically using PHP and making normal MySQL queries.

To minimise the possibility that a visitor lands on an uncached page, LiteSpeed has a built in page crawler which can keep your website cache warm. This can be particularly useful for websites with lots of pages, or where data changes frequently, or even those websites with low visitor levels.

In order for the crawler to work, your website must have a sitemap. WordPress will usually have a default sitemap which usually exists at https://www.yourdomain.com/wp-sitemap.xml though you may have installed a separate SiteMap plugin which stores the sitemap at a different location. Just navigate in your browser to see if you can load the sitemap, and check for any SEO or Site Map plugins to make sure it's not in a different location.

Once you've identified your sitemap URL, you need to put it in the Sitemap Settings tab and hit Save Changes. Drop Domain can be set to ON unless you run multiple domains for one site and Sitemap Timeout can be left as 120s.

Once this is added, head along to the Map tab.

It will likely be blank, indicating no pages have been found in your Sitemap.

Press Refresh Crawler Map which will use the Sitemap you just defined to generate a list of pages to crawl.

If all is well, the page should update with a list of your website pages.

Next, head across to the General Settings tab. This has a number of advanced options explained in detail in LiteSpeed's documentation. We'll run over some of the key settings below.

Initially, you'll want to ensure that the Crawler is set to ON. This will ensure that the crawler starts to function.

We'll next define the Delay, Threads and Server Load Limit.

Delay

The delay setting defines how quickly LiteSpeed can crawl your site. The default is 500 microseconds. If you host your site on a Kualo shared hosting plan, the minimum value you'll be able to specify is 30000. This can be set to any limit if you are on a VPS or Dedicated server, though we'd recommend keeping it at the default limit.

Threads

This defines the number of simultaneous crawl processes that can be run. If you host your site on a Kualo shared hosting plan, set this to 1. On a VPS or Dedicated server, we'd suggest leaving the default limit to 3 but you can set this higher if you know your server has a lot of CPU capacity.

Server Load Limit

This limit determines if the crawler will run at all.

LiteSpeed's default setting is 1, which is usually far too low. It is designed for a server with a single CPU core.

To understand this limit it's necessary to understand a little about what a server load limit is in the first place. In a nutshell, a server that has a single CPU core is considered to be at maximum load when the load reaches 1. A server with 2 CPU cores is at maximum load with a load of 2, and so on.

So what limit should I set? This depends on how your site is being hosted, and whether you're using our shared hosting, or whether your hosting your site on your own VPS or Dedicated Server.

I'm hosting my website on a Kualo shared hosting plan

Kualo's shared servers are mighty powerful, and may have 40 or more cores available. If the server has 40 cores and has a load of 20, it means it's only operating at half load and has plenty of spare capacity. If you set this limit at 10, it will mean the crawler may never function unless the load is under 10, even though the server can handle it.

On our shared servers, we set a manual override to prevent this limit from being set too high.

You'll see this defined as follows: NOTE: Server allowed max value: 30

You can set the load limit to this value.

I'm hosting my website on a VPS/Dedicated Server

If you host your website on your own VPS or Dedicated Server, you can set this limit up to around 75% of your total available cores (rounded to a whole number). So if your VPS has 8 cores, set this limit to 6.

You can usually also set the number of threads, we'd suggest leaving this to the default of 3 but you can set this higher if you know your server has a lot of CPU capacity.

When in doubt, feel free to ask us.

What about other settings?

We'd recommend leaving the default settings for Run Duration and Interval Between Runs, if ever you start to hit resource limits on your hosting plan or server these limits can be adjusted and we can advise on this. Usually you'd want to reduce the Run Duration and increase the Interval Between Runs to make the crawls happen with less frequency.

The Crawl Interval setting determines how often the crawler will start to re-crawl your site. The appropriate figure here can only be known once the crawler runs and you can determine how long it takes to crawl your site. A site with a large number of pages will take longer to crawl.

To determine this, keep the default setting in place and save the settings page so your other adjustments above are saved.

Jump back to the Summary Tab and press the Manually Run button. Depending on how big your site is, this may take a while to complete and you may need to check back in a few hours.

When it completes, it will record the Run time for Previous Crawler.

If the crawler took 4 hours to completely crawl the site, then a sensible limit might be to set this to 5 hours or 18000 seconds. That way, you know that a new crawl will be initiated soon after the last crawl finished.

We don't recommend setting this to less than an hour or 3600 seconds, even if the crawl run takes much less time as it's usually not needed.

How to Check if the Crawler is Working?

The Summary page on LiteSpeed will display different coloured boxes that indicate the status of the pages being crawled. Here's what the colours mean:

Green Box: Pages that have been visited by the crawler and are already in the cache. No action was needed, so they haven't been re-populated.
Blue Box: Pages that were successfully crawled and weren't previously cached. They will now be cached.
Grey Box: If you see numbers in this box after a few runs, it signifies pages that can't be crawled for some reason.
Red Box: Indicates a page was crawled but has been manually excluded. This should only be the case if there are pages that you have specifically told LiteSpeed not to crawl for some reason.

In essence:

A number in the green box means everything is fine with those pages.
A number in the blue box means those pages are now freshly cached.
Numbers in the grey or red boxes may require attention, depending on the specific circumstances.

By observing these numbers and colours, you can quickly understand the status of the crawling process and make necessary adjustments as needed.

That completes the crawler setup, you should now find that your pages are being crawled by LiteSpeed.

Step 12: Review Database Optimisation

Another aspect that can impact site performance, which can be optimised via LiteSpeed, is the MySQL database. LiteSpeed have a useful blog post on why this is useful, which you can find here. You can also review their detailed documentation on these screens here.

Over time, your MySQL database may become bloated with things that are no longer required to be stored. Depending on your site or how large it is, this can cause your database performance to degrade.

The tools on this tab allow you to clean up your database.

It goes without saying that before you do any such database work, it may be prudent to take a backup just in case.

If the numbers you see on this page are in single or double digits, there's not much to worry about here. If you're seeing triple or higher digits, it may be time to do some pruning.

You can do these one by one, leaving Optimise Tables until the end. Before pressing ahead, consider carefully if you want to purge post revisions or auto-drafts, as once they are removed they will no longer be available to you. For post revisions, you can configure some thresholds to how many post revisions you're comforatble removing (setting this to 1 would mean it will delete all bar the most recent). You can also define an age threshold, so you can delete really old revisions, but keep anything that you may have been working on more recently.

We'd also suggest that you don't usually need to purge all transients, it's only useful to purge expired ones.

The final step is to Optimise Tables, which will reoganise the tables to be more efficient and reclaim some disk space. Optimising tables is always a good idea to do periodically or after a large amount of data has been removed.

Lower down on this page you'll also see a list of your database tables which are using MyISAM, and allow you to convert them to InnoDB. Many installations will have MyISAM set as the default engine, and it may be the case that when WordPress or plugins are installed they default to this storage engine for maximum compatibility. However, InnoDB is generally more reliable and performs better. InnoDB does not lock full tables, and so it allows queries to run faster.

We'd suggest that you convert any MyISAM tables to InnoDB.

The Database Optimisation features do not run automatically, and would usually be a task that you'll want to run periodically. How often you should run this depends on how large or busy your website is, and how much your data changes over time. We'd suggest taking a look at this page at least once a month or when you make broad changes to the website, such as updating or installing plugins.

Step 13: Integrate a CDN

If your website has an international traffic profile, you may wish to integrate a CDN to further speed up delivery. LiteSpeed can integrate with any CDN service, but they also offer a quick integration with CloudFlare, and provide their own CDN solution via QUIC.cloud.

You'll need to determine if you'd like to use CloudFlare (available as a basic CDN at no charge) or a 3rd party paid CDN such as BunnyCDN (which is always paid), or QUIC.cloud (which has an initial free tier, after which you'll incur costs).

One of the benefits of using LiteSpeed's QUIC.cloud CDN is that your HTML can be cached at the edge. This means that not only will your static files be served via their CDN, but also your HTML code. This can dramatically increase the speed of your website if you have an international audience.

If you'd like to use QUIC.cloud's CDN, hop over to their documentation to discover how to set this up.

That's the end of this guide. If you made it this far, you should have successfully configured LiteSpeed Cache for your website. Don't hesitate to reach out if you have any queries!