Suppressing Non-Critical Banners

Sometimes the LiteSpeed Cache plugin for WordPress adds informational banners to your WordPress Dashboard, such as this one:


These banners are meant to be informational, but they are not critical to the functioning of the plugin. As of LSCWP v3.0, these banners are opt-in only, meaning by default, such non-critical banners will not be displayed. If you would like to opt in to seeing LiteSpeed news (hotfixes, new releases, available beta versions, promotions, etc.) displayed on your dashboard, navigate to LiteSpeed Cache > General > General Settings and set Notifications to ON.


This setting does not suppress notifications such as Purged all caches successfully. and other messages related to the functioning of the plugin.

Admin IP Commands

The following commands are available to the admin and do not require log-in, providing quick access to actions on the various pages:

  • NOCACHE - This is used to display a page without caching it. An example use case is to compare a cached version of a page with an uncached version.
  • PURGE - This is used to purge most cache tags associated with the page. The lone exception is the blog ID tag. Note that this means that pages with the same cache tag will be purged as well.
  • PURGESINGLE - This is used to purge the first cache tag associated with the page.
  • SHOWHEADERS - This is used to show all the cache headers associated with a page. This may be useful for debugging purposes.
  • before_optm - Use this parameter to view a page without any of the optimizations enabled.

To trigger the action for a page, access the page with the query string ?LSCWP_CTRL=ACTION.



Actions are case-sensitive.

WordPress CLI

This documentation has moved to it's own page. Please see WordPress CLI.

Using a Default Configuration

The const.default.ini file contains the default configuration for LSCWP. It can be used, for example by hosting providers, to change the default settings for the plugin. The file is located in the /wp-content/litespeed-cache/data folder.

As of v3.3 of our WHM plugin, hosting providers can use a custom const.default.ini file when enabling or mass enabling LSCWP by placing the file under the /usr/src/litespeed-wp-plugin directory. This file will then be used for all sites installing a new copy of LSCWP.

Changes to const.default.ini do not prevent users from changing their plugin settings.

Default values

This is the standard const.default.ini file, as shipped in LSCWP.

; This is the default LSCWP configuration file
; All keys and values please refer const.cls.php
; Here just list some examples
; Comments start with `;`

purge_upgrade = true

cache_priv = true

cache_commenter = true

cache_object_host = 'localhost'
cache_object_port = '11211'

cache_browser_ttl = 2592000

public_ttl = 604800

Available values

public_ttl Default Public Cache TTL Text or numeric value
private_ttl Default Private Cache TTL Text or numeric value
front_page_ttl Default Front Page TTL Text or numeric value
feed_ttl Default Feed TTL Text or numeric value
404_ttl Default 404 Page TTL Text or numeric value
403_ttl Default 403 Page TTL Text or numeric value
500_ttl Default 500 Page TTL Text or numeric value
cache_priv Cache Logged-in Users True or false
cache_commenter Cache Commenters True or false
cache_rest Cache REST API True or false
cache_page_login Cache Login Page True or false
cache_favicon Cache favicon.ico True or false
cache_resources Cache PHP Resources True or false
mobileview_enabled Cache Mobile True or false
mobileview_rules List of Mobile User Agents Text or numeric value
litespeed-cache_uri_priv Private Cached URIs Text or numeric value
litespeed-cache-drop_qs Drop Query String Text or numeric value
purge_upgrade Purge All On Upgrade True or false
timed_urls Scheduled Purge URLs Text or numeric value
timed_urls_time Scheduled Purge Time Text or numeric value
litespeed-forced_cache_uri Force Cache URIs Text or numeric value
litespeed-excludes_uri Do Not Cache URIs Text or numeric value
excludes_qs Do Not Cache Query Strings Text or numeric value
excludes_cat Do Not Cache Categories Text or numeric value
excludes_tag Do Not Cache Tags Text or numeric value
nocache_cookies Do Not Cache Cookies Text or numeric value
nocache_useragents Do Not Cache User Agents Text or numeric value
css_minify CSS Minify True or false
css_combine CSS Combine True or false
css_http2 CSS HTTP/2 Push True or false
js_minify JS Minify True or false
js_combine JS Combine True or false
js_http2 JS HTTP/2 Push True or false
optimize_ttl CSS/JS Cache TTL Text or numeric value
html_minify HTML Minify True or false
css_inline_minify Inline CSS Minify True or false
js_inline_minify Inline JS Minify True or false
optm_css_async Load CSS Asynchronously True or false
optm_ccss_gen Generate Critical CSS True or false
optm_ccss_async Generate Critical CSS In Background True or false
litespeed-optm-ccss-separate_posttype Separate CCSS Cache Post Types Text or numeric value
litespeed-optm-css-separate_uri Separate CCSS Cache URIs Text or numeric value
optm_css_async_inline Inline CSS Async Lib True or false
optm_js_defer Load JS Deferred True or false
optm_exclude_jquery Exclude JQuery True or false
litespeed-cache-dns_prefetch DNS Prefetch Text or numeric value
optm_rm_comment Remove Comments True or false
css_combined_priority Combined CSS Priority True or false
css_exclude CSS Excludes Text or numeric value
js_combined_priority Combined JS Priority True or false
js_exclude JS Excludes Text or numeric value
optm_max_size Max Combined File Size Text or numeric value
optm_qs_rm Remove Query Strings True or false
optm_ggfonts_async Load Google Fonts Asynchronously True or false
optm_ggfonts_rm Remove Google Fonts True or false
litespeed-optm-css Critical CSS Rules Text or numeric value
litespeed-optm-js-defer-excludes JS Deferred Excludes Text or numeric value
optm_emoji_rm Remove WordPress Emoji True or false
litespeed-optm_excludes URI Excludes Text or numeric value
media_img_lazy Lazy Load Images True or false
litespeed-media-lazy-img-excludes Lazy Load Image Excludes Text or numeric value
media_img_lazy_placeholder Lazy Load Image Placeholder Text or numeric value
media_placeholder_resp Responsive Placeholder True or false
media_placeholder_resp_color Responsive Placeholder Background Color Text or numeric value
media_placeholder_resp_async Generate Reponsive Placeholder In Background True or false
media_iframe_lazy Lazy Load Iframes True or false
media_img_lazyjs_inline Inline Lazy Load Images Library True or false
media_optm_auto Optimize Automatically True or false
media_optm_cron Optimization Cron True or false
media_optm_ori Optimize Original Images True or false
media_rm_ori_bkup Remove Original Backups True or false
media_optm_webp Optimize WebP Versions True or false
media_optm_lossless Optimize Losslessly True or false
media_optm_exif Preserve EXIF data True or false
media_webp_replace Image WebP Replacement True or false
litespeed-media-webp_attribute WebP Attribute To Replace Text or numeric value
media_webp_replace_srcset WebP For Extra srcset True or false
cdn Enable CDN True or false
cdn_ori Original URLs Text or numeric value
litespeed-cdn-ori_dir Included Directories Text or numeric value
cdn_exclude Exclude Path Text or numeric value
cdn_remote_jquery Load JQuery Remotely True or false
cdn_cloudflare Cloudflare API True or false
cdn_cloudflare_email Email Address Text or numeric value
cdn_cloudflare_key Global API Key Text or numeric value
cdn_cloudflare_name Domain Text or numeric value
esi_enabled Enable ESI True or false
esi_cached_admbar Cache Admin Bar True or false
esi_cached_commform Cache Comment Form True or false
cache_object Object Cache True or false
cache_object_kind Method Text or numeric value
cache_object_host Host Text or numeric value
cache_object_port Port Text or numeric value
cache_object_life Default Object Lifetime Text or numeric value
cache_object_user Username Text or numeric value
cache_object_pswd Password Text or numeric value
litespeed-object_global_groups Global Groups Text or numeric value
litespeed-object_non_persistent_groups Do Not Cache Groups Text or numeric value
cache_object_persistent Persistent Connection True or false
cache_object_admin Cache Wp-Admin True or false
cache_object_transients Store Transients True or false
cache_browser Browser Cache True or false
cache_browser_ttl Browser Cache TTL Text or numeric value
check_advancedcache Check Advanced Cache Text or numeric value
login_cookie Login Cookie Text or numeric value
litespeed-adv-purge_all_hooks Purge All Hooks Text or numeric value
use_http_for_https_vary Improve HTTP/HTTPS Compatibility True or false
instant_click Instant Click True or false
debug_disable_all Disable All Features True or false
debug Debug Log Text or numeric value
admin_ips Admin IPs Text or numeric value
debug_level Debug Level Text or numeric value
log_file_size Log File Size Limit Text or numeric value
heartbeat Heartbeat True or false
debug_cookie Log Cookies True or false
collaps_qs Collapse Query Strings True or false
log_filters Log Filters True or false
litespeed-log_ignore_filters Exclude Filters Text or numeric value
litespeed-log_ignore_part_filters Exclude Part Filters Text or numeric value
crawler_usleep Delay Text or numeric value
crawler_run_duration Run Duration Text or numeric value
crawler_run_interval Interval Between Runs Text or numeric value
crawler_crawl_interval Crawl Interval Text or numeric value
crawler_threads Threads Text or numeric value
crawler_load_limit Server Load Limit Text or numeric value
crawler_domain_ip Site IP Text or numeric value
litespeed-crawler-as-uids Role Simulation Text or numeric value
crawler_custom_sitemap Custom Sitemap Text or numeric value
crawler_include_posts Include Posts True or false
crawler_include_pages Include Pages True or false
crawler_include_cats Include Categories True or false
crawler_include_tags Include Tags True or false
crawler_excludes_cpt Exclude Custom Post Types Text or numeric value
crawler_order_links Order links by Text or numeric value

Using Multiple Optimization Plugins

LiteSpeed Cache for WordPress has many optimization features in addition to our signature full-page cache, and as such, you probably don't need any other similar plugins. If you still want to use one of the other WordPress optimization plugins for whatever reason, that shouldn't be a problem, as long as you don't try to use the same features in both.

For example, if you are using our full-page cache and our CDN support, then you will need to make sure that page cache and CDN support are disabled in whatever other plugin you use. Similarly, if you are using a minification function (for example) in another plugin, you will need to keep minification disabled in our plugin.

Duplicating functionality at best bogs down your server, and at worst breaks your site. So don't do it!

To learn more about this, see our blog.

Compatibility Check

Not all cache plugins are good candidates to pair with LiteSpeed. In order to avoid duplicating our functions, a plugin must either:

  1. not include the same cache and optimization functions as LiteSpeed Cache at all, or
  2. include cache and optimization functions that can be disabled one-by-one.

Set up Other Plugin

Before you install and activate LiteSpeed Cache, you should first get the other plugin working to your satisfaction. Doing this part first will make it easier because you can follow the plugin’s given directions without having to worry about how it will impact LiteSpeed’s setup.

Once the plugin is installed, activated, and set up to your liking, purge that plugin’s cache to ensure there are no conflicts from the start, and then disable the cache and all of the duplicate optimization functions that you plan to use in LSCWP.

Set up LSCWP

Install and activate LSCWP. Upon activation, you should see the following warning message:


This message indicates that there is another cache plugin activated and that it is using the WordPress advanced-cache.php file. This is normal behavior! If you see this warning, it means everything is working as expected.

If you don’t see the above message, we need to figure out why. Try refreshing your screen a few times. If it’s still not there after that, it can mean one of two things:

  • The other plugin you installed doesn’t use advanced-cache.php
  • There is an underlying issue that needs to be addressed

In either of these cases, it’s best to let us know. We’ll be able to tell you if this is normal for the other plugin you’re using, and if it’s not, we can troubleshoot the underlying issue.

Configure LSCWP

Assuming you’ve seen the message above, the last step is to configure LSCWP not to use advanced-cache.php. If the other plugin wants to use that file, we are going to let it do so. Navigate to LiteSpeed Cache > Cache > Advanced, and uncheck Check Advanced Cache.

Save your changes, and the warning should no longer display. If the message is still there, let us know.

Enable the cache and any optimization features you wish to use in LSCWP.


At this point, you should have both plugins working together in harmony, but you’ll want to do a quick test, just to be sure. To verify that your pages are actually being cached by LiteSpeed, you can follow these steps.

If the page was not cached by LiteSpeed, then something in your setup is not quite right. Contact us, if you need help!

If the page was cached by LiteSpeed, then the setup is finished. Don’t forget to take a look at your LiteSpeed Cache settings and see if anything needs adjustment. In general, the default settings are fine, but you might want to tweak a few things since you’ve got the other plugin running, too.

Translate LSCache for WordPress

LSCWP is written in United States English, and so we rely our our international users to help us translate the plugin for worldwide use. If you are fluent in a language other than English (US), and you have a few minutes to contribute to our plugin, we would appreciate it!

Is Your Language Needed?


We have a few languages very well covered, so you'll want to check the Translating WordPress page for LiteSpeed Cache and look for your language (and geographic location if applicable). If there are red or yellow boxes next to the language, then your expertise is needed.

As you can see, we have quite a few red boxes as of this writing (and several pages more of them past where the screenshot ends). The most important column is the "Stable" column. Languages with shades of red in the stable column have less than a third of the plugin translated.

Submit a Translation

All you need is a login. Once you are logged in, you can click the link and start translating at your own pace.

The instructions will be the same for whichever language and geographic location you choose, but for simplicity's sake, let's say you're from Spain and would like to contribute to the Spain Spanish translation.

Click Spanish (Spain) to be brought to the es_ES translation page.


The most important section to work on first is Stable (latest release), so click on that to see what strings are still missing translation.


You'll be brought to a list of strings and their current translations (if any).

This list, if it's not well-populated, may look overwhelming. However, it is not required for you to translate every single string. You could spend half an hour and do thirty of them. Or ten. Or even just one. Every contribution, even a small one, gets us closer to full translation.

When you see a string you'd like to translate (for example, Communicated with Cloudflare successfully), double click on the Translation column for that string, and enter your translation in the box.


Click the Suggest new translation -> button. Congratulations, you have successfully translated your first string.


All translations must be approved by an editor for your language before they are incorporated into the plugin.

If you would like to be a translation editor for LSCache, just keep translating! We will notice you, and apply to to give you editor access. Additionally, we'll add you to our Slack team, where you can communicate with our other editors, and be kept in the loop for new plugin updates and needed translations.

Thank you for helping us make LSCWP accessible for a global audience!

Enabling and Limiting the Crawler

These instructions apply to the WordPress LSCache crawler and other CMS LSCache crawlers where available.

Due to the potential of the crawler to consume considerable resources, we have put the on/off switch in the hands of the server administrators. In a control panel environment, such as cPanel, the crawler is disabled by default and can only be enabled by an admin through Apache configuration. In the LSWS Native environment, the crawler is enabled by default and can be disabled at the server level or virtual host level in LSWS v5.3.5 and above.


We do not recommend enabling the crawler for shared hosting setups unless the server has enough capacity to handle it!

Shared Hosting / Control Panel Environment

As of LSWS v5.1.16, there are four different approaches you can take to crawling on your server:

  • You can disable it for the entire server
  • You can disable it for the entire server, and selectively enable it for specific vHosts
  • You can enable it for the entire server
  • You can enable it for the entire server, and selectively disable it for specific vHosts

Enabling the Crawler

To enable the crawler in either of the second two scenarios, you need to add this “Crawler Snippet” to the appropriate configuration or include file:

    <IfModule Litespeed>
     CacheEngine on crawler

The exact location of the relevant configuration or include file varies, depending on the control panel you use (or if you use no control panel at all), and which of the above options you are looking to enact. See below for instructions relevant to your setup.

After you've added the Crawler Snippet in the appropriate location, you should gracefully restart the server.


If you are on v5.1.16 and are having difficulty getting this to work, please force reinstall to the latest build.

Limiting the Crawler

Currently, the following variables are available for use with the Crawler function:

  • CRAWLER_USLEEP puts a minimum allowed value on the Delay field.
  • CRAWLER_LOAD_LIMIT sets a default for the Server Load Limit field.
  • CRAWLER_LOAD_LIMIT_ENFORCE sets a maximum allowed value on the Server Load Limit field.

To use these variables, add them one-per-line to the appropriate configuration file. For example:

    <IfModule LiteSpeed>
    CacheEngine on crawler
    SetEnv CRAWLER_USLEEP 1000

Disabling the Crawler

Starting from LSWS v5.3.5 or later, you may disable the crawler for an Apache virtual host, in any situation. Simply add CacheEngine -crawler to the Apache virtual host configuration, like so:

    <IfModule LiteSpeed>
    CacheEngine -crawler


Server Level

Change your working directory to:

  • /usr/local/apache/conf/includes/ for EA3 or
  • /etc/apache2/conf.d/includes/ for EA4.

Add the Crawler Snippet and optional server variables to the pre_main_global.conf file.

Global Virtual Host Level

Change your working directory to:

  • /usr/local/apache/conf/userdata/for EA3 or
  • /etc/apache2/conf.d/userdata/ for EA4

If these directories do not exist, create them.

Add the Crawler Snippet and optional server variables to the lscache_vhosts.conf file.

Apply these changes to all Virtual Hosts by running the following command:

    /scripts/ensure_vhost_includes --all-users


You only need to run this command once and it will activate for all users, including new users created by WHM later. There is no need to edit the cPanel skeleton file.

Individual Virtual Host Level

Change your working directory to:

  • For EA3: /usr/local/apache/conf/userdata/std/2_4/<user>/<domain>/
  • For EA4: /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain>/

If your site supports HTTPS (SSL), please also change that working directory to:

  • For EA3: /usr/local/apache/conf/userdata/ssl/2_4/<user>/<domain>/
  • For EA4: /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain>/


The 2_4 in the path is an example. You can replace it with your appropriate version, such as 2 or 2_2.

If these directories do not exist, create them.

Add the Crawler Snippet and optional server variables to the lscache_vhosts.conf file. This will enable the crawler for this Virtual Host only.

Apply these changes by running the following command:

    /scripts/ensure_vhost_includes --user=$user


Server Level

Change your working directory to:

  • /etc/httpd/conf.d/ for CentOS
  • /etc/apache2/conf.d/ for Debian
  • /etc/apache2/conf-enabled for Ubuntu

Add the Crawler Snippet and optional server variables to lscache.conf. If it doesn’t exist, create it.

Global Virtual Host Level

Change your working directory to /usr/local/psa/admin/conf/templates/custom/domain

Create it if it doesn’t exist.

Copy /usr/local/psa/admin/conf/templates/default/domain/domainVirtualHost.php to this location.

Edit the file and add the Crawler Snippet and optional server variables after the mod_suexec.c block.

Reconfigure all virtual hosts (this will regenerate new configuration files for all vhosts), like so::

    /usr/local/psa/admin/bin/httpdmng --reconfigure-all
Individual Virtual Host Level

Change your working directory to /var/www/vhosts/system/<domain_name>/conf/

Create a file called vhost.conf if it does not already exist ( or vhost_ssl.conf for HTTPS sites).

Add the Crawler Snippet and optional server variables to this file.

Reconfigure this Virtual Host (this will regenerate new configuration files for this vhost), like so:

    /usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name>


Server Level

Add the Crawler Snippet and optional server variables to the /etc/httpd/conf/extra/httpd-includes.conf file.

Global virtual host level

Create a /usr/local/directadmin/data/templates/custom/cust_httpd.CUSTOM.2.pre file and add the Crawler Snippet and optional server variables to it.

Apply these changes to all Virtual Hosts by running the following commands:

    cd /usr/local/directadmin/custombuild
    ./build rewrite_confs

LiteSpeed Native

The cache crawler is enabled by default in a LSWS Native environment.

To disable it at the Server Level, you will need to use LSWS 5.4 and above. There was a Cache Features function added to control this.

In the LSWS WebAdmin interface, navigate to LSWS Admin > Configuration > Server > Cache. In Cache Features, check On, uncheck Crawler, check ESI, and uncheck Not Set.

If Not Set is checked, the other three values will be ignored and the default values will be used. (By default, all three are checked.)


To disable the cache crawler at the LSWS Native Virtual Host level, navigate to LSWS Admin > Configuration > Virtual Host > VH Name > Cache >, and set Cache Features in the same manner as above. If Not Set is checked, the other three values will be ignored and the server-level configuration will be inherited.


Do not set Enable LiteMage to On, as this setting will also enable the crawler, even if Crawler is unchecked.


To add any of the optional server variables, navigate to Server > External App and add the variable(s) to the Environment setting, one per line. For example:




The LiteSpeed Web Server cache engine will set environment varibles for X-LSCACHE. You can always check Environment Variables through the phpinfo page to see if the crawler is on or not. If the crawler is not there, then it has been disabled successfully. LSWS can only disable the LiteSpeed Cache plugin or LiteSpeed crawler since such LiteSpeed crawlers will check X_LSCACHE environment variable. LSWS can not stop any third party crawler from working since they don't check X_LSCACHE to act accordingly.

    $_SERVER['X-LSCACHE'] on,esi


In the LiteSpeed cache for WordPress plugin, under Crawler > Summary, it should show Crawler Cron set to Disable, and

    Warning: The crawler feature is not enabled on the LiteSpeed server. Please consult your server admin.

Setting Up CloudFront CDN

Create CDN with CloudFront


  1. Set up AWS CloudFront CDN
  2. Get your CloudFront Domain Name
  3. Make sure your site can be visited directly through the CloudFront Domain Name

Set Up in LSCache Plugin

  1. From the WP Dashboard, navigate to LiteSpeed Cache > CDN > CDN Settings.
  2. Set Use CDN Mapping to ON
  3. Enter CDN URL as your CloudFront Domain Name
  4. Enable the relevant Include buttons. e.g. Images and CSS. For this example, if we don't Include JS, then we also need to remove .js from Include File Types
  5. Set up Original URL as your original domain name (and sub-folder if you are using one)


Check that the CSS is served from CloudFront


Check that the JS is served from the original domain


Setting up StackPath or MaxCDN

This tutorial will cover the steps needed to set up MaxCDN or StackPath CDN with LiteSpeed Cache on WordPress with your own custom domain.

Requirements -

  • MaxCDN or StackPath CDN Account.
  • WordPress website with LiteSpeed Cache installed.


  • LiteSpeed Web Server is not neccessary to use LSCache's CDNsupport. This feature will also work on Apache, nginx or any other web servers.
  • There will be no downtime during the process, if each and every step is followed correctly.

This tutorial will be covered in two major parts: 1. Configuring the CDN itself within your StackPath or MaxCDN account 2. Configuring LiteSpeed Cache to work with the CDN.


Since MaxCDN and StackPath represent the same product, from now on in the tutorial we will say simply "StackPath" to refer to both StackPath and MaxCDN.


StackPath can be used in conjunction with QUIC CDN. Use QUIC CDN to serve your dynamic pages while StackPath handles the static files. To set up QUIC CDN, please see the documentation These two solutions are supported together out of the box without any special steps.

Setting up the CDN

Create a CDN Site

Log into your StackPath account, complete the registration process, and you will be taken to the Overview tab. Press the Create CDN Site button.

!create cdn

You will be asked to Enter your Delivery Domain. Choose a subdomain where you will serve your static files from. A common choice is

!enter delivery domain

Set Source to WebServer and Hostname/IP Address to your site's domain.


Please enter your site's default domain. If your website currently opens on, Choose https and enter in the domain. Open your domain in a browser once to verify.

!enter origin domain

Once your CDN site has been created, you will be given a CNAME URL. Make a note of this value.

!copy cname

Log in to your domain registrar and create a CNAME record with the host or whatever you chose during the initial setup, and use the CNAME URL given to you by StackPath, like so: CNAME IN TTL(Minimum Possible)

Be sure to replace xxxxxxx with your CDN site's actual subdomain.

Setting up SSL and DNS records

Return to the StackPath dashboard by clicking the Overview button.

Click on your newly-created CDN site, go to Edge SSL, and click the Generate Free SSL Certificate button.

!generate ssl

Select your delivery domain and click Continue.

You will recieve another CNAME record that you must create in order to validate SSL for your custom created CDN subdomain (

!ssl cname

You now have two CNAME records. One is to point your custom domain to StackPath CDN and the other is to verify domain ownership for SSL.

Log into your domain registrar and add the 2nd CNAME record which is for SSL Verification, exactly as shown by StackPath.


This record should be created for the delivery subdomain and not the root domain. e.g, If your main domain is, but in the delivery subdomain you have entered, This CNAME record should be created as CNAME IN TTL(minimum) ****

Once the CNAME record is added, you can wait for 5-10 minutes and then click the Force Recheck button to validate your domain. You should see an SSL Certificate inside the Edge SSL tab now.

!ssl active

If it is taking sometime, it's fine to move ahead. You can re-verify at the end.

Setting up Mandatory CDN Settings

Return to the Overview tab, re-select your newly created CDN site and go to the Settings tab.

In this page, you need to set up two things:

  • Host Header: This value should be your real domain and not the delivery subdomain. For example, if you use your website like, select there. If you use your website like, select Click on Add Custom, if you don't see the desired option in the list.
  • Pull Protocol: This value should also be selected based on your website's default. If you use HTTPS by default select HTTPS. Otherwise, leave it on HTTP.

!mandatory cdn settings

Other settings below are related to caching properties and are best decided by the website owner. It is also okay to leave them set to their defaults if you're not sure.

Setting up the LiteSpeed Cache Plugin

In the second and the final step, we will setup the LiteSpeed Cache plugin to serve static files using StackPath.

Log into your WordPress Dashboard, navigate to LiteSpeed Cache > Settings > CDN


If you do not see the CDN tab, click on Show Advanced Options to enable it.

Set Enable CDN to ON. In the CDN Mapping section, set CDN URL to the delivery subdomain you created in the previous steps, i.e Set Original URL to your original default domain that you use with your WordPress site (www or non-www).

!litespeed cache settigs

Do not click the "Save Settings" button yet.

Before saving the settings, re-verify everything so as to avoid any downtime. Your SSL should be issued and should be showing as active in your EdgeSSL Settings inside your StackPath Account, and Host Headers and Pull Protocol should be set perfectly.

You can also verify if the CDN settings are correct by simply going to your website and trying to load any image on your website using the delivery subdomain. For example, if your logo loads from, manually open a new tab and open the URL as, and see if it loads correctly.

If everything looks right, click Save Settings, and then Purge - LSCache via the LSCache logo on the Admin bar.

CDN setup is complete!

Verify Your CDN is Loading Correctly

Visit any page on your site. View the page source by using CTRL + U or the right click menu. You should see your static files being served from

!verify cdn

This completes your website's setup with LiteSpeed Cache and StackPath/MaxCDN. Let us know your feedback or any problems you may experience at support[at]

Turning WordPress Shortcodes into ESI Blocks

You can turn WordPress shortcodes into ESI blocks with LiteSpeed Cache. This allows you to cache the contents of the shortcode in a different way than you've cached the rest of the page. (You can learn more about ESI on our blog, if this concept is new to you.)

If you have a mycalendar shortcode, for example, and it inserts a calendar into your page, you might use it like this:

    [mycalendar month="November" year="2018"]
To turn it into an ESI block, you would instead use it like this:
    [esi mycalendar month="November" year="2018"]
By default, shortcode contents are stored in public cache, and the TTL defaults to whatever value you have stored in LiteSpeed Cache > Cache > TTL > Default Public Cache TTL, but you can change that with a few parameters. To store the shortcode contents in private cache for five minutes (or 300 seconds), you can say this:

    [esi mycalendar month="November" year="2018" cache="private" ttl="300"]


While LiteSpeed Cache can easily cache your shortcode contents, it is not possible for LSCache to purge the shortcode contents on demand. Shortcode ESI blocks can naturally expire when the TTL is reached, but a purge cannot be triggered by particular events. This makes sense, because LiteSpeed can't know which occurences should trigger a purge. Different shortcodes all have different events that render them out-of-date, and there's no way for LiteSpeed to know what they are.

Using the example of the calendar plugin above, let's say you use the following shortcode:

    [esi mycalendar month="November" year="2018"]
This will cache the mycalendar block for the same length of time as your site's default TTL. If someone edits an event before the TTL is reached, then the ESI block will, unfortunately, be out-of-date.

There are two ways to handle this issue:

  • Have the shortcode's plugin author use our API to trigger a purge when block content changes.
  • Use a short TTL, and live with the possiblity that contents may be out-of-date for a short time.

Get the Plugin Author Involved

If it's important that the shortcode contents be purged by specific events, you can share this API call with the author of the shortcode's plugin (just be sure to replace mycalendar with the actual name of the shortcode you want to purge:

do_action( 'litespeed_purge', 'esi.mycalendar' ) ;

This is the most precise way to keep the content in the shortcode up-to-date and accurately cached according to the shortcode's own requirements.

Do it Yourself

If it is not critical for the contents of the shortcode to have up-to-the-minute accuracy, then you can use the ttl parameter to cache the content for a short time. If you can live with content that is an hour old, set ttl="3600". If you are thinking more along the lines of five minutes, set it to ttl="300".

While it is possible to set the content to not be cached at all ( ttl="0"), it is not recommended. Any time there is uncached content on a page, PHP must be invoked in order to generate that content. PHP uses valuable resources, and significantly slows down a page. It's far better to cache your content for a small amount of time than to set it not to be cached at all.

Cookies and Cache

The relationship between cookies and caching can be easily misunderstood. When you talk about "caching cookies" or "not caching cookies," it's not the cookies themselves that are being cached or not cached. It's the pages of the site that are being cached or not cached based on whether a user has those cookies stored.

Cookies, generally, are ignored unless you specify otherwise. Cookies become important when they impact the user experience in some way.

Cookies Set or Read by WordPress

If a cookie must be set or read by WordPress, then it has to be excluded from cache. And, if the cookies are set on your site (i.e. they are not set somewhere before arriving at your site), then you will also have to exclude the page that sets the cookie's value.


Let's say your site is part of an affiliate network. When a user arrives at an aff-example cookie is set. As they navigate the site, the cookie is updated with tracking information.

In this case, the cookie aff-example must be added to the Do Not Cache Cookies list in LiteSpeed Cache > Cache > Excludes, and ^/afilliate_home must be added to Do Not Cache URIs list on the same page. (For more on the Excludes page, see the screen-by-screen documentation.)

If, in this example, the cookie was set at, but then never referenced again, you would not have to exclude the cookie from cache.

Alternately, if the cookie was set offsite somewhere, but was used for tracking as the visitor wandered around your site, then you would have to exclude the cookie from cache, but you wouldn't have to exclude the ^/afilliate_home URI.

Cookies That Indicate Variations

Sometimes cookies can be used to indicate important information about the user to WordPress, to help determine what content should be shown to the user. In these cases, you can use the cookies to create cache varies. When LSCache varies on a cookie, it caches separate public versions of the pages of the site, based on the value of the cookie.


Let's say your WP site is a shop, and you have special pricing for your friends that is activated when they visit That page sets a myfriend cookie, and from that point on, every page they visit in your shop shows pricing that is 20% less than normal. When a visitor without the myfriend cookie looks at the pages in your shop, they see regular prices.

Because the cookie is set on the page, that URI will need to be excluded from cache as described above.

There are two ways to deal with the cookie itself:

  • You could do as the previous example, and exclude it from cache. That's the easiest way, but it means your friends will always have uncached content, and that's not an ideal experience for them.
  • You could create a cache vary based on the myfriend cookie.


Assume you have a WooCommerce site with a "woocommerce_products_per_page" cookie. For some users, the value will be 10. For others it will be 100. And still others may have a value of 200. These three scenarios require three different views.

There are two ways to handle different views based on a cookie value:


The more efficient option is to find a JavaScript-based solution. A JavaScript plugin would only need to store one copy of the page and would build the display based on the existence of the cookie.

Rewrite Rules

If a rewrite rule-based answer is preferred, the site can be configured to vary on the cookie by adding the following rule to your site's .htaccess file:

<IfModule LiteSpeed>
CacheLookup on
RewriteRule .* - [E=Cache-Vary:woocommerce_products_per_page]

When a user visits your WooCommerce site, the woocommerce_products_per_page=xxxxxxcookie will be created. Using the rewrite rule above, the cache will vary on that cookie. This means the cache will store multiple copies: one for every value of the cookie that requests the page.


woocommerce_products_per_page is an example. Be sure to substitute the appropriate cookie name.

Further Reading

You can learn more about cookies and cache varies in our Developer's Guide to Cache Vary.

Memcached, LSMCD and Redis (Object Cache) Support in LSCWP

As of version 1.8, LiteSpeed Cache for WordPress supports Object Cache.

What is an Object Cache?

An object cache stores the results of expensive and/or frequent database queries in a way that makes them easy to retrieve, and eliminates the need for repeated access to the database. Object caching greatly reduces the time it takes to retrieve query results.

For example, your WordPress site's options are stored in the database. Site options include things like the site's name and URL. Every time a page is assembled for a visitor, it is necessary to access the database to read the site options. As you can imagine, these repeated queries for the same information represent wasted resources. With an object cache, you can query the database once, and save the results for a set period of time. During that time, whenever a page must be assembled, WordPress can get the site information from the cache. Accessing object cache is a much less resource-intensive prospect than accessing a database.

Some queries are time-consuming, and other queries are repeated frequently. Both of these scenarios can be improved by storing the query results in object cache.


If you have a site that is fully-cached by LSCWP, you won't use object cache very often. Object cache is only necessary when WordPress is building a page through PHP. If PHP is not being invoked (and minimizing PHP usage is the goal with LSCache) then there are no queries to process and therefore nothing to look up in object cache.

How to set up Object Cache Support

LSCWP doesn't provide object caching directly. Rather, it supports your use of an external object cache such as Memcached or LiteSpeed's drop-in Memcached replacement, LSMCD.

Install Memcached, LSCMD or Redis and PHP Extension

You will need a working and fully tested installation of Redis, Memcached, or LSMCD, as well as the related PHP extension (i.e. php-memcached or php-redis) in order to make your object cache work properly with WordPress.

Installation of the above software is outside of the scope of this document, but we have other wikis that may help:

Config Object Cache in LSCWP

If you are using LSMCD, Memcached or Redis, you can set up LSCWP support in the Cache Settings tab. Navigate to LiteSpeed Cache > Cache > Object. You will need to give LSCWP some parameters, including where your Memcached or LSMCD lives, which objects you'd like to have cached, and how long you want objects to remain in cache, among other things.

Before enabling Object Cache, the default values with already be filled in for you.

After enabling Object Cache, the LSCache plugin will automatically run both connection testing and Memcached/Redis extension detection.

Detailed instructions for all of these settings can be found here.

How to Verify

There are not too many methods to check the Object Cache log, but if you set LiteSpeed Cache > Toolbox > Debug Settings > Debug Log to ON or Admin IP, and view your page source code, you should see something like this at the bottom of the code:

    <!-- Object Cache [total] 5190 [hit_incall] 5056 [hit] 6 [miss_incall] 21 [miss] 107 [set] 171 ->

  • total is the total number of objects the page requested.
  • hit_incall is the number of objects that did not hit Memcached but hit the runtime data from above.
  • hit is the number of objects retrieved from Memcached.
  • miss_incall is the number of objects not set in runtime. That is to say, when php ran into the current line, no data was set before.
  • miss is the number of objects not found in Memcached.
  • set is the number of objects set in Memcached.

How to Debug

If your Connection Test shows Failed, there are a few things you can try.

  1. Try service memcached status, to make sure the service is active (running).
  2. Try ss -lptun | grep 11211, to make sure the Memcached port is listening.
  3. Try telnet localhost 11211, to make sure you can connect to localhost successfully.

Test files

You can create test PHP files to test connection

For Memcached:


    $conn = new Memcached ;
    $address = '/path/to/memcached.sock' ; // set the address here
    $port = 0 ; // set the port
    $conn>addServer( $address, $port ) ;
    var_dump( $address ) ;
    var_dump( $port ) ;
    var_dump( $conn>getStats() ) ;
    echo '<hr>';
For redis:

    $cfg_host = 'redis address' ;
    $cfg_port = '6379' ; // or 0 if use socket
    $cfg_pswd = '' ; // Set if has
    $cfg_db = 0 ;

    $conn = new Redis() ;
    $conn>connect( $cfg_host, $cfg_port ) ;
    if ( $cfg_pswd ) $conn>auth( $cfg_pswd ) ;
    if ( $cfg_db ) $conn>select( $cfg_db ) ;

    var_dump( $conn>ping() ) ; // Should give a `+PONG`

Using Memcached in a UNIX socket

Memcached can run in a UNIX socket, which provides better performance than a TCP connection.


If Memcached fails to start, it is usually due to permission and user problems. Please use root privilege to execute the following instructions, and verify that the socket path is writable to the designated user.


  1. Stop Memcached systemctl stop memcached
  2. Copy the service file cp /usr/lib/systemd/system/memcached.service /etc/systemd/system/memcached.service
  3. Add the following content to /etc/systemd/system/memcached.service. After [Service], please change username to the same user that runs PHP: User=username Group=username The contents of the file should look like this:
  4. Edit /etc/sysconfig/memcached, changing the path to your desired location, and the username to the same one used in Step 3: OPTIONS="" USER="memcached" becomes OPTIONS="-s /path/to/memcached.sock -a 0770" USER="username"
  5. Start Memcached again: systemctl start memcached
  6. Verify it started successfully: systemctl status memcached
  7. Check if everything is working well: nc -U /path/to/memcached.sock stats
  8. If there is still a permission issue, please check selinux status: getenforce
  9. Disable selinux if status shows Enforcing: setenforce 0 (reboot will re-enable selinux)
  10. To permanently disable selinux, edit /etc/selinux/config, change enforcing to permissiveordisabled and then reboot.


  1. Stop Memcached systemctl stop memcached
  2. Edit /etc/sysconfig/memcached and change OPTIONS="" USER="" to OPTIONS="-s /path/to/memcached.sock -a 0770" USER="username" where USER is the same user that runs PHP.
  3. Start Memcached service memcached start
  4. Check if everything is working well: nc -U /path/to/memcached.sock stats
  5. If there is still a permission issue, please check selinux status: getenforce
  6. Disable selinux if status shows Enforcing: setenforce 0 (reboot will re-enable selinux)
  7. To permanently disable selinux, edit /etc/selinux/config, change enforcing to permissiveordisabled and then reboot.

Ubuntu 17.10, Ubuntu 16.04, Debian 8 and Debian 9

  1. Stop Memcached systemctl stop memcached
  2. Edit /etc/memcached.conf, comment out host and port, add socket path and permission -s /path/to/memcached.sock -a 0770 and change -u memcache to -u username where username is the same user that runs PHP.
  3. Start Memcached again systemctl start memcached
  4. Check if everything is working well: nc -U /path/to/memcached.sock stats

Ubuntu 14.04 and Debian 7

  1. Stop Memcached service memcached stop
  2. Edit /etc/memcached.conf, comment out host and port, add socket path and permission -s /path/to/memcached.sock -a 0770 and change -u memcache to -u username where username is the same user that runs PHP.
  3. Start Memcached again service memcached start
  4. Check if everything is working well: nc -U /path/to/memcached.sock stats

Using Redis in a UNIX Socket

Please use root privilege to execute the following instructions. If Redis fails to start, please verify SELinux is disabled , and all mentioned directories and files have correct permissions to the designated user.

Centos 7.X

  1. Stop Redis. systemctl stop redis
  2. Copy the service file. cp /usr/lib/systemd/system/redis.service /etc/systemd/system/redis.service
  3. Edit /etc/systemd/system/redis.service. User=username Group=username Change username to same user that runs PHP.
  4. Edit /etc/redis.conf and change the following (Change port to 0 if TCP socket is no longer needed):
        unixsocket /path/to/redis.sock
        unixsocketperm 770
        logfile /path/to/redis.log
        dir /path/to/redis
  5. Change owner of redis.conf to same username in step 3. chown username:group /etc/redis.conf If /path/to/redis directory does not exist, please manually create it, and make sure above mentioned socket path, log pathand dir path and are writable by the designated user.
  6. Start Redis. systemctl start redis
  7. Verify it started successfully. systemctl status redis
  8. Check whether everything is working well. nc -U /path/to/redis.sock info

Last update: September 24, 2020