Cache Tab

Enable Cache

ON/OFF/(Use Network Admin Setting)

This is the third and final level for enabling the caching functionality of the plugin. (If you have not completed the previous steps, please see here for instruction.) When enabled, the cache plugin will cache pages. Disabling will stop any caching from occurring and purge the cache of all WordPress cache entries.

For single site installations, only ON and OFF are available. For Multisite Subsite admins, there is a third option, Use Network Admin Setting. This last option uses what the Network Admin chooses.


If you are seeing a warning that LSCache is disabled, and you can't make it go away, please see our troubleshooting instructions.

Cache Logged-in Users


This setting allows content to be cached for logged-in users. Pages will be stored in private cache by IP/session ID.

Cache Commenters


This option is useful for the WordPress option that requires moderation on guest comments. If that option is set, this option will serve the cached version of the page, meaning the commenters will not see their under moderation comments. If off, commenters will not be served from cache.



This option allows you to cache requests that are made by WordPress REST API calls.

Cache Login Page


This option will cache the login page. Normally, there is no reason to uncheck this option. However, if there is something that may identify a user on the page, this should be off.

Cache favicon.ico


This option will cache the favicon.ico response if it does not exist. The reason for caching this is because if the file does not exist, it will load WordPress every time. This will avoid that extra call.

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. If they are in fact dynamic, this should be off.

Cache Mobile


This option enables users to display a 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.

The list of Mobile View User Agents must not be empty when this is on.

List of Mobile User Agents


If Cache Mobile is set to off, this text box will be grayed-out. Once enabled, this list should be filled in with a rewrite-rule-friendly list of user agents.


Each entry should be separated with a bar, '|'. Any spaces should be escaped with a backslash before the space, ' '. The default list WordPress uses is Mobile|Android|Silk/|Kindle|BlackBerry|Opera Mini|Opera Mobi

Private Cached URIs

empty string

A list of path patterns that should never be publicly-cached. To indicate the beginning of a string, add ^ to the beginning of the string. To do an exact match, add $ to the end of the string.

String Matching Examples

Assume you have the following URIs:

  1. /recipes/baking/
  2. /recipes/baking/cakes
  3. /recipes/baking/brownies
  4. /popular/recipes/baking/

The string /recipes/baking/ will match all four URIs.

The string /recipes/baking/$ will match #1 (because $ indicates exact match).

The string ^/recipes/baking will match #1, #2, and #3 (because ^ indicates the beginning of the URI).

Force Cache URIs

empty string

Paths containing the listed strings WILL be cached, regardless of any "non-cacheable" settings that may appear elsewhere. One per line. Each string will be compared to the REQUEST_URI server variable. If there is a match, the URI will be cached. To indicate the beginning of a string, add ^ to the beginning of the string. To do an exact match, add $ to the end of the string.

Force Public Cache URIs

empty string

Paths containing the listed strings WILL be cached in public cache, regardless of any "non-cacheable" settings that may appear elsewhere. One per line. Each string will be compared to the REQUEST_URI server variable. If there is a match, the URI will be cached. To indicate the beginning of a string, add ^ to the beginning of the string. To do an exact match, add $ to the end of the string.

Drop Query String

empty string

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

Some query strings, particularly 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. As such, it should not be necessary to store multiple copies of the page in the cache. Learn more.


Default Public Cache TTL


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

The default value amounts to one week. Other possible values are 1 hour (3600), 1 day (86400), 2 weeks (1209600) etc. Since most of these pages will not change once posted, a longer TTL may be beneficial.

Default Private Cache TTL


This TTL setting determines how long private pages are cached. Possible values are between 60 and 3600.

Default Front Page TTL


This TTL setting controls the front page.


This can be triggered by the is_front_page() check, or by a third party plugin that chooses to use the front page TTL for one of its own pages. For example, WooCommerce does this with its Shop page.

The default value amounts to 30 minutes. The front page tends to be the most often updated page, but is also the page that most visitors will see. For these reasons, it may be more beneficial to use a short TTL. That said, if the site is not updated often, longer TTLs may be used.

Default Feed TTL


This TTL setting controls the feeds. Feeds are a great way for readers to stay up to date on blog entries. They are generally set up to pull from the blog in intervals, which, without caching, could cause a constant load on the server. Cached feed pages are purged on update and on comment, so they are guaranteed to remain up to date. Possible values are 0 or more. 0 indicates do not cache, < 30 seconds will be set to 30.

Default REST TTL

Default HTTP Status Code Page TTL

403 3600 404 3600 500 3600

This TTL controls the pages that return 404, 403, 500, or whatever status codes you specify.

The default TTL for each of the default status codes is 3600, or one hour. There is no real recommended value for this TTL because it depends on what happens to the site. If visiting 404 pages is a common occurrence, it may help to cache the page for at least a short period.

Pages returning 403 are usually intentional, so it may be worth while to have a longer TTL for this setting.

500 Errors are a more severe error. Caching this page may mask an issue within WordPress, so that may not be desired.

Purge Tab

Purge All on Upgrade


This option selects whether to purge all pages when any plugin, theme, or the WordPress core is upgraded. As you never know what may change across versions, it's highly recommended to leave this on.

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. As such, you can specify which types of pages will be automatically purged every time a post is updated or created.

Which of these pages you choose is dependent on your theme and how posts are displayed on 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, but in most cases, it is best not to check All pages.

To optimize performance, the admin should only check the options that are necessary. For example, with the historical archive, if the site only has a monthly archive and does not have a yearly archive or daily archive, only the “monthly archive” needs to be checked. If the site does not have archive by author, then there is no need to select it as extra checks will only slow down the process.

Scheduled Purge URLs

empty string

You can specify a list of URLs (one per line) 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.

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.

Purge All Hooks

a list of recommended hooks

LSCWP executes a "Purge All" action on the cache when certain WordPress hooks are run. You can change the purge behavior for your LSCWP installation by changing these hooks. For example, if you don't want to purge the cache every time you create a new tag or category, remove the create_term hook from the list. Or, if you do want to purge the cache every time a comment is posted on your site, you could add the comment_post hook.

LiteSpeed recommends you Purge All when the following hooks are run:

See the WordPress Code Reference for a list of available hooks. Many plugins also have their own hooks that you can reference, as well.

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.

To understand why you might want to enable Serve Stale, let's look at how LSCache handles purged pages when Serve Stale is OFF.

  • A user visits a page that has been purged from cache
  • The request invokes PHP and begins the process of building the page
  • 100 more users visit that same page before the PHP process finishes
  • PHP is invoked 100 times, causing serious server load
  • The first user's request completes and the page is newly cached
  • Future visitors are served the up-to-date cached page

Now, let's see what happens if Serve Stale is ON:

  • A user visits a page that has been purged from cache
  • The request invokes PHP and begins the process of building the page
  • 100 more users visit that same page before the PHP process finishes
  • All 100 users are served the previously purged (stale) version of the page with minimal server impact
  • The first user's request completes and the page is newly cached
  • Future visitors are served the up-to-date cached page

This is an option that benefits very busy sites, but has less of an impact on quiet sites.

Should you enable Serve Stale? It depends on what is a more acceptable risk for your site. Weigh the potential for heavy server load (OFF) against the possiblity of serving stale content once in a while (ON), and choose accordingly.

Excludes Tab

Do Not Cache URIs

empty string

Paths containing the listed strings will not be cached. One per line. Each string will be compared to the REQUEST_URI server variable. If there is a match, the URI will not be cached. To indicate the beginning of a string, add ^ to the beginning of the string. To do an exact match, add $ to the end of the string.

String Matching Examples

Assume you have the following URIs:

  1. /recipes/baking/
  2. /recipes/baking/cakes
  3. /recipes/baking/brownies
  4. /popular/recipes/baking/

The string /recipes/baking/ will match all four URIs.

The string /recipes/baking/$ will match #1 (because $ indicates exact match).

The string ^/recipes/baking will match #1, #2, and #3 (because ^ indicates the beginning of the URI).

Do Not Cache Query Strings

empty string

You can eliminate URLs with certain query strings from being cached.


If you don't want to cache any page that is rendered in a purple color scheme, you could enter color=purple in that list (assuming the URL you use to indicate that a page should be purple looks like 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

empty string

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.


To exclude, insert category-slug.


If the category slug is not found, the category will be removed from the list on save.

Do Not Cache Tags

empty string

Tags are treated the same way as categories: cached by default, but ignored if entered by slug (one per line) in this box.

Do Not Cache Cookies

empty string

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.


This option can be more far-reaching than you may realize. If you exclude a cookie that exists on every page of your site, then you are essentially excluding your entire site from being cached.

Do Not Cache User Agents

empty string

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.


Partial matches are allowed.

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.


As of version 1.2, LiteSpeed Cache for WordPress includes Edge Side Includes, also known as ESI.


OpenLiteSpeed does not support ESI functionality. You will need LiteSpeed Web Server Enterprise, LiteSpeed Web ADC, or CDN in order to use ESI.

With ESI, pages may be served from cache for logged-in users.

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.

Public Cache vs. Private Cache

LiteSpeed Cache has built-in public and private caches. In the public cache you will find pages that are exactly the same for everyone. Private caches contain content that pertains only to a specific user specified by his/her IP address and session ID.

ESI allows you to disassemble a full page and treat the pieces differently from each other.

LiteSpeed Web Server allows you to store content in either the public cache or a private cache.

Combine these two elements and you get something very powerful. You get a system that can break apart a page into public and private pieces, cache each piece appropriately, and then re-compose the full-page content from the relevant caches and serve it to a user without ever hitting the PHP backend.

This combination allows you to cache content for logged-in WordPress users. With ESI enabled you can cache a full page, punch holes in it for the private content, and save that content in the private cache.


Example #1: Admin Bar

A logged-in site admin visits the publicly-cached home page:

Without ESI: the request hits the backend, because the admin bar at the top of the page is private content, and as such this page (and every other page on the site, for that matter) cannot be served to the admin from cache.

With ESI: most of the this page is served from the public cache, while the admin bar is served from the site admin's private cache. There is no need to invoke PHP.

Example #2: Recent Posts Widget

A large site with much static content that rarely changes includes a "Recent Posts" sidebar widget on each page.

Without ESI: Every time a new post is published, every single page in the site must be purged so that the widget displays up-to-date data. Re-populating the entire cache requires a crawler to run, or visitors to hit all of the pages of the site.

With ESI: All of the pages in the site can remain cached with a long TTL, while the Recent Posts widget is the only thing that needs to be purged. Re-populating the widget in the cache requires just one visitor to request any page one time.

Enabling at the Server Level

Cache and ESI must be enabled on the web server before you can use it. In a shared hosting environment, your system admin will control if a specific virtual host account has CacheEngine on/off; esi on/off. Consult your system admin to see if ESI has been enabled for your domain.

If you are the system admin, see Enabling Cache for an Individual Virtual Host for further instruction.

Enabling at the Plugin Level

LiteSpeed Cache for WordPress considers all cacheable full pages to be publicly-cached.

When you enable ESI, you allow holes to be punched for content that will either be privately-cached, publicly-cached with its own TTL, or not cached at all.

Once enabled, the following ESI blocks are created by default:

  • Admin Bar
  • Comments
  • Comment form
  • Recent Posts widget
  • Recent Comments widget

Any widget can be an ESI block if you want it to be. By default, ESI is disabled for all but the two widgets listed above, but you can change that in WP Admin.

Navigate to LiteSpeed Cache > Cache > ESI. Set Enable ESI to ` ON`.

This creates the ESI blocks listed above. The blocks are cached by default, unless you disable them via the Cache Admin Bar and Cache Comment Form settings.

ESI Nonce

empty string

List nonces one-per-line that should automatically be converted to ESI blocks. Wildcards are supported.

Vary Groups


Despite its location on the ESI settings tab, the Vary Groups function is not actually related to ESI.

Vary Group functionality combines the concepts of cache varies and user roles: with Vary Groups you can have multiple publicly-cached versions of a single page, based on the permissions of the users who view the page.

(Your list of user roles may vary from those in the image above. That's normal.)

Vary Groups do not change the behavior of your application. They simply allow separate cached copies to be saved for each public view that is already being generated by your app. Without Vary Groups, apps that generate different views for different user roles would need to leave logged-in users uncached, or serve to them from private cache.

Learn more about Vary Groups on our blog.


In some themes administrator functions will appear right on the public pages (like an “edit” link at the end of a post). If you create a vary group for administrators, then LSCache will save two public copies of the page: one with all of the editing permissions displayed on it for anyone in the administrator group, and the default copy of the page without the editing links for everyone else.


A shop has two user roles: retail_customer and wholesale_customer. There are two sets of prices, and three different ways that the site can be viewed: users in the group retail_customers will see the highest prices. Users in the group wholesale_customers will see the lowest prices. Users who are not yet customers will see the default page with no pricing whatsoever. This scenario would require two Vary Groups: one for retail_customer and one for wholesale_customer.

To create a vary group for any user role shown, enter a non-zero value into the box next to that user role. If a user role has a 0 next to it, then it will be served the default cached copy.

There is no significance to the numbers other than the fact that unique views should have unique numbers.

If two user roles share the same view, put them in the same group by giving them the same number.

Widget ESI Blocks


Navigate to WP Admin > Appearance > Widgets and select the widget that you want to turn into an ESI block.

By default a widget is not considered an ESI block (unless it is Recent Posts or Recent Comments, as mentioned above). If you want the widget to be treated differently than the pages on which it appears, set one of the following configurations in the shaded "LightSpeed Cache" area:

Private widget

The contents will be stored in private cache, different copies for each user by IP/session ID. (Examples: a list of recently-viewed posts, or a personalized greeting.)

  • Set Enable ESI to Private.
  • Set Widget Cache TTL to a value appropriate for the contents of the widget.
Public widget

The contents will be stored in public cache, with each user seeing the exact same thing. (Examples: a list of recent posts, or a calendar of upcoming events).

  • Set Enable ESI to Public.
  • Set Widget Cache TTL to a value appropriate for the contents of the widget.
Uncached widget

The contents will not be cached at all, and will dynamically-generated each time they are displayed on a page.

  • Set Enable ESI to either Public or Private (it makes no difference, as long as it's not Disable)
  • Set Widget Cache TTL to 0.

Third Party Plugins

Our ESI implementation supports a few other blocks that belong to third-party plugins. For instance, the WooCommerce shopping cart is considered a private ESI block.

As we mentioned earlier, with ESI enabled, your site pages are now considered publicly-cacheable, because we are able to punch holes for the occasional non-public content. This is true for all native WordPress pages, and for all WooCommerce pages. It is not, however, true with bbPress.

A bbPress page contains so many areas of private data, that it's actually much more efficient to consider the entire page to be private. So, that's what we've done. All bbPress pages are considered private.

If one of your favorite plugins warrants special consideration, please get in touch with us via the WordPress plugin support forum and let us know.

Object Tab

Object Cache


Object Cache is disabled by default. Select ON to enable it and then configure it via the settings described below.


An informational area to let you know the status of your external object cache. If you are getting errors here, please see How to Debug your Oject Cache Setup.



If your object cache is Memcached or LSCMC, set Method to Memcached. If your object cache is Redis, set Method to Redis.



The hostname or IP address used by your Memcached or LSMCD object cache. The default setting should work fine for you, if your Memcached is set up via a TCP connection. If you are using a UNIX socket, Host should be set to /path/to/memcached.sock. (Substitute the actual path used for your installation.)



The port number used by your object cache. The default setting should work fine for you, if your Memcached is set up via a TCP connection. If you are using a UNIX socket, Port should be set to 0.

Default Object Lifetime


The TTL for items stored in the object cache. We recommend using a relatively short time in order to avoid stale results.


Only available when SASL is installed and the object caching method is Memcached.


Specify the password used when connecting.

Redis Database ID

Database to be used. This field only appears when the object caching method is Redis.

Global Groups

users userlogins usermeta user_meta site-transient site-options site-lookup blog-lookup blog-details rss global-posts blog-id-cache

A list of groups that should be cached at the network level.

Do Not Cache Groups

comment counts plugins

A list of groups that should not be included in object cache.

Persistent Connection


If enabled, the connection is kept alive in order to make Memcached faster.

Cache WP Admin


If enabled, WordPress admin will be sped up, but at the risk of occasionally retrieving stale data from the object cache.

Store Transients


When Cache WP Admin is set to OFF, transients have nowhere to go. Without transients, you don't receive server status notices (such as XXXX has been completed successfully.). Enable Store Transients to get server notices when Cache WP Admin is disabled.

Browser Tab

LiteSpeed Cache is a full-page cache. It takes expensive-to-generate dynamic content and stores it as easy-to-serve static files. While it handles dynamically-generated content well, it only handles dynamically-generated content. Static content such as images, video, or fonts is not included in any full-page cache. And yet, this content may be requested from the server repeatedly. Take, for instance, your site's logo. That image is likely to be displayed on every page that the user visits, which means the server has to repeatedly transfer that same image to that same user.

This is where browser caching comes in handy. With browser caching enabled, your logo (along with other static content) is stored locally on the user's device the first time it is requested. After that, the content is pulled from their local storage until the browser cache expires. Displaying a local image will always use fewer resources than transferring an image across the internet, no matter how fast your connection may be.

How to Set it Up

Normally, browser caching is enabled at the server level. However, if you do not have access to your server's admin, you can still enable browser caching through the LiteSpeed Cache for WordPress plugin's settings. You can choose to set this up at whichever level makes the most sense for your site(s). If either level is turned on, then browser caching will be enabled.

At the Plugin Level

Browser Cache


When Browser Cache is enabled, static files (such as images, css, and videos) are stored locally on the user's device to make subsequent retrieval much faster.

Browser Cache TTL


The amount of time, in seconds, that files will be stored in the browser cache before expiring. Minimum is 30 seconds. Recommended value is 2592000 (which is 30 days).

At the Server Level

If you are a server admin, you have somewhat more control. In the LiteSpeed Web Server Admin, navigate to Server > General and scroll down to Expires Settings.


Set Enable Expires to Yes.

Expires Default may be set to a number of seconds or left blank if you don't wish to provide a catch-all expiration.


Be careful with this setting. It applies to all types of content, even HTML. This causes potential conflicts with LSCache, and can result in stale content being served to the user. If you are running LSCache, always leave **Expires Default* unset.*

Set Expires by Type to a string similar to the example above, changing any file types or expiration times as desired. The example enables browser caching for all images, css, and javascript, and it sets all of their expirations to 604800 seconds (or one week). If you leave Expires Default blank (as you should, if you're using LSCache), then you must specifically include every file type you want cached by the browser in Expires by Type

Advanced Tab

Check Advanced Cache


This option can be unchecked if another cache plugin is used for non full page caching purposes. For example, the other plugin can be a database cache, minification plugin, etc.


If another cache plugin is not being used, it is recommended to leave this on.

empty string

This option should be used to configure a unique login cookie if multiple web applications with an LSCache plugin are used in a single virtual host.


An example login cookie is _wp_login_1

Improve HTTP/HTTPS Compatibility


When a site uses both HTTP and HTTPS, conflicts with the login cookie may occur. Cookies are based on domain name, regardless of protocol, however an HTTP connection can't read a cookie that was saved with HTTPS. And so, if a user logs in with HTTPS and then connects with HTTP, the user will be treated as a guest, and not as a logged-in user.

When you enable this option, the login cookie is saved as an HTTP cookie at all times, regardless of the protocol used to access the page. This ensures that the login cookie is always accessible to both HTTP and HTTPS connections.

Instant Click


It takes time for a user to click a link. First they hover over it, then they depress the mouse button, and then, only after the button is released, is the link considered "clicked" and the new page loaded. With Instant Click enabled, the page begins to load as soon as the user hovers over the link. By the time the mouse button is released, enough of the page has been loaded that the display can seem almost instant.

Be aware, though, that this function will generate extra requests to the server, if your visitors do a lot of link hovering without clicking. As such, it has the potential to impact server load.

WooCommerce Tab

If you don't see this tab on your LSCWP Settings page, then you don't have WooCommerce installed and activated.


It is highly recommended that you enable ESI while using WooCommerce. ESI allows flexible caching of mixed public and private data in an ecommerce environment.

Product Update Interval

Purge product on changes to the quantity or stock status. Purge categories only when stock status changes.

Use this area to specify how aggressively you wish to purge the cache when a product's stock status or quantity in stock has been updated. Which should you choose? It depends on your store's configuration and theme.

  • If you don't use quantity or stock status in any meaningful way, then it's safe to do a minimal amount of caching tied to stock events.
  • If you display stock quantities on your product pages and your category pages, you'll want to purge both pages any time a stock event occurs.

Use Front Page TTL for the Shop Page


Checking this option will force the shop page to use the front page TTL setting.

Privately Cache Cart


If this option is on, than a cart that is not empty is stored in private cache. If the options is turned off, then a full cart is not cached at all.

Last update: June 3, 2020