LiteSpeed Cache Setup Guide for WordPress

Click on the screenshot above to see how to install the LiteSpeed plugin on your WordPress site

If you already have it installed, please go to 'General Settings' as shown in the screenshot above (click to enlarge).

Try to leave ON or OFF, as appropriate, the indicated fields. If it is not written, please add fbclid, gclid, utm* to the 'Ignore query strings' field as shown in the screenshot.

Within the 'Browser' tab, you must activate (ON) cache generation.

If you have WooCommerce, try to disable (OFF) the 'Cache cart privately' option in the WooCommerce tab.

If your server supports the excellent service of cloudflare (such as Duplika), you must – and it is clearly in your best interest – to activate this option by filling in your account details.

If you have questions regarding this and you are hosting your site with us, please do not hesitate to write to us at [email protected]

The indicated configurations must be deactivated (OFF).

Within the 'Optimization' tab, it is recommended to activate the elimination of Emojis as indicated in the screenshot.

On the configuration screen of General Options:

• Automatic update: our recommendation is that trusted plugins can always be updated automatically (ON). The reason: it is not only convenient to have the latest version of our important plugins for performance reasons but also for security reasons (it is common that different patches emerge over time exclusively to solve holes where malicious users could enter our site… All because of a plugin). On the other hand, LiteSpeed is updated so frequently that it would be annoying to have to perform a manual update every so often.
• Notifications: OFF.

Leave everything else as is.

On the configuration screen of Cache:

•  enable cache: ON. Without this we are sound.
• Cache logged in users: OFF (only enable if our site (1) has few users logged in at the same time AND (2) these users browse different content AND (3) are regular visitors to our site. Otherwise, LiteSpeed would create cache for private pages little or not visited at all) .
• Cache commenters: a function that does not contribute much. better leave it on OFF.
• Cache REST API: the same as in the previous case; in general it will not contribute much but in any case we will leave it ON just in case Check, after activating and accepting the changes, that the site works normally.
• Cache login page: Since malicious bots that browse the internet looking for security holes often attack login pages, it's best to leave this option on ON. Only deactivate if said page presents anomalies in the design, in some function or in the captcha. special note: many admins move the url /wp-admin either /wp-login to a different URL. If you do that LiteSpeed will not be able to protect your login page…
• Cache Favicon.ico: ON.
• Cache PHP resources: ON. This feature is especially useful for themes and plugins with poorly debugged code and/or programming errors.
• Mobile Cache: OFF unless your site has an AMP version or mobile-specific design/content (Important note: responsive design is NOT the same as having deferred content for mobile devices; therefore, in this case it will also remain OFF).
• List of mobile User Agents: only use when the previous option is also ON (AMP cases or mobile deferred layout such as those supported by Elementor and Astra 3.0). This list allows you to add more devices if you see fit.
• Privately cached URIs: never used. It's for pages that need to be cached separately for each visitor (assuming each visit browses different content). The number one example of this is user profile pages, but caching this is not critical when there are few logins to a site. On the other hand, we can assume that a client and/or faithful user will be indifferent to the milliseconds of loading at the beginning of the session.
• Force cached URLs: the pages in this list will have their version cached yes or yes (regardless of other global settings or rules where exceptions exist).
• Force public cache URIs: similar to above; urls in this list will be forcibly cached in the public cache regardless of any "uncacheable" settings that may have been configured elsewhere.
• Ignore query strings: extremely useful to avoid cache generation for certain query strings. Ex: some query strings do NOT change the content, unlike those that change the language or a currency. Typical query strings that do not modify content and should therefore be listed here are those that incorporate trackers such as Facebook, Google and cookies. We recommend that these three lines be listed: fbclid, gclid, utm*, _ga.

Ignore all options as follows:

• Default TTL of the public cache: Do not touch.
• Private cache default TTL: Do not touch.
• Default TTL of the Main Page: Do not touch.
• Feed default TTL: Do not touch.
• REST default TTL: Do not touch.
• Default page status code TTL: Do not touch.

Configure the following options as indicated below:

• Empty all on update: ON.
• Auto-flush rules for publish and update: the options that are checked by default are the most used. You can uncheck the options that are never updated when new posts are made. On the other hand, if your site has widgets in Posts or you regularly receive comments, check “All Pages”.
• Serve stale content: OFF.
• Scheduled flush URLs: The URLs you add here will be purged at the time you set in the option below, “Scheduled emptying time”.
• Scheduled emptying time: you simply decide at what time the cache will be cleared from the list of the upper option
• Empty all hooks: the URLs listed here trigger a purge of the site every time certain actions are performed. The default values should not be touched, as they directly affect the design of the site. Here you can add other hooks from other plugins if their features affect the design of your site (if you don't know how to add links, just manually purge the cache every time you make changes that will reflect in the visible part of the site).

These options are rarely useful on common sites. The useful thing here is to be able to exclude certain pages from the cache (the rest of the functions are usually used for measurements and diagnostics).

• URIs to not cache: to exclude pages from the cache. (We recommend listing here pages that have contact forms, pages that users see when logging in, and checkout pages, although for WooCommerce the checkout page is excluded by default.)
• Query strings to not cache: exclude certain query strings from the cache (useful for certain cases where a query string frequently updates content).
• Categories not to cache: easy, here you can list categories of content/products that for some reason you don't want to be part of the cache.
• Tags not to cache: same as the previous item but for content tags.
• Cookies not to cache: exclude certain cookies.
• User Agents not to frisk: list here user agents that you don't want to cache.
• Do not cache profiles: Exclude specific user roles from the cache. You don't need to check anything, unless you are caching private/registered user pages.

Thanks to ESI (Edge Side Includes), pages can be served from the cache to logged in users. The advanced function of ESI allows us to generate dynamic page cache that should not normally be cached. In fact, it is a configuration that is done on the server side by ITs, but which Litespeed nevertheless enables.

Any function, content, and widget can be converted to ESI, allowing you to specifically decide how to cache it: privately, publicly with its own TTL (useful for shorter TTL content), or not cache at all (i.e. respect dynamic gestation). Recommended with exceptions: There are still some bugs that can occur with functions that rely on their own specific triggers and JS. Test at your discretion.

• Activate ESI: just put it on ON if the use that this has and what it is for is correctly understood (see ESI here inside the official documentation).
• Cache admin bar: ON.
• Cache comment form: ON.
• ESI Nonces: so that certain plugins that use nonce security functions will not have problems with private caching.
• Variation groups: do not change this setting unless you fully understand what it is for.

This is the same function fulfilled by those lines of code that mention expiration (expired) found in the file .htaccess at the root of the site (some plugins also perform this function).

We remind you that this function allows a browser to use its own cache already created on a computer or mobile device in a user's previous visit (a returning user would browse the files already downloaded on their own device rather than download all the information again) .

• Browser cache: ON.
• TTL browser cache: We recommend a number between 2592000 seconds (which is 30 days) and 31557600 (that is 1 year).

Although these settings are intended exclusively for advanced users (read people already familiar with the inner workings of a server), we will explain each item.

• Access cookies: it is only necessary to complete it if you have several sites that share the same domain name (one in a subdirectory). Entering a unique identifier is required so that LiteSpeed does not mix visits from one site to another.
• Improve HTTP/HTTPS compatibility: must be in OFF and, on the other hand, your site should only enter through one protocol (eg: HTTP must redirect to HTTPS when there is an SSL certificate). If you can enter your site by typing both HTTP and HTTPS without redirection, in addition to being a serious security problem, write us in the comments so that we can help you.
• Instant Click: OFF. Enabling it means that a page starts downloading in the background when a user hovers their mouse cursor over the corresponding link (ie they don't have to click for the download to start). You can do tests and see how it works for you (taking into account that you are going to increase the use of your hosting resources because it is enough for the mouse to slide over links/buttons so that the sections where they lead are downloaded, beyond the user going to actually enter or not). Note: this feature can cause inconvenience with shopping carts. It can also conflict with cookie tracking when there are ads or affiliate links.

These settings make sense when your site works in conjunction with a CDN service like Cloudflare.

• QUIC.cloud CDN: Quic.cloud provides features like HTML caching on the CDN itself (useful when your server is slow and/or doesn't provide LiteSpeed from the server), image compression (if you want to use LiteSpeed compression instead of ShortPixel or others), generate CSS critical (not recommended), CDN for static assets (if you don't use another CDN service like CloudFlare). You can learn more about Quic.cloud here.
• Use CDN mapping: ON if you use a CDN other than CloudFlare or Quic.cloud.
• CDN-URL: enter the web address of the CDN network along with the types of files to include. You can add multiple CDNs (for example, if you use one service for images and a different one for videos). If multiple CDNs are used for the same assets, the service will be chosen randomly.
• HTML attribute to replace: it is not necessary to touch anything (in any case items could be added).
• original url: don't touch unless your site spans multiple URLs, such as multiple sites or multi-language sites, where multiple domains or subdomains are used.
• Directories included: the values that come from gabrica are usually enough, but if it is necessary for your site you can include others.
• Exclude route: to exclude any directories found in the list of directories included in the previous field.
• Cloudflare API: for Cloudflare users only. Enter your email, global API key, and domain here to have LiteSpeed purge Cloudflare's cache at the same time it purges its own. If you host your site with us, write to us if you have any questions.

To activate these features you must have the Cloudflare API active in the CDN configuration.

• Cloudflare: You don't need to touch anything.
• Development mode: you can turn this mode on when you make design and content changes to your site (useful for changes to be reflected without delay).
• Cloudflare cache: It only allows you to clear the CloudFlare cache but not the LiteSpeed cache (useful when changing images or other elements that you need to see reflected on the site immediately).

It is worth highlighting the power and speed that LiteSpeed's image compression service brings. Easy, powerful, and free. It does what any other specific image compression plugin does, and better. Below we explain what each button does.

• Collect image data: click to request bitmap compression.
• Download images: you can download here the optimized images to your site.
• Clean unfinished data: click here if you notice that the compression processes have been hung.
• Calculate the disk space of backups: is a tool that tells you the size of the backup folder. It is convenient for you as maintenance to download these files to your computer to save space on the server.
• Delete all backup copies of the original images: irreversible. What it does is delete the images you originally uploaded to the site, leaving only the compressed copies.

• Automatic request cron: ON if you want your site to automatically request optimization for all newly uploaded images.
• Auto fetch cron: ON if you want to automatically download the optimized images to your site.
• Optimize original images: ON. A copy of the images prior to compression will always be saved.
• Delete backup copies of the original: OFF unless you need space on the server or you are 100% satisfied with the compression work and the appearance of the images that result from LiteSpeed compression.
• Lossless Optimize: it is a non-destructive compression method. The images look better but weigh more, and therefore it is not the most used method on the planet.
• Preserve EXIF/XMP data: OFF, unless you need your site to display that information (for example, on sites dedicated to photography).
• Create WebP versions: ON. We thoroughly explain the new image compression formats here.
• Replacing WebP images: ON.
• WebP attribute to replace: the way to be able to control which images will be replaced by the WebP format. It is a way to save space on the server by using WebP for certain images only (eg: large images, or images that use transparency).
• WebP for src extra: how to enable WebP formatting for non-natively managed images with WordPress.
• WordPress Image Quality Control: the default is 82 and this is a good compression standard. It can be modified to test and find the best compression based on the complexity/simplicity of images on our site.

Here let's take some time to entertain ourselves since there are several functions available. However, we recommend trying each option individually because If something breaks on the site, it is most likely that the problem is generated here.

The vast majority should not activate minification or merging via LiteSpeed because they are processes that slow down the server (it is much better to do it from cloudflare occupying other people's resources). For the rest, combining all the CSS and/or JS can cause problems without really improving the speed of a site much.

With these points clarified, we are going to unravel each available function.

• Minify CSS: OFF (use CloudFlare minification). If it is placed in ON, refresh the page and check that everything works correctly.
• Combine CSS: OFF For caution. If it is placed in ON, refresh the site and control its normal development.
• Combination of external and embedded CSS: includes external CSS and embedded CSS in a combined file as long as Combine CSS is also activated. This option helps maintain CSS priorities by minimizing potential errors caused by combining CSS.
• CSS HTTP/2 push: OFF it is safer since its benefit is negligible.
• Load CSS asynchronously: leave it on OFF; turning it on will help your Pingdom/GTmetrix score but hurt the user experience (and today Google gives a lot of importance to this. Here we explain why).
• Generate Critical CSS: OFF. Activating it brings visual problems in many Themes. If you activate it, it will reflect the page and check that everything looks good.
• Generate critical CSS in the background: uses the apache cron module to generate critical CSS in the background. It is activated or deactivated in accordance with the previous item.
• Distinct CSS Cache Content Types: if you enable critical CSS you will need to list each post type that has its own layout and CSS (example: WooCommerce product and category pages, pricing table pages, etc.).
• Different CSS cache URIs: similarly to the previous option but for unique URL addresses (they can be pages specifically dependent on a plugin).
• Async built-in CSS library: OFF. Authentic CSS always blocks content and that is contemplating in the new Google measurement guidelines.
• Font display optimization: from a user interface point of view, we recommend using 'Default' or 'Block'. Never activate 'sawp' or 'fallback' because you will have problems with text styles flashing during load.

• Minify JS: OFF (use CloudFlare minification).
• Merge JS: OFF it is safer; if placed in ON carry out meticulous tests of all the functionalities of your site.
• Combination of external and embedded JS: if the above item is activated, we recommend you to activate this one too: it helps to maintain the execution priorities of JS which should fix potential errors caused by combining JS.
• JS HTTP/2 push: OFF it's more secure plus on most sites turning it on doesn't improve speed.
• Defer JS loading: OFF it is safer. Some JS is used for critical elements above the 'fold' and thus should not be deferred.
• Load Embedded JS: downloads the embedded JS after the DOM is complete to improve JS compatibility and reduce JavaScript errors if all other features are enabled. 'Deferred' is recommended only if one is willing to try all the functionality of the site after having activated it.

• CSS/JS Cache TTL: OFF it is safer. You can lower the time if you are making a lot of changes to your site, or extend it when you are not working on it.
• Minify HTML: OFF (take advantage of this by activating it in CloudFlare).
• Prefetch DNS: A good strategy for speed is to preload DNS for external domains so that they are accessed faster when URLs to them are clicked or when your site loads external assets from them. To find out what to add, browse your site in Chrome Incognito > Inspect > Fonts… (more on Incognito here). In the countryside prefetch write all the external domain sources that Incognito shows you (google analytics calls, TTFs, social media elements, chat services, CDN, etc.).
• DNS prefetch check: being that you have added the urls in the field of the previous item, it is not necessary to activate it.
• Remove query strings: there is no improvement in enabling it (cache can handle query strings already). Those who enable it do so to receive a better score in speed tests. Only turn it on if you're done designing your site's framework.
• Load Google Fonts asynchronously: activate it, but test that the fonts are displayed correctly.
• Remove Google Font: prevents external Google fonts from loading on your site. The only reason one would enable this option is if they have placed the font files locally on the server itself and made the necessary CSS adjustments.
• Remove emojis from WordPress: ON. It removes a little emoji JS call that is useless nowadays since modern browsers can display emojis natively.
• Remove the Noscript tag: just remove the tags

• Delay loading images: loads images only when the browser scrolls to them (hidden images on screen are not loaded). It is a personal option because scrolling and images taking time to appear may not be the most convenient from the user experience. If we have to tilt the balance to one side, it would be to OFF.
• Basic Image Placeholder: This is what users of our site will see moments before the images finish loading (a transparent image can be used).
• Adaptive placeholder: ON if you have decided to delay loading images above. It is convenient to reserve the space to prevent the design of our site from moving from one side to another as the images load (this Google considers it as a negative aspect).
• Responsive SVG Placeholder: the image file to be used as a placeholder.
• Adaptive Placeholder Color: its name indicates it. Choose the color you want
• Cloud LQIP Generator: advanced placeholder technology that displays a very low quality version of the image that will soon be replaced by the original version of the file. It's ideal for improving the user experience on image-heavy sites: the blurred version loads instantly and reduces the distraction caused by lazy-loading images. It is an excellent option compared to other technologies.
• LQIP Quality: 4 is correct but tests are always welcome.
• LQIP Minimum Dimensions: leave it at the recommended value.
• Generate LQIP in the background: It is recommended to test ON versus OFF on pages outside the cache. In principle, and without proof, leave it in ON.
• Delay loading iframes: useful in cases where there are iframes or video embeds that are not used above the fold.
• Integrated library of images in lazy loading: OFF.

• Delayed image loading exclusions: exclude images in this list from lazy loading. It is a good option for important or most viewed images.
• Excluding class names for lazy loading images: allows to exclude from lazy loading all those images that share a class name.
• Parent class lazy loading exclusions: a good resource for excluding images that don't have a CSS class assigned; instead, it is excluded by its parent class.
• iframe class lazy loading exclusions: great way to exclude certain videos from lazy loading (such as those used near the top of your site) or ones that take longer to load and you don't want to slow everything down because of their weight.
• Iframe parent class lazy loading exclusions: convenient for excluding iframes with the parent class names you list.
• Exclusion of lazy loading URIs: here you can list URLs where you don't want lazy loading to take place (for landings where images/videos need to load right away).
• LQIP Exclusions: images you list here will not generate a low-quality preview waiting for the final image (you can use full URLs or partial strings).

• Gravatar Cache: useful for sites where (1) comments are made daily and (2) tons of them. Not recommended if your site does not have comments enabled or few are made per week.
• Gravatar Cache Cron: if you cache gravatar, this option should be ON also.
• Gravatar Cache TTL: the default is 604800 seconds (a whole week) and it's not bad but a higher value is recommended since it's rare for people to change their Gravatar's avatar often. Therefore, 7257600 is a figure more in line with reality (three months).
• Localized resources: it is favorable to put it in ON when Google measurements suggest optimization of JavaScript and/or other resources that are hosted on domains like Google itself or Facebook (we actually have no control over these resources because they are not on our server). Placing this option in ON, these external resources will be copied to the own server (and can be optimized as desired).
• Localized domains: if the above option is ON, typical external resources to be replaced with local URLs are listed here.

• Exclude CSS: In this field you can list the URLs of all the CSS files that you do not want to be minified or merged. You can also list the full name of the classes (eg “elementor-builder.css”) and even a partial name (eg “elementor”).
• Exclude JS: ditto above. Leave the ones listed by default.
• Critical CSS Rules: If you have enabled the “Load CSS asynchronously” feature within the CSS settings, copy and paste any critical CSS rules into this field to ensure they are loaded with priority.
• Generate Critical CSS: this option only works together with “Load CSS asynchronously”. Must be ON to allow communication with the QUIC.cloud CSS service.
• Generate critical CSS in the background: takes advantage of Apache's CRON function to enqueue critical CSS generation. leave it on ON.
• Distinct CSS Cache Content Types: you can list in this field the types of content that have their own CSS. For example, if all Pages on the site have unique CSS, type 'page' (without the quotes).
• Different CSS cache URIs: you can list in this field the URLs of pages to exclude from all optimization. This field is useful to list those pages where the design is broken or its functionality is altered.
• Async built-in CSS library: leave it ON. This feature integrates the asynchronous CSS library in order to avoid rendering blocking.
• Font display optimization: These options allow you to add font-display to all the rules @font-face before creating the CSS cache to determine the display of fonts while downloading. It is recommended to choose SWAP.

• Clear all: run all the optimizations you see on the screen.
• SPAM Comments: it may be convenient to take a look at them before deleting them in case there are false positives.
• All transient data: it is recommended to delete them.
• Ticket Reviews: delete all the historical revisions of the Posts (remember that WordPress keeps an “undo” list to recover a post to a previous stage.
• Comments sent to the trash: delete all comments inside the 'Trash' folder.
• Optimize Tables: activate it.
• Automatic Drafts: perhaps it is better to take a look at it before deleting it.
• TrackBacks/PingBacks: delete them, if they exist.
• Clean the CSS/JS optimizer: run it without hesitation.
• Entries sent to the trash: delete existing Entries in the 'Trash' folder.
• Expired transient data: Delete them without hesitation.

• Maximum number of revisions: you can set a limit if your site's database is too large, with many posts and thus extensive revision history. Leave at 0 if you keep your site clean; otherwise, enter a larger number (10 or 20).
• Maximum age of revisions: you can set it to automatically delete reviews after a certain time (eg 7 days). I do not recommend touching it because a Post could have an error and the review system works as a backup.

Note: This section doesn't have much effect unless you have a dedicated server. Most hosting providers with LiteSpeed enabled will not turn on the tracker option to preserve resources (and you will see the legend “The crawler feature is not activated on the LiteSpeed server. Please consult the server administrator“).

The vast majority should not touch anything in this section unless they intend to crawl more aggressively.

• Reset position: reset if you want it to start over from the beginning (typical after a full cache purge).
• Run manually: crawling is started on the spot (instead of waiting for CRON to rule).
• Clear the Crawleo map: a crawl map is like a sitemap but crawler version. You can clean it whenever you want or need to generate a new one (for example, after adding new content pages).
• Refresh the Crawleo map: it is probably positive to do so after making changes to your site or after executing the previous option. After this action you will be able to see which pages are crawled or not, and add those that should not be automatically crawled to the blacklist.
• Blacklist: delete if necessary.

In this section you can view the URIs that are currently on the map as a result of the tracking.

If you don't see anything listed, try pressing the 'Reload Tracker Map' button.

From here you can manually add URIs to the blacklist using the corresponding button next to each entry. The 'Crawler Status' column uses colored dots to make it easy to read the Status of each of the URIs. If necessary, the 'Empty Tracker Map' button does a clean slate.

In this section you can view the URIs currently on the blacklist. Any URI can be manually removed via the button next to each entry.

The 'Status' column uses colored dots to provide the status of each URI. If necessary, the 'Empty Blacklist' button performs a clean slate.

• Crawler: ON to enable automatic cache creation. It uses server resources, so it is not recommended in cases of shared and/or saturated servers. On the other hand, if you have a dedicated server, you should inhabit it without hesitation.
• Delay: the default value is best for the vast majority of cases. Only adjust if your site has more than 30,000 entries or pages.
• Execution duration: the default value is correct for most cases (only increase it for priority sites in dedicated server scenario with more than one own site).
• Interval between executions: the default value is fine for most cases (just lower it for priority sites and/or when the server is down for frequent periods).
• Indexing interval: the recommended default value of 302400 (3.5 days) is indicated. It is possible to force it up to 86400 (1 day) if your site is small (less than 3000 pages) or if you have your own server.
• Threads: the default value of 3 is recommended. Setting a higher number causes faster crawls, but it doesn't matter much unless you have 200 or so pages. Also, it's good to remember that more CPU is used, so don't set this high on servers with many sites and/or high constant CPU usage.
• Timeout: specifies the time to wait while each URL is crawled. The default value of 30 is recommended.
• Server load limit: the default value of 1 is recommended and safe for most servers (enter 2 or 3 if you have a dedicated server).

This section is useful only if you want to pre-crawl pages for logged-in users (the standard crawling feature already covers non-logged-in public users).

• Role Simulation: allows you to pre-cache pages for specific users (enter one user per line if necessary for your site).
• Cookie simulation: pre-track for specific cookies. To track a particular cookie, enter the cookie name and the values you need to track, one per line.

• Custom sitemap: LiteSpeed pre-crawls a site automatically, but here you can add your own sitemap, typically the one generated from the XML sitemap plugin.
• Remove domain from sitemap: leave it on ON unless you have multiple domains in the sitemap (typically for multiple languages).

This area provides valuable tools that allow you to selectively purge things without overloading the CPU. It is very convenient on sites with a lot of traffic, because purging cache chunks prevents thousands of users from suddenly entering a page without cache (slow).

• Empty Home Page: Plain and simple, it allows you to reset the cache of the home page. Useful when in it we have a feed of the latest entries or things like that (and we want the cache to reflect the latest changes). It is also useful when we have made design and/or content changes exclusively on the home page.
• Empty 500 error: does exactly what it says, clears the 500 error cache among many others.
• Purge all, critical CSS: used to reset the priority CSS.
• empty pages: clears the cache created of all content type Pages.
• Purge All – LScache: This button clears the entire cache created by LiteSPeed.
• Empty 403 error: clear the cache of error pages including the 403 error page.
• Purge All - CSS/JS Cache: this button will clear only the minified or combined CSS/JS cache.
• Empty 404 error: clear the cache of error pages including the 404 error page.
• Purge All – Cache opcode: clear the opcode cache to generate it again.
• purge all: clears all cache content created by LiteSpeed except critical CSS and LQIP caches.
• Empty the entire cache: It not only clears LiteSpeed's own cache but also any other cache created by other applications (useful when conflicts between different caches are generated).
• Empty by… : this field allows you to delete Categories/Post IDs/Tags/URLs by selecting the corresponding tab and entering the filter values (for example, the name of a Post Category).

This corner of LiteSpeed is useful for testing (and saving) different configurations that one has been shuffling over time. It even allows us to export a global configuration to use it in another domain (as long as said configurations lack export site-specific settings). If you intend to take advantage of this function, you must be sure of the exported settings to avoid serious errors on the import site.

• Export: this button saves all LiteSpeed settings to a single downloadable file.
• To import: This button allows you to import the global settings from a previously exported file in the same or a different site.
• Hola: is the button that returns all LiteSpeed settings to their factory default values. Useful if our site has design and/or functionality errors and we cannot determine their cause. So, as we always say, when making adjustments to LiteSpeed (especially when you're not sure what you're doing) you should preferably make one change at a time. Then, delete the previously created caches and test our site from top to bottom.

This tool allows you to view and edit the .htaccess file at the root of a site. Useful because normally to edit this file we use an FTP client or via the server itself. Here we can see the content of .htaccess and perform cleaning, if necessary, with ease.

• Path of the .htaccess of the public part (front-end): the file is automatically detected if we leave this field empty as it is.
• Administration .htaccess path (back-end): the same as the previous item but for the desktop .htaccess.

We recommend getting to know what the WordPress 'heartbeat' controls do before you start tinkering with things.

The heartbeat of WordPress is actually the AJAX call that uses the “/wp-admin/admin-ajax.php” file. Most sites should never have to optimize this call unless for some reason it causes high CPU usage (something that GTmetrix's speed test cascades will promptly show in that case with the file admin-ajax.php).

It should not be disabled unless the file is called abusively from a plugin. It's typically optimized by raising the interval where it is used, but disabling it on pages where it isn't.

There are two current uses of so-called heart beat: auto-saving of content edits and updating of the WooCommerce shopping cart by adding or subtracting products. There are also plugins that use it a lot and everything will depend on the framework of your site. Caution is recommended and be sure that we can disable it (if there are WordPress tasks dependent on admin-ajax.php, they would stop working).

• Heartbeat control of the public part (front-end): ON if we want to change the interval.
• Public part (front-end) heartbeat TTL: set it to 120 seconds if it is still in use, or write 0 to disable it.
• Management heartbeat control (back-end): ON if we want to change the interval.
• Management (back-end) heartbeat TTL: usually the backend is a safe place to disable 'heartbeat' completely. Most functions do not depend on admin-ajax.php on the back end.
• Publisher's Heartbeat: it is strongly recommended to leave this on OFF as WordPress uses it to automatically save your work. That saves you from power outages or accidental window closings.
• Publisher heartbeat TTL: here you can increase the interval if many editors work on your site at the same time. Never put 0 (zero).

• Install DoLogin security: This button installs a plugin that gives third parties instant access to wp-admin using a temporary link (instead of logging in with username and password).
• System information: This field displays a collection of data that is normally requested by the developers behind LiteSpeed when we have a problem. Typically, this information is copied and pasted into an email or contact form in the indicated field (the button at the end of the section, 'Send to LiteSpeed', precisely serves these purposes).
• Link without password: generates an instant access link to the back-end (requires the DoLoin plugin installed; see item one of this section).
• Grades: It is the right place to leave notes of our changes, doubts, variables to test and any comments that help a LiteSpeed developer to help us more effectively.
• Send to LiteSpeed: this button sends a report to LiteSpeed developers. Note: Submitting a report generates a reference number that you can view on the official LiteSpeed support forum.

This is a section that we should never need except when LiteSpeed has debugging problems (debugging). Since it's a rare occurrence, the chances of you needing it are slim to none. However, we are going to explain what each thing does.

• Disable all features: we'll leave it at ON if and only if our site has debugging conflicts.
•  Debug log: leave it on ON to debug. The option 'Only the administrator's IP' is used so that the registry is set exclusively for our current IP (on high traffic sites it prevents a giant debug file).
• Admin IPs: you can add your external IP to run debugging actions from your internet browser.
• Debug level: sets the depth of debugging depending on our case. Usually, essential, although advanced presents even more technical data useful for trained administrators.
• Log file size limit: only increase it on errors of insufficient size.
• Register cookies: activate it to ON if you want to debug cookies too.
• Collapse request chains: Put in ON if necessary (shortening the request strings in the debug log improves the readability of the generated file).
• URIs included in the debug: will log the pages you list in this field (useful if you're having problems on a certain page).
• URIs excluded from debugging: URLs listed in this field will be excluded from the debug report.

Once logging is enabled, you will be able to view the log in this section.

If you can't find any information relevant to the issue your site is experiencing, try reproducing the issue with debug mode enabled (previous section). Then recheck this page to see the result.

Empty log: Click this button when you notice that the log contains too many old entries. The action deletes all but the most recent entries. Note: Playing D on our keyboard also performs the above action.

It is a valuable option when, either out of curiosity or necessity, we are interested in trying out different versions of LiteSpeed. It is common, on staging sites, to alternate between the BETA versions and the latest stable one. It can also be useful to roll back LiteSpeed to a previous version if the latest update conflicts with our site.

• Use the latest GitHub development commit: Click on this button to test the latest version published in the GitHub repository.
• Use the latest GitHub master commit: Click on this button to use the latest stable version.
• Use the latest version of WordPress: Click this button to dismiss the beta test and return to the current version of the WordPress plugin directory.

I don't see any LiteSPeed comments in the source code of my site

It may be that LiteSpeed is not working, but it is also possible that the CloudFlare service has activated the function that deletes comments within the HTML code (and therefore they are not seen in the source code).

Deferred CSS issues (FOUC or FOUT)

Stop using critical CSS generation. Don't merge CSS.

Design issues/broken features

Do not mix JavaScript or CSS. You may also want to try the error isolation methods discussed below.

Problems in the Contact form

If your form(s) stopped working, the most practical solution is to exclude the form pages from the cache generation. Another option is to exclude the CSS/JS of the form from the merge cache (Note: the Contact Form 7 plugin is known to have issues with LiteSpeed).

WSOD or Error 500

Many times the plugins on our site conflict with each other. To fix WSOD or 500 errors try restoring your site by deleting the section LScache in the File .htaccessdelete the files advanced-cache.php Y object-cache.php from the /wp-content/ directory. You can also increase WP memory limits. If you don't know how to perform these steps and you are hosting in Duplika, send us an email to [email protected]

I see the desktop wrong

If the backend fails, it is most likely due to the logged in user cache, private content cache, or object cache. Try disabling all these features and re-enabling one by one until you can isolate the problem (always remember to clear the cache to see the changes).