WordPress Litespeed Cache Configuration

WordPress Litespeed Cache Configuration.

WordPress Litespeed Cache configuration. In this post I’ll be talking about the configuration options available in the Litespeed Cache plugin and how you can use these to improve the performance of your website. Hopefully this will help you arrive at the best WordPress Litespeed cache configuration to improve your site’s performance.

This WordPress Litespeed Cache configuration post follows on from the introductory post about the Litespeed web server and it also provides specific configuration options covering the Litespeed Cache plugin that’s mentioned in this post about WordPress and Caching plugins. You might consider reading these posts to provide some background information, but this isn’t mandatory. Object caching is also mentioned below, and you can find further information about Object Caching in this post.

Before you start using the Litespeed Cache Plugin.

To get the most from the Litespeed Cache plugin, you’ll need to be using hosting that uses the Litespeed web server. Although it is possible to use this plugin on web hosting that doesn’t use the Litespeed web server, the improvement in site performance won’t be as great if your hosting doesn’t provide the Litespeed web server. Consequently, before you even get started with WordPress Litespeed Cache configuration, you’d be best to check if the Litespeed web server is available in your hosting.

How to Check if the Litespeed Web Server is Available.

You can check to see if the Litespeed web server is available in your hosting using the Google Chrome browser.

• Using Google Chrome browse to your site.
• Right click on your site’s page, the click on “inspect”.
• Click the “network” tab. (step 1 on the screen shot below)
• Refesh the page. (step 2 on the screen shot below)
• Click on a resource in the network tab. (step 3 on the screen shot below)
• Click on “headers”. (step 4 on the screen shot below)
• Check the “sever” section. (Highlighted at the bottom the screen shot below)

Once you’ve done the right click, inspect part, the rest looks like this:

In the screen shot above, you can see the server is Litespeed, so Litespeed is available. If you see Apache or Nginx in the server section, you don’t have litespeed available.

You can still use the Litespeed Cache plugin if Litespeed isn’t available, but the results won’t be quite as good.

This guide covers WordPress Litespeed Cache configuration, using the Litespeed Cache pugin when the Litespeed web server is available. Please take that in to account when reading this guide.

WordPress Litespeed Cache configuration.

You’d install and activate the Litespeed Cache plugin just as you would any other plugin.

The Litespeed Cache plugin provides some predefined cofiguration profiles that make it easy to carry out the initial set up. To access these, hover over “Litespeed Cache” in the menu on the left hand side, then click on “Presets”:

What you’re doing here is choosing a predefined WordPress Litespeed Cache configuration profile.

After applying a preset, it’s a really good idea to check that your site functions OK.

The “advanced” preset isn’t as likely to have any negative effect on your site, but you might then need to tweak the config of the Litespeed Cache plugin to gain some of the additional benefits it can provide.

You could give the “aggressive” preset a try, but you might find there are some CSS type issues with your site if you do this. These could then potentially be addressed by disabling the CSS combine, and / or the JS combine (these are under Page Cache > CSS and Page Cache > JS respectively). You might also need to try adjusting “asynchronous CSS” as well, in the same manner.

Once you have a preset in place, and your site is functioning as it should, you can then start working through the configuration options to effectively tweak what the preset has bought in to effect.

It’s advisable to check your site after making and saving any changes to see if there’s been any negative effect.

Now that a preset is in place, let’s go through the WordPress Litespeed Cache configuration plugin options page by page.

Litespeed Cache – General

The General page of the Litespeed Cache plugin settings is just that: General configuration settings.

Automatic Upgrade.

I have this turned on so that upgrades are automatic. The hosting provide I use has built in daily backups which I can restore from if there’s an upgrade specific problem. Upgrades and updates are sometimes made available to patch against vulnerabilities, and the whole world can access my site, so there’s that too. You could turn this off if you’d prefer to manage upgrades manually… let’s hope you don’t remember you didn’t upgrade when you’re on the plane going on holiday to a place with no internet though!

Domain Key.

You’ll need to request a domain key to link to QUIC.cloud services. These services include Image Optimization, Critical CSS Generation (CCSS), Unique CSS (UCSS), Low Quality Image Placeholder Generation (LQIP), and Content Delivery Network (CDN) services. You’ll need to request a domain key then link to QUIC.cloud to be able to use these services.

Guest Mode.

Guest Mode is designed to load your site as quickly as possible for a user’s first visit. It also improves load time for first time visitors. It’s not just human visitors that benefit from Guest Mode, though. Search engine bots and page speed checkers also get the fastest page load possible, leading to better search rank and improved page speed score with Guest Mode enabled, so it’s a good idea to have this enabled. If you’re interested you can read more about Guest Mode on the Litespeed blog.

Guest Optimisation.

If you have guest mode enabled, it’s a good idea to have this enabled too. Guest Optimisation effectively take guest mode even further with regard to performance improvements. If you haven’t enabled guest mode, there’s no point in having Guest Optimisation enabled. Generally speaking, I\d suggest enabling both Guest Mode and Guest Optimisation.

Server IP.

You’ll need to enter the IP address of the server on which your site is hosted here. This allows cloud services directly call IP instead of domain name. This eliminates the overhead of DNS lookups. You can find the IP address of the server you’re hosted on either in your hosting control panel, or by pinging the address of your site (command line on Windows, Terminal for MacOS/Linux).

Notifications.

This one’s totally up to you. It doesn’t affect performance, you just get notificaitons about latest news, hot fixes and so on, with this option enabled.

Recomended Settings:

Automatic upgrade: on, although off is OK if you’re prepared to update manually.
Domain key: Make sure you have a domain key, request one if you don’t.
Guest mode: on (improves performance to a greater degree), although up to you.
Guest optimisation: on (optimisation is more aggressive), although up to you.
Server IP: Make sure the IP of the server your site is hosted on is listed here.
Notifications: Up to you, leave on if you want to receive notifcations fromthe Litespeed cache plugin

Litespeed Cache – Cache

The Cache page of the Litespeed Cache plugin shows the cache specific settings. As you can see this page has quite a few tabs on it, and each contains respective settings.

Cache (page) – Cache (tab)

The cache tab is used to control general cache settings.

Enable Cache.

You’ll need to turn this on. The Litespeed cache plugin isn’t doing any caching if this is turned off.

Cache Logged-in Users.

If your site allows users to log in, have this turned on. I have this turned off on my site because I’m the only person who logs in to it. If you don’t provide the ability for users to log in to your site, you’d be best to have this turned off.

Cache Commenters.

If you allow comments on your site you’d be best to have this turned on. I’ve got my comments disabled so there’s no point in me having this turned on. The same applies to your site if you don’t have comments enabled.

If you have Cache Commenters turned on, when a comment is submitted on a post, if moderation is not enabled, the comment is published immediately, and the page is purged from cache. Everyone (the commenter, and all future visitors to the page) will see the newly-published comment when the page reloads.

Cache REST API.

You’d be best to turn this on. A lot of plugins and themes use the REST API, including WordPress blocks. This setting enabled means that requests that are made by WordPress REST API calls are cached.

Cache Login Page.

This option caches the login page. There’s a worrying “Disabling this option may negatively affect performance” message next to this setting. Turn it on! Quick!

Cache favicon.ico.

This is kind of like a failsafe option. If your site is configured to use a favicon, and for some reason it goes missing, when it’s called this invokes WordPress’s 404 (not found) page. When the favicon.ico file is not found on your site, the WordPress backend will be invoked with each request, as it attempts to find the site favicon. Having this option enabled cache’s the 404 response, so avoids WordPress being invoked to serve the 404 response. It’s best to have this option enabled.

Cache PHP Resources.

This option will cache any PHP resources loaded by themes. Generally speaking, these are css or js resources loaded in PHP. In most cases, these are static outputs, so there is no reason to load PHP every time, so you’re best to have this option turned on UNLESS these resources are actually dnamic.

Cache Mobile.

This option enables you to cache separate versions of a page for mobile and desktop views. You only really need to have this option turned on if you’re using a non-responsive theme with a mobile-specific design, or if you’re serving different content on the mobile version of your site, or if you’re using AMP, the CCSS service or the UCSS service.

List of Mobile User Agents.

This list should be filled in with a rewrite-rule-friendly list of user agents. It is used in conjunction with the Cache Mobile setting and will be ignored if Cache Mobile set to off.

Private Cached URIs.

A list of path patterns that will be privately cached. These are paths that should never be publicly cached. You’ll only really need to use this for pages that you want to be cached privately (for logged in users) but not for general access (non-logged in visitors). You won’t generally need to use this as the “cache logged-in users” generates the private cache. You’d really only need to use this to tell Litespeed to never cache the URI for general access.

Force Cache URIs.

Paths containing the listed strings will be cached, regardless of any “non-cacheable” settings that may appear elsewhere. You can effectively use this to force the cache for specific URIs when you have some non-cacheable set elsewhere. This applies to both public and private URIs.

Force Public Cache URIs.

This is the same as the above, but for public URIs only, where as the above covers both private and public URI’s.

Drop Query String.

This setting allows you to specify the query strings that should be ignored by LSCache.

Some query strings, such as those that are used for marketing or analytics purposes, have no effect on the content that is displayed on the page. The page renders the same with and without these query strings. So it’s not necessary to store multiple copies of the page in the cache, and having this setting enabled stops pages with query strings being cached and served. You may need to add query strings here if the page content differs accoridng to the query string, or if the query string is required for other purposes.

Recomended Settings:

Enable cache: On.
Cache logged in users: Off (unless your site allows users to log in, in which case turn this on).
Cache Commenters: Off (whilst this can be helpful, a lot of comments will consume a lot of resources with this set to on).
Cache REST API: On (a lot of plugins and themes use the REST API).
Cache Login Page: On (this being off can consume resources as login pages are often targetted by bots).
Cache favicon.ico: On (this is in the tab on all your site’s pages, so best to cache).
Cache PHP Resources: On (only turn this off if your site’s PHP generates dynamic CSS or JS).
Cache Mobile: On if using Guest Mode and Guest Mode Optimisation (can consume resources).
Cache URIs: Usually not needed
Drop Query String: Usually you don’t need to add anything here unless query strings are used in somethign like marketing campaigns, in which case add them as required.

Cache (page) – TTL (tab)

The settings on the TTL tab are effectively used to define how long caches should last for before being expired.

Default Public Cache TTL.

This TTL setting controls most of the pages. All the other TTLs are for specific pages/types of pages. The TTL value is defined in seconds (3600 = 1 hour, 86400 = 1 day, 604800 = 1 week). It’s beneficial to have a longer TTL so that your cache lasts for longer. You can use the purge options to define that a cache should be purged when an update to a post or a page is made (more on that later).

Default Private Cache TTL.

This setting determines how long private pages are cached. The same applies with regard to the TTL length in the paragraph above.

Default Front Page TTL.

This setting determines how long the front page should be cached. The same applies with regard to the TTL length in the paragraph above.

Default Feed TTL.

This setting defines how long the feed should be cached. Again, same applies with regard to the TTL length in the paragraph above. Caching the feed is a good idea, as not doing so can result in CPU load. Cached feed pages are purged on update and on comment, so they are guaranteed to remain up to date.

Default REST TTL.

This TTL setting controls how long calls to the REST API are cached. Again, same applies with regard to the TTL length in the paragraph above.

Default HTTP Status Code Page TTL.

This TTL controls the pages that return 404, 403, 500, or whatever status codes you specify. Again, same applies with regard to the TTL length in the paragraph above.

Recomended Settings:

You shouldn’t need to change anything here. It’s only if your site is regularly updated by contributors that you might need to reduce TTL values to ensure fresh content is served.

Cache (page) – Purge (tab).

The settings on the purge tab are used to define when the cache should be purged (emptied).

Purge All On Upgrade.

If this setting is enabled, the cache will automatically purge when any plugin, theme or the WordPress core is updated. It’s a good idea to have this enabled so that you don’t see cached pages as soon as an upgrade has been applied (so you can tell if the upgrade has caused an issue).

Auto Purge Rules For Publish/Update.

When a post is published or updated, the post page is not the only one that changes. Category listings, tag listings. the blog’s front page, and a variety of archives may all also change. This section allows you to define what should be purged when an update to a post or page is made, according to what else should also be updated when an update to a post or page is made. If you’re in any doubt selecting all will make sure that all cached pages are purged when any update is made, but this will result in more server load.

Serve Stale.

When enabled, this setting allows the most recently purged (stale) cached copy of a page to be served to a visitor if the updated cache copy is not yet generated. Whilst this does result in “better” caching and reduced page load times, it may result in old content being served. If you’d prefer recent content to be served by default (although this will result in some cases where page load time is longer) have this disabled.

Scheduled Purge URLs.

The URLs here (one per line) will be purged automatically at the time set in the option “Scheduled Purge Time”.

Scheduled Purge Time.

This specifies the time at which the pages in the “Scheduled Purge URLs” section should be purged.

Purge All Hooks.

The Litespeed Cache plugin executes a “Purge All” action on the cache when certain WordPress hooks are run. You can change the purge behavior for your Litespeed Cache plugin installation by changing these hooks. The default settings should be OK here, but you can use this section to add additional hokks should you need to.

Recomended Settings:

Purge All On Auto Upgrade: On (this will purge the cache when updates are applied to ensure the update comes in to effect in reepctive areas on your pages).
Auto Purge Rules For Publish/Update: Leave as default if you can.
Serve Stale: Off (avoids serving old content from the cache).
Scheduled Purge URLs: You’ll only need to use this if you want your cache purged at a specific time (such as times of low traffic) and for specific pages.
Scheduled Purge Time: You’ll only need to use this if you’e added URLs to “Scheduled Purge URLs”.
Purge All Hooks: Default settings are fine here.

Cache (page) – Excludes (tab).

The excludes tab is used to define resources that shouldnt be cached.

Do Not Cache URIs.

By default, the Litespeed cache plugin caches as many pages as possible. If you have some pages that should not be cached for whatever reason, you can list the URIs here, one per line. Partial URIs are fine. Usually it’s best to leave this empty.

Do Not Cache Query Strings.

You can use this option to eliminate URLs with certain query strings from being cached. Usually it’s fine to leave this empty.

Do Not Cache Categories.

By default all categories are cached. If you have categories that you wish to exclude from the cache, enter a list of the category slugs (one per line) in this box. If you’d like all your category pages to be cached, leave this empty.

Do Not Cache Tags.

Tags are treated the same way as categories: cached by default, but ignored if entered by slug (one per line) in this box. Again, if you’d like all your tags cached, leave this empty.

Do Not Cache Cookies.

This is a list of cookies that should not be cached. Specifically, do not cache any page where a cookie in this list appears in the request headers. Leave this empty unless you need to not cache according to cookies.

Do Not Cache User Agents.

Specific user agents may also be excluded from cache. This means that if a visitor requests a page from your site via one of the listed user agents, they will not be served from the cache. You can enter user agents by name in this box, one per line if you need to, but it’s best to leave thsi empty unless you want to exclude specific user agents from being served cached content.

Do Not Cache Roles.

There may be user roles that you wish to exclude from caching. For example, if you are an admin, testing new functionality, you may want to exclude your administrator role from being served from cache until your testing is through. You can use this option to prevent caching for users logged in with certain roles. Leave this empty unless you really need to not cache according to role.

Recomended Settings:

You usually won’t need to do anything here unless you want to exclude parts of your site from the cache. You’d only need to do this if cahing is problematic, and exactly what you’d need to do depends on what the problem is.

If there is a problem, you’ll need to identify what it is that’s being cached whcih causes the problem, then exclude it using the settings on this page..

Cache (page) – ESI (tab).

ESI is Edge Side Includes. Unless you’re using edge side includes it’s best to leave this off, as the config can get complicated.

ESI allows you to designate parts of your dynamic page as separate fragments that are then assembled together to make the whole page. In other words, ESI lets you “punch holes” in a page, and then fill those holes with content that may be cached privately, cached publicly with its own TTL, or not cached at all.

ESI doesn’t come without a cost. It is much simpler for the server to return full pages than it is for it to piece together pages from several different blocks, and so this must be a factor in your decision to enable ESI. Will the speed benefits outweigh the efficiency hit? There’s no easy answer. It depends on your site. If you can avoid enabling this, leave it off.

Recomended Settings:

You shouldn’t need to do anything here, the defaults are fine.

Cache (page) – Object (tab).

This tab allows you to configure object caching. I’ve written a whole separate post about what object caching is and what it does.

If don’t really want to read the whole of that post, generally speaking you’re best to use Redis (it’s more powerful and it’s cache persists after reboots). You will need to have object caching available in your hosting to be able to use this (this is covered in the post linked to above).

Provided you have Redis object caching available:

Object Cache.

This needs to be turned on for the Litespeed cache plugin to make us or object caching.

Method.

If you have Redis available in your hosting set this to Redis. You’d only really need to use Memcached if you onlyhave Memcaced available in your hosting and not Reids.

Host.

Usually you’ll be able to use localhost or 127.0.0.1 but if this doesn’t work, you’ll need to contact your hosting provider and ask them for the object cachign server address.

Port.

If you’re using Redis the port is 6379, but if you’re using Memcached the port is 11211.

Default Object Lifetime.

This defines how long the cache of cached objects should last. 604800 is fine to use here, but you could set this to a lower value if you want caching but less chance osf stale objects… and nobody lieks a stale object.

Username.

You won’t need this unless using a private object caching server.

Password.

You won’t need this unless using a private object caching server.

Redis Database ID.

You can leave this set to 0 unless you run your own server, and have been setting up Redis yourself.

Global Groups.

This is a list of groups that should be cached at the network level. The default groups are fine to leave as they are.

Do Not Cache Groups.

Leave this as it is unless you want to exclude specific groups from the object cache.

Persistent Connection.

Turn this on, as it uses a keepalive to speed up object cache operations.

Cache WP-Admin.

This helps speed up the wp-admin area, so you might as well have this enabled.

Store Transients.

Turn this off if you have “cache wp-admin” turned on. When Cache WP Admin is set to OFF, transients have nowhere to go. Without transients, you don’t receive server status notices, so turnin this on to get the server notices.

Recomended Settings:

Assuming Redis is available in your hosting:

Object Cache: On
Method: Redis
Host: localhost (speak to your hosting provider if this doesn’t work)
Port: 6379
Default Object Lifetime: 360 – 86400
Username: Blank (speak to your hosting provider if this doesn’t work)
Password: Blank (speak to your hosting provider if this doesn’t work)
Redis database ID: 0 (unles managing multiple sites)
Global Groups: Leave as default
Do No Cache Groups: Leave as default (unless you want to exclude specific groups from the object cache).
Persistent Connection: On
Cache WP-Admin: On
Store Transients: Off (due to “Cache WP-Admin” being on).

Cache (page) – Browser (tab)

The browser cache is used to tell browsers how long they should cache static assets for. This helps with the “serve static assets with an efficient cache policy” flagged by pagespeed (and other tools).

Browser Cache.

Turn this on. You’d be silly not to.

Browser Cache TTL.

This defines how long browsers are told to cache static assets for. You’ll need to set this to 31557600 to keep conform to Google’s recommendations.

Recomended Settings:

Browser Cache: On (Google recommendation)
Browser Cache TTL: 31557600 (Google recommendation)

Cache (page) – Advanced (tab)

You shouldn’t need to change much here.

Login Cookie.

Leave this as it is, unless you have multipel WordPress installations and need the cache to be able to distinguish between who’s logged in to which one.

Improve HTTP/HTTPS Compatibility.

You’ll only need to turn this on if you’re using a mix of http and https, and seeing irregularities. It’s unlikely you’ll be operating in this manner.

Instant Click.

Turn this on. With this turned on when a visitor hovers over a page link, that page is preloaded which will speed up the visit to that link.

Recomended Settings:

Login Cookie: Leave blank (unless managing multiple WordPress installs and the cache needs to be able to distinguish between users).
Improve HTTP/HTTPS Compatibility: Off (you only need to turn this on if you’re mixing content between http and https)
Instant Click: On (improves preloading).

Litespeed Cache – CDN.

I’m not using a CDN in conjunction with the Litespeed Cache plugin.

When I first started using this plugin, I really wanted to see how much improvement in performance I’d see using the plugin alone. The performance benefit I’ve seen from using the Litespeed Cache plugin alone has negated the need to use a CDN.

This might not be the case for everyone. I’d undertaken a fair amount of upstream optimisation before I started using the Litespeed Cache plugin. If you haven’t undertaken any optimisation measures, then you might need a CDN to improve performance to a greater degree.

If you do decide to use a CDN, how you’d configure the CDN section of the Litespeed Cache plugin can vary according to the CDN you’ve chosen to use.

If you don’t want to use a CDN, then you can skip the CDN section of the Litespeed Cache configuration.

CDN (page) – CDN Settings (tab).

This page is used to set up and configure a CDN to be used by your site.

QUIC.cloud CDN.

Turn this on if you want to use the QUIC.cloud CDN, that’s all you need to do with this setting.

Use CDN Mapping.

This section allows you to specify multiple CDN paths for your content. If you only use one CDN, you’ll only need to fill out the first box. If you have more than one path (images served from one CDN, and JavaScript/CSS served from another CDN), then you’ll need to fill out a box for each path.

CDN URL.

This is the base URL for content that is served from this CDN. This needs to be a full URL.

Include Images.

Turn this on to serve all images through this CDN.

Include CSS.

Turn this on if you want CSS to be served by the CDN.

Include JS.

Turn this on if you want JS (JavaScript) to be served by the CDN.

Include File Types.

You can use this list to specify the extenstions of additional files that should be served from the CDN (one per line).

Original URLs.

This setting defaults to your site’s base URL, and you shouldn’t need to change this.

Included Directories.

These are the directories that will be served by the CDN. You shouldn’t need to change this (unless you’ve deliberately changed the names of the wp-content and wp-includes directories).

Exclude Path.

You can use this option to list file paths that you don’t want to be served from the CDN. You can use this option to exclude files from being saved by the CDN. You can list a path in its entirety, or use a partial path that will be matched, you can’t use wildcards, and you need to list one path per line.

Cloudflare API.

Cloudflare isn’t like other CDNs. You shouldn’t set “Use CDN Mapping” to “on” for Cloudflare. That said, you can manage your Cloudflare cache through the Litespeed Cache plugin, if you want to. All you’d need to do it set Cloudflare API to “on” and then fill in the three fields below. Once these settings are saved, you will be able to manage your Cloudflare cache through the LiteSpeed Cache > CDN > Manage area.

Email Address.

Enter the email address of your Cloudflare account.

Global API Key.

Enter the API key you were given by Cloudflare (or obtain it from your Cloudflare profile).

Domain.

Enter the domain name served by Cloudflare.

Recomended Settings:

This will vary according to whether you want to use a CDN or not, and which type of CDN if you do, please refer to the above.

CDN (page) – Auto QUIC.cloud Setup (tab).

This setup wizard can be used to setup and configured the QUIC.cloud CDN with your site.

The Litespeed Cache plugin provides a simple three-step process for getting started with QUIC.cloud CDN.

If you haven’t set up QUIC.cloud CDN or any of QUIC.cloud’s Online Services for your domain, this section will show a “Link to QUIC.cloud” button.

If you already have a QUIC.cloud domain key for this site, then the button will say Begin QUIC.cloud CDN Setup instead.

Press the button (whatever it says) to add your site to a new or existing QUIC.cloud account.

Linking your domain to QUIC.cloud isan automatic process, when this succeeds you’ll be redirected back to this Litespeed Cache page. You’ll notice that the button has been replaced with a status of “Ready to run CDN setup”.

CDN Setup Status.

Once your domain has been linked to QUIC.cloud, the Run CDN Setup button will be displayed. Click the Run CDN Setup button to continue.

The “CDN setup status” should change to “In Progress” and the button should now say “Refresh CDN Setup Status”. You’ll receive an email from QUIC.cloud when setup is complete, or you can press the “Refresh CDN Setup Status” button for an update.

If there are any errors during this process, the “CDN setup status” will change to “Paused”, and the error will be listed below the status. If the error is something you can fix yourself, go ahead and fix it, then press “Run CDN Setup” button again.

If you can’t fix the error, you’d need to contact QUIC.cloud support.

Nameserver detection.

This part of the setup wizard will detect the nameservers set against your domain. You’ll need to set the nameservers displayed in the “nameservers” section of the above against your domain. You’ll need to do this manually with the party that holds your domain registration.

Once the QUIC.cloud nameservers are detected at your domain registrar, the setup will be marked as Done. In real world terms, this may take 24 to 48 hours to actually come in to effect due to DNS propagation:

Once the above has completed the “Set up QUIC.cloud Account” section will have two new links: Manage CDN and Manage DNS Zone. These will each take you to your QUIC.cloud Dashboard to manage the CDN and DNS settings.

At this point you’ve set up the CDN. The only thing to be aware of is that it can take some time (around 20 minutes) to install a certificate and your site might show warnings about insecure content until the certificate has been installed.

CDN (page) – Manage (tab).

The Litespeed Cache plugin provides a mechanism to manage certain external CDN accounts, which eliminates the need for an extra plugin.

QUIC.cloud.

If you’re using QUIC.cloud CDN, you can find all of the management tools on your QUIC.cloud dashboard which you can access by clicking the https://my.quic.cloud link in the screen shot below.

Cloudflare.

Before you can use the functions in this section, you will need to set up the Cloudflare API in the settings. To do this navigate to:
LiteSpeed Cache > Settings > CDN and set Cloudflare API to ON.

Cloudflare Domain.

This is just for information, it’s not a setting and you can’t change it.

Cloudflare Zone.

This is the unique id that was assigned to your domain by Cloudflare. This is just for information, it’s not a setting and you can’t change it.

Development Mode.

These buttons allow you to turn development mode on and off. You might want to turn on development mode to see your site updates in realtime, to be able to check everything functions as you want it to.

Development mode turns itself off automatically, after 3 hours.

Cloudflare Cache.

You can use the “purge everything” button to completely clear the cache at Cloudflare. This is helpful if you have made changes that result in an Litespeed Cache plugin purge, and you want to make sure Cloudflare is up to date.

Image Optimisation.

Litespeed Cache plugin has the ability to optimise your site’s images, making them smaller, and faster to transmit. This helps with “Serve images in next-gen formats” as flagged by tools such as https://pagespeed.web.dev/ .

You could choose to manually press a button to optimise each new batch of images, or configure it to do this automatically.

All of Litespeed’s online services (including Image Optimisation), are hosted at QUIC.cloud. You don’t need to have a QUIC.cloud account if you don’t want one, but you do need a Domain Key to use Image Optimisation with your domain. You can get a Domain Key in the plugin’s General section.

By default QUIC.cloud optimise your JPG/PNG images. They don’t create WebP versions of each image, unless you enable that behaviour. You may also choose to only create WebPs and forgo the JPG optimisation. This is covered in more depth in the Image Optimisation (tab) section below.

Image Optimisation (page) – Image Optmisation Summary (tab)

This page is primarily used to send optimisation requests and to check the status of optimisation requests.

You can click on “Send Optimization Request” to start the image optimisation process. Before you do this, you’ll need to make sure that the “Image Optimization Settings” section has been configured according to your preference.

Only one small group of images is sent the first time you click “send optimisation request”. QUIC.cloud want to make sure everything is working well between your server and theirs, so they start with a small batch of images. You don’t need to wait on this page. You can just let it run and go and put the kettle on if you like.

Once the first group of images has finished being optimised and have been pulled back to your site (automatically through the cron, or manually by pressing the Pull Images button), Litespeed will slowly start sending larger groups of images. You have to press “Send Optimization Request” again to send the second batch.

The status messages will update, letting you know how many images were requested for optimisation, how many were pulled back to your site, and if there were any problems.

When images are ready to pull, you can press the “Pull Images” button to initiate the image pull process manually.

After a few batches, you will see the batch sizes have reached 200 images.

You can automate this process. You’ll need to make sure that your system cron is working. Then, under the Optimization Settings tab, set Auto Request Cron to ON and set Auto Pull Cron to ON. Save your settings, and then let your site’s images optimise and pull in the background.

Image Optimisation (page) – Image Optmisation Settings (tab)

This page is used to configure how Litespeed will optimise your site’s images.

Auto Request Cron.

Auto Request Cron being set to “on” means that image optimisation requests will be sent as a timed job (a cron job), in an automatic manner.

Auto Pull Cron.

Auto Pull Cron being set to “on” means that images that have been optimised at QUIC.cloud will be pulled to your site as a timed job (a cron job), in an automatic manner. If you have this set to off, you’ll need to manually initiate the pull of optimised images.

Optimize Original Images.

When Image Optimization is run, JPG and PNG images will be optimised, and backups saved. So if the image image.jpg can be optimised a copy of it is saved in image.bk.jpg, and the newly optimised version is saved back into image.jpg. Turn this option off, if you do not want optimised JPG and PNG files.

Remove Original Backups.

Be careful with this, it’s not reversable.

When this option is on, Image Optimization automatically deletes your original images after it has fetched the optimised versions. You will be unable to Revert Optimization if the backups are deleted.

Optimize Losslessly.

Optimising losslessly results in higher quality images, but they’re larger in size so contribute to page weight (the size of pages in KB or MB) to a greater degree.

Preserve EXIF/XMP data.

EXIF or XMP data contains data about the image itself. This can vary from the geographical coordinates for where the image was taken, the equipement used to take the data, and also things like copyright information. Because this information takes up space, turning this on results in greater image sizes.

Image WebP Replacement.

If you want to have WebP versions of your images created, enable Image WebP Replacement. Having this enabled will help with “Serve images in next-gen formats” issues flagged by reporting tools.

Image WebP Replacement.

Turning this on does 2 things:

1. For all future requests, Image Optimization will generate images in the WebP format in addition to optimizing the original images.
2. Litespeed will serve .webp images in place of .jpg or .png to browsers where it is supported.

This is effectively a master switch. You can control the use of WebP on an individual image basis in the Media > Library section of your WordPress. You will see a WebP optm/non-optm toggle link in this section to allow you to control whether WebP versions of specific images are served or not.

Recomended Settings:

Auto Request Cron: On
Auto Pull Cron: On
Optimize Original Images: On
Remove Original Backups: Off (although you can turn this on to save space if you’re happy with the image optimisation).
Optimize Losslessly: On (better quality)
Preserve EXIF/XMP data: Off (saves space)
Image WebP Replacement: On (addresses “serve images in next-gne formats”).
WebP Attribute To Replace: Leave as default
WebP For Extra srcset: On (ensures images served in custom code are WebP).
WordPress Image Quality Control: 80-90

Page Optimisation.

The Page Optimisation section is used to optimise your page output when using the Litespeed Cache plugin.

After changing any of the settings under the “CSS Settings” or “JS Settings” it’s advisable to check your site is functioning as expected, and displaying as it should.

Page Optimisation (page) – CSS settings (tab).

This page is used to control how the Litespeed cache plugin will optimise CSS on your site’s pages.

CSS Minify.

Turning this on minfies your CSS (removes comments and whitepace) to reduce the size of CSS files, it’s a good idea to have this turned on.

CSS Combine.

This combines multiple CSS files in to a singular file. It’s a good idea to enable this if you can.

Generate UCSS.

Unique CSS (UCSS) is a QUIC.cloud service that can be used along with the CSS Combine setting, to create a single slimmed down version of a CSS file for each page of your site. Each UCSS file is page specific and only contains the CSS required to render the respective page, which can make CSS files smaller in size. It’s a good idea to enable this option if you can.

UCSS Inline.

This inlines the UCSS file genrated when using UCSS. What this does is put the CSS in the HTML of a page, rather than calling it as separate file. This can help reduce the chance of CSS being render blocking, but it might not completely eliminate render blocking CSS. Enable this option if you can.

CSS Combine External and Inline.

By default, the CSS Combine option only combines local CSS files. With the “CSS Combine External and Inline” option turned on, external CSS files, and CSS that is found inline with the HTML will also be included in the combined file. Including all possible CSS in this manner, helps to maintain the priorities of CSS, which should help to minimise potential errors caused by CSS Combine. Enable this option if you can.

Load CSS Asynchronously.

This option defaults to “off”. When it is “off”, web pages load the normal way (the browser loads the CSS from the HTML header before continuing on to display the content in the HTML body). If you turn this option on, CSS and HTML will be loaded at the same time, which can result in pages looking faster, but they may initially load without formatting. To avoid this formatting problem, Litespeed automatically generates Critical CSS when Load CSS Asynchronously is set to “on”. Enable this option if you can.

CSS Per URL.

This option defaults to “on”. Set this option to “off” to generate Critical CSS per Post Type instead of per individual page. This can save significant CCSS quota and disk space, but it can result in incorrect CSS styling if your site uses a page builder.

Inline CSS Async Lib.

This option being enabled will inline the asynchronous CSS, which can help with render blockign CSS. Turn this on if you can.

Font Display Optimization.

Set this to swap and it will add swap to the font-display directive for all @font-face rules before caching CSS. This can help with “ensure text remains visibile during web font load”, so set this to swap if you can.

Recomended Settings:

CSS Minify: On (although maybe disable if your site breaks, you’ll need to exclude something to be able to turn this on and your site not break).
CSS Combine: On (although maybe disable if you have large CSS fils or your site breaks, you’ll need to exclude something to be able to turn this on and your site not break).
Generate UCSS: Off (only use if CSS Combine is turned on, advisable to tuen on cache mobile if you turn this on).
UCSS Inline: Off (so that it doesn’t increase HTML size, maybe turn on if you have small CSS).
CSS Combine External and Inline: Off (but on if Combine CSS is on).Load CSS Asynchronously: On if you can (check your site is OK if on).
CCSS Per URL: Off (unless you have page specific individual CSS).
Inline CSS Async Lib: On if you can (helps with render blocking CSS), but you may have flash of unformatted text when on.

Page Optimisation (page) – JS settings (tab).

This page is used to control how the Litespeed cache plugin will optimise JS (JavaScript) on your site’s pages.

JS Minify.

Turning this on minfies your JS (removes comments and whitepace) to reduce the size of JS files, it’s a good idea to have this turned on.

JS Combine.

This combines multiple JS files in to a singular file. It’s a good idea to enable this if you can.

JS Combine External and Inline.

Turn this option on to include external JavaScript and inline JavaScript in the combined file (when JS Combine is also enabled). This option helps to maintain the priorities of JS execution, which should help reduce potential errors caused by JS Combine.

Load JS Deferred.

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

• Deferred runs the JS as soon as the HTML has 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).

You’ll need to use Deferred if your site’s JS does anything specific to formatting, rather than user interaction alone.

Recomended Settings:

JS Minify: On (reduces size of JS files).
JS Combine: Off (especially if you have large JS files of use HTTP2).
JS Combine External and Inline: Off (only enable if JS Combine is on)
Load JS Deferred: Delayed (if possible, you may need to defer if delayed causes issues with your site, or disbabel completely).

Page Optimisation (page) – HTML settings (tab).

This page is used to control how the Litespeed cache plugin will optimise the HTML of your site’s pages.

HTML Minify.

Turning this on minfies your HTML (removes comments and whitepace) to reduce the size of HTML files, it’s a good idea to have this turned on.

DNS Prefetch.

You can use this setting to prefetch DNS for external resources. This reduces the overhead of DNS lookups for resources you’re linking to that are external to your site. You’d enter the domains of the external resources (one per line) to prefetch them. Enabling this reduces latency, which is more common on mobile networks.

DNS Prefetch Control.

This is like a global on switch used to prefetch all URLs in site pages. Turning this on can reduce page load times.

DNS Preconnect.

This is a bit like prefetch but it goes further than prefetch by performing the connection handshake with the sites specified in the list (one per line).

HTML Lazy Load Selectors.

You can use this option to choose to lazy load any HTML content by its selector (generally an id or class). List selectors one per line.

Remove Query Strings.

This setting strips the query string from static resources. Static resources with query strings are usually not cached by browsers, so removing the query strings allows them to be cached, which results in faster page load.

Load Google Fonts Asynchronously.

You might not want to enable asynchronous loading for all of your CSS, but if you want to do this for JUST the Google Fonts, you can enable this setting. When enabled, Google Fonts are loaded asynchronously without all the other CSS loading asynchronously. This option also implements a preconnect to Google.

Remove Google Fonts.

This does what it says, it removes Google fonts from your site. if you enable this option test your site to make sure it functions and displays as intended.

Remove WordPress Emoji.

If enabled, this setting removes the extra JavaScript file that is used to add support for emojis in older browsers. Visitors using modern browsers that have their own native emoji support won’t see a difference. Enabling this setting effectively means that visitors using older browsers won’t see emojis.

Remove Noscript Tags.

<noscript> tags are used for compatibility with older browsers that don’t support JavaScript, or modern browsers where JS is turned off for security reasons. They give the browser instructions for what to do if it can’t run the associated script. While that’s nice and helpful, these tags do take up space.

With this option enabled, <noscript> tags are removed, resulting in a smaller page size, but less compatibility for browsers with no functioning JavaScript. You will need to decide for yourself whether the efficiency gains are worth the compatibility losses.

Recomended Settings:

HTML Minify: On (reduces the size of your HTML).
DNS Prefetch: List URLs of external resources here (such as https://maps.google.com). This helps reduce the impact of 3rd party code.
DNS Prefetch Control: On (if listing URLs above).
DNS Preconnect: List URLs of external resources here (such as https://maps.google.com). This helps reduce the impact of 3rd party code.
HTML Lazy Load Selectors: Enter selectors you want to lazy load here. This is similar to lazy loading images but for any below the fold elements.
Remove Query Strings: On (unless required for a specific purpose).
Load Google Fonts Asynchronously: On (if using Google fonts). This will use the Web Font Loader library to load Google Fonts asynchronously while leaving other CSS intact. This will also add a preconnect to Google Fonts to establish a connection earlier.
Remove Google Fonts: Off (unless using local fonts).
Remove WordPress Emoji: On (reduces load times)
Remove Noscript Tags: Reduces size, but also reduces JavaScript support for older browsers, or browsers with JavaScript disabled. Leave off if you’re concerned about older browsers being used to access your site.

Page Optimisation (page) – Media Settings (tab).

This page is used to control how the Litespeed cache plugin will optimise images on your site’s pages.

Lazy Load Images.

When enabled, this setting only loads the images once they are visible in the viewport (the screen of the device). The remaining images are only loaded as and when they appear on screen by the visitor scrolling down a page. When you turn this option one, the WordPress core Lazy Load feature is automatically disabled.

Basic Image Placeholder.

You can use this to specify a placeholder image that’s displayed until the true actual image has finished loading.

When Lazy Load Images is enabled, a grey box is displayed as a placeholder until an image can be loaded. You can use the Basic Placeholder Image to define what should be displayed instead of the grey box.

Responsive Placeholder.

Responsive image placeholders can be used in cases where the width and height attributes for the images are set. Placeholders are generated with the same dimensions as the images, which helps to reduce layout shift.

Responsive Placeholder SVG.

If generating a placeholder locally, you can use this option to specify an SVG to be used, and it will be converted to a base64 placeholder on the fly.

Responsive Placeholder Color.

You can use this to set the colour of a placeholder (instead of grey, select another colour).

LQIP Cloud Generator.

LQIP is Low Quality Impage Placeholder. This is a QUIC.cloud service that lets you generate a unique placeholder, which is a blurred and minified version of the original high-quality image to be loaded.

LQIP Quality.

This is related to the LQIP Cloud Generator setting above, and it allows you to specify the quality of the LQIP Cloud generated image. Higher quality results in larger sizes, so be a bit careful with this one.

LQIP Minimum Dimensions.

Again this is related to the LQIP Cloud Generator setting above. You can use this to specify the dimensions (in pixels) of the smallest files you wish to be sent for LQIP requests.

Generate LQIP In Background.

The first time a page is visited, the LQIPs are be generated. If this setting is on, the generation will be done in the background via a cron-based queue in advance of the page being visited.

Lazy Load iframes.

This option being enabled makes iframes load when they’re scrolled to, rather that being loaded when the page is requested. Turning this on is advisable if your site’s pages uses iframes.

Add Missing Sizes.

Turning this option on makes the Litespeed cache plugin to automatically add the width and height to any image where the attributes are missing. This helps reduce layout shift if you haven’t defined height and width values for your images. It can also help with the “images don’t have explicit hieght and width” issue flagged by reporting tools. Turning this on is adviseable.

Recomended Settings:

Lazy Load Images: On.
Basic Image Placeholder: Up to you (used to define custom image placeholder while images load).
Responsive Placeholder: On if using Basic Image Placeholder.
Responsive Placeholder SVG: Up to you.
Responsive Placeholder Color: Up to you.
LQIP Cloud Generator: On if using Basic Image Placeholder.
LQIP Quality: According to your preference.
LQIP Minimum Dimensions: 150×150 is fine here.
Generate LQIP In Background: On if usien LQIP Cloud Generator.
Lazy Load Iframes: On
Add Missing Sizes: On (helps with images to not have explicit height and width).

Page Optimisation (page) – VPI (tab).

VPI means “Viewport Images”. This is a service that allows you to exclude above the fold images from lazy loading.

For each post URL submitted to the queue, QUIC.cloud detects which images in the post would be visible in the viewport on post load. These images are referred to as Viewport Images (or VPI), and LiteSpeed Cache will load them along with the page.

VPI images will not be lazy loaded, but all of the other below the fold images for the URL will still be lazy loaded.

Viewport Images.

Turn this setting on to use the QUIC.cloud VPI service. Viewport Images are generated automatically in the background on QUIC.cloud servers so as not to impact your site.

Viewport Images Cron.

When Viewport Images is enabled and this setting is set to on, the Viewport Images will be generated in the background via a cron-based queue. If left off, you can manually submit any URLs waiting to be processed. A Run VPI Queue Manually button will appear when there are queued URLs waiting.

Recomended Settings:

Viewport Images: On
Viewport Images Cron: On

Page Optimisation (page) – Media Excludes (tab).

This page is used to exclude images, and other resources from Lazy Loading (and excluded image or resource will be loaded regardless of where the image is on the page and what’s displayed on the visitors screen).

If you want all content to be lazy loaded, you don’t need to configure anything on this tab.

Lazy Load Image Excludes.

If you want images to load immediatel regardless of where the image is on the page and what’s displayed on the visitors screen you can list them here. Both full URLs and partial strings can be used. One per line.

Lazy Load Image Class Name Exclude.

Images containing the class names you enter here will not be lazy loaded. Both full and partial strings can be used. One per line.

Lazy Load Image Parent Class Name Excludes.

Images whose parents contain the class names you enter here will not be lazy loaded. Both full and partial strings can be used. One per line.

Lazy Load iframe Class Name Excludes.

Iframes containing the class names you enter here will not be lazy loaded. Both full and partial strings can be used. One per line.

Lazy Load iframe Parent Class Name Excludes.

Iframes whose parents contain the class names you enter here will not be lazy loaded. Both full and partial strings can be used. One per line.

Lazy Load URI Excludes.

Images and iframes on the pages listed here will not be lazy loaded. One URI per line. Partial strings may be used.

LQIP Excludes.

Images listed here will not be included when generating Low Quality Image Placeholders. Images can be added one per line, and partial strings are allowed.

Recomended Settings:

This will depend on whether you want to exlude anything from being lazy loaded, and if you do, what that is. Please refer to the above.

Page Optimisation (page) – Localization (tab).

The localization tab can be used to locally cache and serve resources that would normally be called from an external source. The settings on this tab can be used to minimise the overhead of 3rd party code, and it can also help (in some cases) with unused JavaScript.

Gravatar Cache.

Gravatars (Globally Recognized Avatars) can be cached locally, if this is set to on. This is a good setting to enable if you allow comments on your posts with gravatars displayed.

Gravatar Cache Cron.

Turn this on to refresh the Gravatar cache using a cron job.

Gravatar Cache TTL.

This setting defines how long (in seconds) Gravatars should be cached.

Localize Resources.

You might want to turn this on if a page score site is suggesting optimisations to JavaScript and other resources that are hosted on domains external to your site, such as Google or Facebook. You have no control over external resources, so you can’t optimise them. Set Localize Resources to on, and the resources will be copied to your local system, where they may be optimised as necessary.

Use the Localization Files field to specify which resources you would like to localise.

Localization Files.

This option allows you to use local copies of external JavaScript resources. Enter a URL, and it will be localised. A list of Recommended URLs is provided by default, but you can choose to localise whatever external resources you like.

Recomended Settings:

Gravatar Cache: On (especially if you have comments enabled).
Gravatar Cache Cron: On (especially if you have comments enabled).
Gravatar Cache TTL: 604800 is fine here.
Localize Resources: On (if your site calls any external resources).
Localization Files: You’ll need to list the external resource files here if you have Localize Resources on.

Page Optimisation (page) – Tuning (tab).

You’ll only really need to use this tab if other page optimisation settings break your site or cause it to display of behave in an undesirable manner.

You’d effectively use the tuning page to define resources that shouldn’t be optimised as per the other page optimisation settings you’ve set in other tabs of the Page Optimisation page.

JS Delayed Includes.

You can listed JS files or partial strings here to ensure those JS files will always be delayed.

JS Excludes.

Use this to list the full URLs or a partial strings of JS files that you’d like to exclude from minfying and combining (as set under the JS tab).

JS Deferred/Delayed Excludes.

Use this to list the full URLs or a partial strings of JS files that you’d like to exclude from delay and defer (as set under the JS tab).

Guest Mode JS Excludes.

Use this to list the full URLs or a partial strings of JS files that you’d like to exclude from guest mode optimisation.

URI Excludes.

Use this to list pages that you’d like to completely exclude from optimisation.

Optimize for Guest Only.

When this is turned on, CSS and JavaScript optimisations are performed for non-logged-in visitors only.

When this is turned off, optimisations are performed for all visitors, which means that each user role will have its own set of generated CSS and Javascript.

Role Excludes.

There may be user roles that you want to exclude from any sort of optimisation. If, for example, if you are an admin, testing new functionality, you might want to exclude your administrator role from optimisation until you’ve completed your testing.

Recomended Settings:

This will vary between sites, and how owners want them to work. Use this section to exclude/delay resources that you don’t want to be cached or optimised. You’ll only need to do this if caching breaks parts of your site.

Page Optimisation (page) – Tuning CSS (tab).

This tab is used to exclude CSS from optimisation. It’s like the Tunign tab mentioned above, but just for CSS.

You might need to use this tab to exclude certain CSS from optimisation if the options set under the CSS tab cause your site to appear in a manner it shouldn’t.

CSS Excludes.

Use this to exclude CSS files (one per line) from the minify and combine optimisations configured under the CSS tab.

UCSS File Excludes and Inline.

Use this to exclude CSS files (one per line) from the UCSS optimisation configured under the CSS tab.

UCSS Selector Allowlist.

There might be CSS selectors (generally ids or classes) that you will always want included in the calculated UCSS (Unique CSS). You can list the selectors in this setting, one per line.

UCSS URI Excludes.

Use this to exclude pages (one per line) from the UCSS optimisation configured under the CSS tab.

Separate CCSS Cache Post Types.

By default, one set of Critical CSS is saved for each post type. So that’s, one CCSS for Posts, one CCSS for Pages, another CCSS for Products (if you have a custom post type called “Product”).

If you have a post type where every item within that post type has different formatting, then one set of Critical CSS will not work for this post. You;ll have to add that post type to the box, and Critical CSS will be generated for each item of that post type.

Separate CCSS Cache URIs.

If you have pages that don’t follow the same formatting rules as the rest of their post type, you can list the URIs (or partial URIs) of those pages in this here. Separate critical CSS files will be generated for paths containing these strings.

Critical CSS Rules.

When Load CSS Asynchronously is enabled in the CSS Settings tab, critical CSS is generated automatically. You might want to single out a few additional definitions that must be loaded first in order to properly style above the- old content. Enter those rules here in plain CSS, just as they appear in your stylesheet. They will be appended to the generated CSS.

Recomended Settings:

This will vary between sites, and how owners want them to work. Use this section to exclude/delay resources that you don’t want to be cached or optimised. You’ll only need to do this if caching breaks parts of your site.

Database (page).

Database optimisation is a useful tool when it comes to speeding up your site. The Litespeed Check plugin’s database page gives you an easy way to execute some database optimisations.

It’s advisable to have a backup available and know how to restore it before optimising your site’s database, just in case there’s any adverse effect.

Database (page) – Manage (tab).

This page is used to optimise your site’s database.

Clean All.

Press this button to mass clean up everything all at once. Pressing this will carry out all of the listed cleanups, except for “Optimize Tables” and “Clean CSS/JS Optimizer”.

Post Revisions.

This cleans post revisions from the site’s database.

Pressing this will mean that you loose the ability to go into any of your post and restore previous versions of them. Only the currently published version of each post will be saved if you press this.

Auto Drafts.

Drafts are made as you write post content. It does this incase you loose your internet connection when updating your site. It’s a bit like an auto-save mechanism. Pressing this cleans the database of saved drafts.

Trashed Posts.

This deletes posts that you’ve trashed.

Spam Comments.

This option deletes comments marked as spam. There’s no need to keep these.

Trashed Comments.

This option permanently deletes comments that have been trashed.

Trackbacks & Pingbacks.

When other blogs link to you, it can create trackbacks or pingbacks. Some WordPress themes display these in the comments section. If displaying these external links is not important to you, press this button to clear them from the database.

Expired Transients.

Transients are the result of a form of caching that can happen in the your site’s database from the results of remote API calls. This option clears all of the expired transients from the database.

All Transients.

This option clears all of the transients in the database, whether expired or not. NOTE: It is normal for there to still be some transients left after cleaning. Transients are caused by plugins, and are regenerated every time you reload a page.

Optimize Tables.

This option optimises database tables. It’s bit like defragging a disk (remeber that?) but just for databases.

Clean CSS/JS Optimizer.

If you’re using the minify and/or combine functions for CSS and/or Javascript, you can clean up the related data with this button.

Database (page) – Manage (tab).

This page is used to manage how the database optimisation functions.

Revisions Max Number.

Use this to specify the mximum number of revisions to keep when cleaning up revisions.

Revisions Max Age.

Revisions newer than this many days will be kept when cleaning up revisions.

Recomended Settings:

Revisions Max Number: 10
Revisions Max Age: Up to you, 0 to not delete any 7 to keep 7 day’s worth of revisions.

Crawler.

The crawler has to be allowed by your hosting provider if you’re using shared hosting. You won’t be able to use this, unless it’s been allowed.

The idea of the cralwer is that it requests your sites pages to refresh the caches of any pages that have expired in the cache.

By doing this it reduces the chance of a site visitor trying to access a page that isn’t cached, as the cralwer is likely to have already requested that page, and it’s cache will have been refreshed when it did.

Crawler (page) – Summary (tab).

This page is primarily used to check the status of what’s been crawled on your site, and to request crawls.

You can use the summary page to see the status of what’s been crawled and what will be cralwed next.

Clicking the “manually run” button prompts the cralwer to carry out the next crawl (position 1) in the list. If you don’t click this the crawler will crawl site pages as per what’s defined in the “general settings” tab.

With regard to the colour key:

• Gray, Waiting to be Crawled: the page is in the queue to be crawled
• Green, Cache Hit: the page is already cached, so the crawler skipped it
• Blue, Cache Miss: the page was not already cached, so the crawler has cached it
• Red, Blocklisted: the page cannot be crawled (because the page is listed in the blocklist tab).

Crawler (page) – Map (tab).

This page is used to check crawl the status of pages on your site.

This page displays the URIs currently in the crawler map. If you don’t see any listed, try pressing the Refresh Crawler Map button:

The map tab is for informational purposes, and you can use it to see what’s been crawled and the status of crwaled pages.

The “add to blacklist” button can be clicked to stop the crawler from crawling specific pages.

A similar colour scheme applies:

• Green, Cache Hit: the page is already cached, so the crawler skipped it
• Blue, Cache Miss: the page was not already cached, so the crawler has cached it
• Orange: The page isn’t cacheable so it’s been added to the blocklist
• Red, Blocklisted: the page cannot be crawled (because the page is listed in the blocklist tab).

Crawler (page) – Blacklist (tab).

This page shows pages listed in the blacklist (pages you don’t want the cralwer to crawl).

All you can really do on this page is check the blacklist, or completely empty it by clicking “Empty blacklist”.

Crawler (page) – General Settings (tab).

This page is where you configure the cralwer’s behaviour.

Crawler.

You’ll need to set this to on for the crawler to crawl your site.

Delay.

Use this to add a delay between the crawls of individual pages. You’ll probably want to have some sort of delay to stop the crawler requesting a large amoutn of pages in a small space of time, as this can cause CPU load to rise. Adding a delay does mitigate this, but it also makes crawls of your whole site take longer.

Run Duration.

This can be used to limit how long a crawl run will run for. If this limit is reached, the crawler stops (for as long as the setting below is set), the starts again, picking up where it left off.

Interval Between Runs.

THis dictates how ling the crawler waits until restarting a run when the run duration (above) is reached.

Crawl Interval.

This dictates the interval between crawl runs independently of run duration and interval between runs. This effectively dictates how frequently your site is crawled.

The best way to figure this out is to run the crawler a couple of times and keep track of the elapsed time. Once you’ve got that amount, set Crawl Interval to slightly more than that. For example, if your crawler routinely takes 4 hours to complete a run, you could set the interval to 5 hours.

Threads.

This setting defines how many separate crawling processes can take place at the same time.

The higher the number, the faster your site is crawled, but also the more load that is put on your server.

Timeout.

The crawler has this many seconds to crawl a page before moving on to the next page.

Server Load Limit.

This dictates the highest the CPU load on the server can be for a crawl to be initiated. If you set the load to 3, when the CPU load on the server is more than 3, the crawler won’t run. You can use this to stop the crawler running at times when CPU load is high, as the crawler running when it is, would make the load even higher.

Recomended Settings:

Crawler: On (if permitted by your hosting provider)
Delay: 1000
Run Duration: 400 is OK here
Interval Between Runs: 180-300 (you might need to use a higher value if your site has a larger number of pages)
Crawl Interval: 302400 is OK here although reduce if you want your entire site to be crawled more frequently.
Threads: 3
Timeout: 60
CPU Load: 3 (setting this too high can cause CPU load issues – be nice to your hosting provider!)

Crawler (page) – Simulation (tab).

This page is used to simulate the cralwer for specific roles.

The crawler runs as a non-logged-in “guest” on your site. The pages that are cached by the crawler are all for non-logged-in users. If you would like to also pre-cache logged-in views, you can do so here.

The crawler simulates a user account when it runs, so you need to specify user id numbers that correspond to the roles you’d like to cache.

Crawler (page) – Sitemape settings (tab).

This page is used to tell the crawler the pages that your site is made of. It’s this that the crawler uses to establish what it shoudl crawl.

Custom Sitemap.

Use this field to specify the URL of your sitemap.

Drop Domain from Sitemap.

The crawler will parse the sitemap and save it into the database before crawling. When parsing the sitemap, dropping the domain can save on database storage.

Sitemap Timeout.

Specify a time limit for reading the sitemap here.

Toolbox.

The toolbox provides a suite of facilities that you can use to clear parts of the cache, import/export settings and provide reporting information.

Toolbox (page) – Purge (tab).

The purge tab is used to clear the cache, either as specific cache aspects or as a whole.

Purge Front Page.

Click this to clear the cache of your site’s front page/homepage.

Purge Pages.

Click this to clear the cache of your site’s front pages.

Purge Error Pages.

Click this to clear the cache of your site’s error pages.

Purge All – LSCache.

Clicking this button will purge all cache entries related to the current WordPress installation.

If you have the crawler running, the Purge All button will also purge any crawled pages and reset the sitemap.

Purge All – CSS/JS.

If you click this button all of the minified and combined JavaScript and CSS files that were cached as a result of the settings in the Page Optimisation section will be purged from the cache.

Purge All – Opcode Cache.

This button clears the opcode cache, not to be confused with LSCache, which is a separate thing. Opcode cache stores compiled PHP code, not complete pages.

Purge All – Critical CSS.

Clicking this button clears any Critical CSS generated through the QUIC.cloud CCSS service.

Purge All – Unique CSS.

Clicking this button clears any Unique CSS generated through the QUIC.cloud CCSS service.

Purge All – LQIP Cache.

This button can be clicked to clear any Low Quality Image Placeholders generated through the QUIC.cloud LQIP service.

Purge All.

Clicking this button purges everything except Critical CSS, Unique CSS, and LQIP. It purges everything that may be freely regenerated, but does not purge anything that would require you to pay QUIC.cloud credits to regenerate.

Empty Entire Cache.

This is one of those buttons that should only be used when you have a problem that can’t be solved any other way. Press it to purge all of the cache entries for the entire site, including those entries from other web applications.

Purge by…

This allows you to purge a list of pages. The available list types are: Category, Post ID, Tag, and URL. The list of the selected type should be entered one per line in the text area above the Purge List button.

Toolbox (page) – Import/Export (tab).

This page is used to export an entire Litespeed cache plugin configuration, and to import an entire Litespeed cache plugin configuration file. It can also be used to reset the entire configuration of the Litespeed cache plugin.

Toolbox (page) – View .htacces (tab).

This section allows you to view the site’s .htaccess tab, but this is for informational purposes only, as you can’t make any changes to the .htaccess file, only view it.

Toolbox (page) – Heartbeat (tab).

You can use this section to disable or adjust WordPress’ interval heartbeats to reduce server load. Be careful with this as changing these settings can cause WordPress tasks triggered by AJAX to stop working.

Frontend Heartbeat Control.

Turn this ON to use heartbeat control on the WordPress frontend.

Frontend Heartbeat TTL.

You can adjust the heartbeat interval using this setting. The “Frontened Heartbeat Control” option above needs to be on for this to work.

Backend Heartbeat Control.

Turn this ON to use heartbeat control in wp-admin.

Backend Heartbeat TTL.

You can adjust the heartbeat interval for the wp-admin area using this setting. The “Backend Heartbeat Control” option above needs to be on for this to work.

Editor Heartbeat.

Turn this ON to use the heartbeat control in the WordPress editor.

Editor Heartbeat TTL.

You can adjust the heartbeat interval for the wordpress editor using this setting. The “Editor Heartbeat Control” option above needs to be on for this to work.

Recomended Settings:

Frontend Heartbeat Control: On
Frontend Heartbeat TTL: Up to you, 0 to disable, 15-120 advisable.
Backend Heartbeat Control: On
Backend Heartbeat TTL: Up to you, 0 to disable, 15-120 advisable.
Editor Heartbeat: On
Editor Heartbeat TTL: Up to you, 0 to disable, 60-120 advisable.

Toolbox (page) – Report (tab).

This page is used to generate a report should you need support and it be required.

Toolbox (page) – Debug Settings (tab).

This page is primarily used when debugging problems.

Debug Helpers.

The “View Site Before Optimisation” button opens your site in a new tab with all optimisations turned off.

The “View Site Before Cache” button opens your site in a new tab without loading anything from the cache.

Disable All Features.

You can use this option if you need to debug your site. Turning this on will disable all caching and optimisation.

Debug Log.

This can be used to enable and disable the debug log. The log is written to wp-content/debug.log when this is turned on, and can be viewed in the LiteSpeed Cache > Toolbox > Log View tab.

Admin IPs.

You can add your IP address here, then browse to a page on your site using the LSCWP_CTRL and the front end cache of that page will be purged.

Debug Level.

This setting dictates the level of logging in the debug log, when the debug log is enabled.

Log File Size Limit.

You can use this to limit the size (in MB) of the debug log.

Log Cookies.

Log request cookie values.

Collapse Query Strings.

Shorten query strings in the debug log to improve readability.

Debug URI Includes.

You can use this to define specific URIs, and by doing so, the debug log will only contain information specific to the URI’s you’ve entered here.

Debug URI Excludes.

You can use this to define specific URIs, and by doing so, the debug log will only contain information THAT ISN’T specific to the URI’s you’ve entered here.

Debug String Excludes.

You can enter query strings here to prevent the debug log containing entries for the respective query strings.

Toolbox (page) – Log View (tab).

The buttons on this tab can be used to view different types of logs, and also to clear the log files.

Toolbox (page) – Beta Test (tab).

You can use this area to try versions of the Litespeed Cache plugin that haven’t yet been released to the public.

Unless you’re an advanced user and are willing to debug and use your site in an experimental manner, you’d be best not to use beta versions.