WpW: The Beginner’s Guide to LiteSpeed Cache for WordPress

November 22nd, 2017 by LSCache 0 Comments

WordPress Wednesday: Beginner's Guide to LiteSpeed Cache for WordPress

Welcome to another installment of WordPress Wednesday!
Today’s Topic: Beginner’s Guide to LiteSpeed Cache for WordPress

Disclaimer: The information contained in this post is accurate for LSCWP v1.6.3 [release log]. If you are using a newer version of the plugin, some details may have changed. Please refer to our wiki for the latest!

So you’ve downloaded the LiteSpeed Cache for WordPress plugin, installed it, and activated it. Now what?

Some people are invigorated by the site of all of those settings tabs and are eager to jump right in, while others find all of the options overwhelming, and are paralyzed with indecision.

Well, if you are part of the latter camp, you’ve come to the right place. Today we are going to talk about setting up LSCWP simply and easily. We’ll go over the things you must know in order to successfully use the plugin, and tell you which settings you can safely ignore.

I’ve installed and activated LSCache for WordPress. Now what?

Beginner's Guide to LiteSpeed Cache for WordPress

LSCWP essentially has two purposes: that of a full-page cache for your site’s dynamically-generated pages, and that of a site-optimization plugin. Most people who install LSCache do so for the caching functions, and the rest is just the icing on the cake.

You are free to enable the caching functions and ignore everything else.

Upon activation, you’ll find that everything is disabled. To turn on caching, navigate to LiteSpeed Cache > Settings > General and set Enable LiteSpeed Cache to Enable.

You could stop right there, never configure another setting, and the plugin would probably cache your site very nicely. We specifically chose the default settings to work with the majority of sites right out of the box.

TL;DR: This is a very long post, but that’s only because I set out to explain every single basic setting for you. In the event that you want to tweak things a bit, it doesn’t hurt to have a rudimentary understanding of these things. There’s no need to read it now, though! Use the default settings, bookmark the wiki version of this page (which we will keep updated through each plugin version), and check it when you need the reference.

Still reading? Ok! Let’s look at the first four tabs in the Settings section, and see what they do. These are the most basic settings for your cache.

Beginner’s Guide to LiteSpeed Cache for WordPress


Let’s start with the General tab. The first option turns the caching functionality on and off. The remaining settings define the parameters for the expiration of different types of content in the cache.

TTL stands for “Time to Live” and it refers to the number of seconds a page can remain in cache before LSCache considers it stale. Once a page reaches its TTL, it is purged from cache. We’ve chosen default TTL’s that should work for most sites, but you are free to change them.

If you would like a deeper understanding of content caching and purging, take a look at this article. We wrote it at a high-level, so you can get the gist without knowing a lot of jargon.

Beginner's Guide to LiteSpeed Cache for WordPress: LSCache Settings General Tab

Enable LiteSpeed Cache

Default Setting: Enabled – The plugin will cache pages.
Other Options:

  • Disable – Purges the cache of all of the current site’s cache entries and stops further caching.
  • Use Network Admin Setting – Uses whichever of the previous two options the Network Admin has chosen. (Multi-site only)

Default Public Cache TTL

This TTL setting controls most of the pages. All the other TTLs are for specific pages/types of pages.

Default Setting: 28800
Constraints: Must be 30 seconds or more
Customization: The default value amounts to 8 hours. Other possible values are 1 hour (3600), 1 day (86400), 1 week (604800), or any other number you like. If your site contains pages that are not likely to change once posted, a longer TTL may be beneficial.

Default Private Cache TTL

This TTL setting controls how long to cache private pages.

Default Setting: 1800
Constraints: Must be between 60 and 3600 seconds
Customization: The default value amounts to 30 minutes. The longest possible cache time for private content is one hour.

Default Front page TTL

This TTL setting controls the front page. Note that this can be triggered by the is_front_page() check or by a third party plugin that has chosen to use the front page TTL for one of its pages (for example, the WooCommerce shop page).

Default Setting: 1800
Constraints: Must be 30 seconds or more
Customization: The default value amounts to 30 minutes. The front page tends to be the most-often-updated page, and is also the page that most visitors will see. For these reasons, it may be beneficial to use a short TTL. That said, if you don’t update the site often, longer TTLs are a valid option.

Default Feed TTL

This TTL setting controls the feeds. Feeds are a great way for readers to stay up to date on blog entries, but they generally pull from the blog in intervals. This pulling can cause a constant load on the server. Caching the feed pages can alleviate this load, and because LSCache purges feed pages on update and on comment, they are guaranteed to remain up to date.

Default Setting: 0 – Do not cache feeds
Other Options:

  • Any number less than 30 – Will be set to 30 seconds
  • Any number greater than 30 – Will be set to that number of seconds.

Customization: If there are constant updates, it may not be worthwhile to set this up, because the cache will be purged constantly. If there are a lot of readers updating by feed, however, it may still be beneficial to cache the entries for a limited time.

Default 404 TTL

This TTL controls the pages that return a 404 (“not found”) result. This may be random URLs visited or intentional 404s, but all pages returning a 404 status will use this value.

Default Setting: 3600
Other Options:

  • 0 – Do not cache 404s
  • Any number less than 30 – Will be set to 30 seconds
  • Any number greater than 30 – Will be set to that number of seconds.

Customization:The default value is 3600, for one hour. There is no real recommended value for this TTL because it depends on the site. If visiting 404 pages is a common occurrence, it may help to cache the page for at least a short period. If 404 pages are intentional, it may help to cache the page for a longer period of time, because it is an expected visit. One matter of concern is disk size. Since 404 is a “not found” result, there is an unlimited amount of pages that could be cached. This could negatively impact disk usage.

Default 403 TTL

This TTL controls the pages that return a 403 (“forbidden”) result.

Default Setting: 3600
Other Options:

  • 0 – Do not cache 403s
  • Any number less than 30 – Will be set to 30 seconds
  • Any number greater than 30 – Will be set to that number of seconds.

Customization: The default value is 3600, for one hour. Pages returning 403 are usually intentional, so it may be worthwhile to have a longer TTL for this setting.

Default 500 TTL

This TTL controls the pages that return a 500 (“internal server error”) result.

Default Setting: 3600
Other Options:

  • 0 – Do not cache 500s
  • Any number less than 30 – Will be set to 30 seconds
  • Any number greater than 30 – Will be set to that number of seconds.

Customization: The default value is 3600, for one hour. 500 Errors are a more severe error. Caching this page may mask an issue within WordPress, so that may not be desired.


This tab allows you to decide what types of content to cache. By default, everything aside from Object Cache and Browser Cache is on. This is because object caching and browser caching are not native functions of LSCWP, but rather other types of caches that LiteSpeed can support if you are already using them.

If you don’t know what these settings do, it’s best to leave them set to their defaults.

Beginner's Guide to LiteSpeed Cache for WordPress: LSCache Settings Cache Tab

Cache Logged-in Users

Use this option to control whether to serve logged-in users from a private cache. For logged-in users, it’s either private or nothing. When users are logged in, there is potential for each page to have private content, and therefore they cannot be served from public cache.

Default Setting: ON – Content for logged-in users will be cached privately by session id.
Other Option: OFF – Logged-in users will not be served from cache at all.

Cache Commenters

When a user leaves a comment, the page reloads. This setting controls whether to serve the page from cache at that point. This option is useful if your WordPress installation requires moderation on guest comments. Enable this setting to keep commenters from seeing their under-moderation comments.

Default Setting: ON – Cached version will be served.
Other Option: OFF – Commenters will not be served from cache.


This option allows you to cache requests that the WordPress REST API makes. If you don’t know what this is, then you probably don’t need it. If you don’t use the API, having caching enabled won’t hurt anything. And if you do you use it, having caching enabled will speed things up.

Default Setting: ON – REST API calls will be cached.
Other Option: OFF – REST API calls will not be cached.

Cache Login Page

This option will cache the login page. Normally, there is no reason to disable this option. If there is private data displayed on the page (i.e. something that may identify a user), however, this option should be turned off.

Default Setting: ON – The login page will be cached.
Other Option: OFF – The login page will not be cached.

Cache favicon.ico

This option will cache the favicon.ico response if the file does not exist. This is a useful option because WordPress loads every time the favicon.ico file is not found. Caching the “not found” response avoids that extra call.

Default Setting: ON – The “not found” response will be cached.
Other Option: OFF – No response will be cached, and WordPress will need to be invoked to generate a “not found” response.

Cache PHP Resources

This option will cache any PHP resources that are loaded by themes. Generally speaking, these are actually CSS or javascript resources loaded via PHP. In most cases, they provide static output, and there is no reason to load PHP every time. If the output is, in fact, dynamic, turn this option off.

Default Setting: ON – PHP resources will be cached.
Other Option: OFF – PHP resources will not be cached.

Cache Mobile

This option enables users to display separate HTML for mobile and desktop views. Site owners primarily use this for non-responsive themes, but they may also use it in situations where the theme loads different widgets depending on browser type.

If you are using a responsive theme, and there is no difference in the actual content served to mobile vs. desktop, then you do not need to cache a separate mobile view.

Default Setting: OFF – Separate mobile view will not be enabled.
Other Option: ON – Separate mobile view will be enabled.
NOTE: The list of Mobile View User Agents (see below) must not be empty when this is turned on.

List of Mobile User Agents

If Enable Separate Mobile View (see above) is off, this text box will be disabled. Once enabled, fill in this box with a rewrite-rule-friendly list of user agents.

Default Setting: Mobile|Android|Silk/|Kindle|BlackBerry|Opera\ Mini|Opera\ Mobi
Customizations: It’s not likely you would need to change this, but if you know of other user agents that require a mobile view, add them to the string. Each agent should be separated by a |.

Private Cached URIs

Sometimes you have pages that should never be publicly cached, but are ok to cache privately. List those URIs here. Enter the paths, one-per-line, that are to be cached privately. LSCache will treat the paths as partial strings and compare them to URIs.

To make an exact match, add a $ to the end of the path, as in /category/recipes$.
To indicate the beginning of the path, add a ^ to the start of the path, as in ^/category/recipes

category/recipes matches /blog/category/recipes/baking, /category/recipes/baking, and /category/recipes.
/category/recipes$ matches only /category/recipes.
^/category/recipes matches /category/recipes/baking, and /category/recipes.

Default Setting: Empty String



There are sometimes situations where you would like to purge pages before their natural expiration. This section allows you to define the rules for that behavior. The default selections should work for most sites.

Beginner's Guide to LiteSpeed Cache for WordPress: LSCache Settings Purge Tab

Purge All on Upgrade

This option indicates whether to purge all pages when there are upgrades executed on installed plugins. Plugin upgrades make changes across versions, and it’s not easy to predict whether these changes will impact page content. It’s highly recommended to leave this on and play it safe.

Default Setting: ON – Pages will be purged.
Other Option: OFF – Cache will remain intact.

Auto Purge Rules For Publish/Update

When an author publishes or updates a post, additional pages may change. Category listings, tag listings. the blog’s front page, and a variety of archives may all also change.

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

LSCache must purge all of the affected pages in order to avoid serving stale content. These settings give you an opportunity to adjust the rules to fit what your site needs.

There is an option for All pages, which is disabled by default. Enabling this ignores all other checkboxes. Choosing the All pages option makes sense if you do not have ESI enabled and you have dynamic post-related widgets which display on every page. (ESI is one of the advanced options that is disabled by default.)

Scheduled Purge URLs

You can choose to purge a list of URLs automatically at a certain time of day. This is not necessary under normal circumstances. LSCWP’s sophisticated purge rules are able to handle most situations. If, however, you have content that is generated by an outside source, for example, you might want to purge the relevant pages every day to be sure the outside content is correctly displayed.

Default Setting: Empty String
Other Option: List of URLs (one per line)

Scheduled Purge Time

Use this field in conjunction with the one above. If you’ve provided a list of URLs to purge, specify the time they should be purged here.


You may have pages that you don’t want cached at all. These options allow you to exclude specific parts of your site from being cached. Again, for most sites, there will be no need to change these settings. We provide these options to allow you to make custom exceptions to the cache rules.

Beginner's Guide to LiteSpeed Cache for WordPress: LSCache Settings Exclude Tab

Do Not Cache URIs

This box takes a list of URIs (one per line) that should not be cached. Each URI will be compared to the REQUEST_URI server variable to determine if it’s a match.

(For more on how matching URIs works, see the explanation of Private Cache URIs above, under the Cache tab.)

Do Not Cache Query Strings

You can eliminate URLs with certain query strings from being cached. Enter one per line.

Let’s say you have a special theme that allows you to turn the pages into monochromatic color schemes simply by adding the ?color= query string to the end of the URL.

You could enter color=purple in the Do Not Cache Query Strings list if you don’t want to cache purple pages. You could also enter color= to indicate that you don’t want to cache any URL with a specified color, regardless of which color it is.

Do Not Cache Categories

By default LiteSpeed caches all categories. 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.

A category slug is the string used to represent the category in a URI. So, if you have a category called “Recipe Box” and it’s URI is /category/recipes then the slug for the Recipe Box category is recipes.

Do Not Cache Tags

We treat tags the same way we treat categories: cached by default, but ignored if entered by tag slug (one per line) in this box.

Do Not Cache Cookies

If your site uses cookies that you don’t want cached, enter them in this box, one per line.

Do Not Cache User Agents

You may exclude specific user agents from cache. Enter them by name in this box, one per line.

Do Not Cache Roles

You may wish to exclude certain user roles from caching. For example, if you are an admin, and you are testing new functionality, you may want to exclude your administrator role from being served from cache until your testing is through.

What about all of those other settings?

The remaining tabs are for a more advanced audience, so I won’t explain them setting-by-setting. I will tell you basically what they are for, and link to more information where appropriate.

These tabs fall into two categories: those that are related to the operation of LiteSpeed’s cache, and those that relate to other types of site optimization.

Beginner's Guide to LiteSpeed Cache for WordPress: LSCache Settings Other Tabs

Cache-related settings


ESI stands for “Edge Side Includes” and is a method through which you can “punch holes” in public content, and fill them with private or uncached content. It’s useful for things like shopping cart widgets and personalized greetings, but we keep ESI disabled by default. Go in-depth here.


As you might guess from the name of this tab, it’s aimed at more experienced users. You are not likely to need this tab, unless you have some kind of conflict with another cache plugin. See the wiki here.


This isn’t a tab you’re likely to use just for fun, unless you’re into examining logs. If you’re having trouble with something, we may suggest you visit this tab and flip a couple of switches so we can better see what is going on. See the wiki here.


We keep the crawler disabled by default. When it’s active, it travels your site, refreshing any pages that may have expired from the cache. Crawling can be a resource-intensive process, and not all hosting providers will allow its use. If your hosting provider does allow crawling, it’s a nice way to keep your cache fresh. Go in-depth here.

Optimization settings


There are several other measures you can take to speed up your WordPress site, and LSCache supports many of them in this tab. CSS and Javascript minification and combination, HTTP/2 push, asynchronous and deferred load… if you don’t know what these things mean, don’t worry. We have them disabled by default. See the wiki here.


Among other things, the Tuning tab gives you an opportunity to further refine the settings you selected in the Optimize tab. For instance, you may want to minify all of your CSS, except for one particular style sheet. You can list that CSS as an exception on the Tuning tab. See the wiki here.


Another way to optimize your site is by making images less of a burden to transmit. LSCWP supports two methods of achieving this: Lazy Load, and Image Optimization. We have both options disabled by default, and you may configure them on this page. See the wiki here. Go in depth on Image Optimization here.


This tab allows you to configure your Content Delivery Network for use with WordPress. If you use Cloudflare, do not use this option. It’s meant for reverse proxy CDNs, not distributed proxy servers like Cloudflare. If that last sentence made no sense to you, don’t worry about it. We have CDN support disabled by default. See the wiki here.

What now?

Now, you sit back and watch your site load more quickly 😀

If you’re feeling adventurous, you can start looking at some of those other features we glossed over. We have a wiki that provides explanations of every setting, and you can explore previous WordPress Wednesday topics for more in-depth discussions of some of them.

If anything we covered was not clear enough, or you feel the need for additional help, please don’t hesitate to leave a comment here or post on our WordPress support forum. We enthusiastically support this plugin and are happy to answer any of your questions!

Have some of your own ideas for future WordPress Wednesday topics? Leave us a comment!

Don’t forget to meet us back here next week for the next installment. In the meantime, here are a few other things you can do:


Related Posts