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

November 22nd, 2017 by Cache , WordPress 0 Comments

Welcome to another installment of WordPress Wednesday!

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?

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. The default settings are specifically chosen 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 this page, and come back here 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.


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 it is considered 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 how content is cached and purged, take a look at this article. It’s written at a high-level, so you can get the gist without knowing a lot of jargon.

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 private pages are cached.

Default Setting: 1800
Constraints: Must be between 60 and 3600 seconds
Customization: The default value amounts to 30 minutes. The longest private content may be cached 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 the site is not updated 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 are generally set up to 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 feed pages are purged 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 will be cached. By default, everything aside from Browser Cache is on. This is because browser caching is not a native function of LSCWP, but rather a function of your visitors’ browsers. More on that below.

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

Cache Logged-in Users

Use this option to control whether logged-in users will be served 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 is then reloaded. This setting controls whether users are served 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 are made by WordPress REST API calls. 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, 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 must be loaded 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, this option should be turned 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. This is primarily used for non-responsive themes, but can also be used in situations where different widgets are loaded 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, this list should be filled in 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. Paths will be treated as partial strings to be matched 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

Browser Cache

Technically, this is one of those “optimization features” that we weren’t going to discuss, but since it’s on this page, I’ve made an exception.

Browser Cache is not LiteSpeed Cache. This is an important distinction. Every other setting that we are discussing today is meant to instruct the LiteSpeed server how to handle it’s own full-page cache. This setting, however, is simply our way of enabling a different cache to deal with the files we don’t store.

Enabling this option instructs the visitor’s browser that it should cache static files (such as images, css, and videos) locally on the user’s device. Browser cache makes subsequent retrieval of static files much faster, just as LSCache makes subsequent retrieval of dynamic pages much faster. Same concept, different kind of cache.

Default Setting: OFF – Browser cache support is disabled.
Other Option: ON – Browser cache support will be enabled.

Browser Cache TTL

If you enable the browser cache above, you may also want to specify how long the browser is to cache the static content.

Default Setting: 2592000 – The user’s local browser caches content for 30 days
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.


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

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 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.

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

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

There is an option for All pages, which is disabled by default. When you enable this, all other checkboxes are ignored. 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 specify a list of URLs that will be purged 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. They are provided to allow you to make custom exceptions to the cache rules.

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 where color is specified, regardless of which color it is.

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.

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

Tags are treated the same way as 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

Specific user agents may also be excluded from cache. You can enter them by name in this box, one per line.

Do Not Cache Roles

There may be user roles that you wish to exclude 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.

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. ESI is useful for things like shopping cart widgets and personalized greetings, but is 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.


The crawler is 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 many of them are supported 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. They are 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. Both are disabled by default, and configured 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 CDNs that are reverse proxies, not distributed proxy servers like Cloudflare. If that last sentence made no sense to you, don’t worry about it. CDN support is 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:

Categories:Cache , WordPress

Related Posts