Cache

Cache Tab

!LSCWP Cache Section 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.

Note

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

ON

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

Cache Commenters

ON

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.

Cache REST API

ON

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

Cache Login Page

ON

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

ON

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.

Info

This setting is moved to the Network Admin screen when used with a multisite network

Cache PHP Resources

ON

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.

Info

This setting is moved to the Network Admin screen when used with a multisite network

Cache Mobile

off

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.

Info

This setting is moved to the Network Admin screen when used with a multisite network

List of Mobile User Agents

disabled/string

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.

Syntax

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.

Warning

The method used is only compatible with LiteSpeed Enterprise v5.2.3+ although one can manually add rewrite rules for OpenLiteSpeed in .htaccess

Info

This setting is moved to the Network Admin screen when used with a multisite network

TTL Tab

!LSCWP Cache Section TTL Tab

Default Public Cache TTL

604800

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

1800

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

Default Front Page TTL

1800

This TTL setting controls the front page.

Note

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

0

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

!LSCWP Cache Section Purge Tab

Purge All on Upgrade

ON

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.

Info

This setting is moved to the Network Admin screen when used with a multisite network

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.

Wildcards are supported.

Warning

For URLs with wildcards, i.e. /a*.html, there may be a delay in initiating scheduled purge. LSCache has no way of knowing which URLs match the pattern until the first time those URLs are purged, or until they reach their natural expiration. If you would like to speed this process along, you can enter the wildcard string in Scheduled Purge URLs, press the Save Settings button, and then manually purge the relevant pages so that LSCache is aware of the URLs right away.

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:

    switch_theme
    wp_create_nav_menu
    wp_update_nav_menu
    wp_delete_nav_menu
    create_term
    edit_terms
    delete_term
    add_link
    edit_link
    delete_link
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

OFF

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

!LSCWP Cache Section 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.

Example

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 http://example.com/page?color=purple). 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.

Example

To exclude http://www.example.com/category/category-slug/, insert category-slug.

Note

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.

Tip

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.

Info

This setting is moved to the Network Admin screen when used with a multisite network

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.

Note

Partial matches are allowed.

Info

This setting is moved to the Network Admin screen when used with a multisite network

Do Not Cache Roles

unchecked

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.

ESI Tab

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

Note

OpenLiteSpeed does not support ESI functionality. You will need LiteSpeed Web Server Enterprise, LiteSpeed Web ADC, or QUIC.cloud 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.

Note

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.

!LSCWP Cache Section ESI Tab

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.

Examples

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.

Nonces often expire before the site TTL, and this can be problematic for the pages that use them. By converting a nonce to an ESI block, you allow the nonce to expire independently of the rest of the page, without causing any cache conflicts.

Fetch Latest Predefined Nonce

LiteSpeed maintains a list of known third party plugin nonces here. Press this button, and the nonces from the list will be automatically appended to the nonces you have already listed in the ESI Nonce box.

This allows you to easily convert every nonce we know about into ESI blocks.

If you have a nonce that you would like to be included in this list, please submit a Pull Request.

Vary Groups

Note

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.

Example

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.

Example

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

!LSCWP Cache Section Object Tab

Info

This tab is moved to the Network Admin screen when used with a multisite network

Object Cache

OFF

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

Status

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 Object Cache Setup.

Method

Memcached

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

Host

localhost

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

Port

11211

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

360

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

Username

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

Password

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

ON

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

Cache WP Admin

OFF

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

Store Transients

ON

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.

!LSCWP Cache Section Browser Tab

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

Info

This tab is moved to the Network Admin screen when used with a multisite network

Browser Cache

OFF

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

2592000

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.

Note

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

!LSCWP Cache Section Advanced Tab

Check Advanced Cache

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.

Example

An example login cookie is _wp_login_1

Info

This setting is moved to the Network Admin screen when used with a multisite network

Improve HTTP/HTTPS Compatibility

OFF

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

OFF

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.

Note

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.

!LSCWP Cache Section WooCommerce Tab

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

ON

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

Privately Cache Cart

ON

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: August 7, 2020