LiteSpeed Cache WordPress Plugin – UNOFFICIAL GUIDE

I don’t know why it’s taken me this long to release a guide for one of my favorite cache plugins. Much of the internet and WordPress speed groups associate me with Swift Performance WordPress Cache Plugin but don’t be mislead, I am very much an equal fan of LiteSpeed web server and its complementing LiteSpeed Cache plugin!!!

LiteSpeed Cache

Learn how to configure this advanced plugin for maximum speed and hassle-free caching!

EDITS:

• APR 28, 2020 – updated to reflect new LSC version 3.x.
• See if you can find my contributions in the changelog. 🙂
• NOV 26, 2021 – updated to reflect new LSC version 4.x. I left some outdated options to make sure they are no longer used elsewhere.

Some background about LiteSpeed web servers:

• LiteSpeed is the 4th most popular web-server behind Apache, NGINX and Microsoft IIS. It’s popular since it has the speed of NGINX but the compatibility of Apache.
• You can run Apache software on it (like WHM/cPanel) and also use Apache configurations (like htaccess).
• It’s popular both for small-time users on VPS as well as large commercial webhosts running off dedicated servers.
• It gives great performance out of the box without much configuration.
• Comes with native-software caching plugins for WordPress, Joomla, Drupal, Magento, and others.
• Also comes with built-in security against brute-force attacks and also DDOS protection.

A little background about LiteSpeed cache plugin (aka “LSC”):

• Fantastic FREE cache plugin that has one requirement—has to be used on LiteSpeed servers (which I absolutely love). On non-LS servers, you can use all of its features except caching (which is the main feature).
• This is a true enterprise-grade caching plugin (incredible for both consumer use and enterprise use). I highly recommend it for any site with massive traffic (over 1 million monthly visitors) and/or many pages (over 1k pages).
• LSC is updated really often. Their developers are extremely aggressive in fixing bugs and issues immediately. Their business model revolves around maintaining their server-clients so they never lag on any critical issues. Any bugs found is usually fixed in a matter of HOURS (not days, not weeks).
• For those not running on LiteSpeed, I like Swift Performance cache plugin as my other favorite cache plugin. Rocket, Breeze, Comet Cache, Cache Enabler and Speed of Light are also all nice as well.

LiteSpeed Cache’s many features:

• Server-side caching (using server to generate cached pages rather than slow PHP)
• Object caching
• Can cache private pages (logged-in users), and admin pages
• Image optimization (yes, for free!)
• CDN compatibility
• Database optimizations
• QUIC.CLOUD – sneaky new feature to serve cache pages via CDN for those not on LS servers!
• And a ton more!

What I personally like about LiteSpeed Cache over other plugins:

• Excellent for sites with massive traffic (my preferred choice)
• Essential for sites with thousands of pages (my preferred choice)
• Has object-caching
• More granular and developer options for caching private content
• It’s a true server-side cache plugin (faster than PHP-level ones)
• Many advanced CSS/JS optimization options (if that’s your thing)
• Free image optimization
• Database optimizations (convert tables to InnoDB & view autoloads)
• New QUIC.CLOUD service in the works

LS & LSC not only speeds up your site but decreases your server usage by a lot—improving performance while saving money!

QUICK Setup Guide

Here’s the 2-minute setup version for busy people. It doesn’t take much to get record-breaking results.

(NOTE: I like my configurations so much better than the default LiteSpeed Cache settings. For full explanation of why I chose these settings, see my DETAILED setup guide below.)

1. Install LiteSpeed WordPress Cache Plugin (free). Then go to Settings from admin side-panel.
2. General > General > Request Domain Key – do this if you plan to use QUIC.cloud services or you want LiteSpeed caching features on a non-LiteSpeed server. For those using LScache on a LiteSpeed server, you can continue without QUIC.cloud integration.
3. General > General > Guest Mode – OFF.
4. Cache > Cache > Enable Cache – turn it ON. If you’re not on LS server, sign up for QUIC.cloud.
5. Cache > Cache Logged-in Users – OFF.
6. Cache > Purge > Serve Stale – OFF.
7. Cache > Drop Query String – type the following 3 entries on a separate line (fbclid, gclid, utm*).
8. Cache > Browser > Browser Cache – ON.
9. Cache > WooCommerce > Privately Cache Cart – OFF
10. CDN > CDN Settings > QUIC.cloud CDN – turn on if you want to use QC CDN.
11. CDN > CDN Settings > Cloudflare API (Cloudflare-users only) – enter email, global API key, and domain.
12. Page optimization > CSS Settings > Generate Critical CSS – OFF.
13. Page optimization > CSS Settings > Inline CSS Async Lib – OFF.
14. Page optimization > Optimization Settings > Remove WordPress Emoji – ON. (Modern browsers already support emojis natively.)
15. Hit [SAVE CHANGES] and you’re flying at light-speed!

Got issues?

• No need to exclude or worry about anything, LSC is fantastic out of the box!
• Are you really so lazy? Here’s my default LSC config if you want. (But you’ll still need to do steps 2, 8, 9 above.)

DETAILED Setup Guide

STEP #1 – Install LiteSpeed WordPress Cache Plugin (LSWCP)

• Install LiteSpeed WordPress Cache Plugin (free).

Requirements:

• You must be running on LiteSpeed webserver OR QUIC.cloud service to use their caching mechanism. For best results, please be on a LiteSpeed server!
• If you’re purchasing webhosting from a 3rd-party service, make sure they’re running on LiteSpeed server.
• If you’re managing your own web-server, make sure you configured the cache roots for LS and also enable crawler function.

STEP #2 – Configure LiteSpeed Cache plugin

Go to settings from admin side-panel. Click on LiteSpeed Cache > General.

I’ve gone through all the settings and leave my detailed thoughts on them below. Anything I forget to mention means I left it at default settings. You can also view official LiteSpeed Cache documentation.

General > General Settings:

• Automatically Upgrade – OFF is safest, but honestly you could totally put it to ON. LSC is built freaken solid; updates have never broken any of my sites (unlike other consumer-grade cache plugins like Rocket or Swift). LSC is updated so often it might be less annoying if you just allow automatic upgrades or else you’ll see update nag screens every week (haha). One little caveat: I’ve seen occasional updates creating issues with their Image Optimization feature, so you might want to avoid automatic updates if your site heavily relies on this feature.
• Domain Key – you can request a key if you plan to use any QUIC.cloud features. It’s basically a big CDN but with many extra features like image optimization (compression, placeholders), generate critical css, page caching at the edge. I only use it for image compression for sites not using ShortPixel. I don’t need the other stuff. If you’re using LSC on a non-LiteSpeed server, then you’ll need QUIC.cloud to benefit from their caching capability.
• Guest Mode > OFF. I don’t suggest using this. It can create problems if you don’t test well. Safer is OFF. But if you want so that page scores or new users to never hit a cold cache, you can enable this. Again…I don’t recommend it. And you don’t need it.
• Server IP > put in your web server IP so LiteSpeed cloud services can call/cache your site quicker. Also reduces the crawl overhead, especially if you have over 1k pages.
• Notifications – OFF for me.

General > Tuning:

• Guest Mode User Agents – automatically displays guest mode cache for these agents. You can add more to improve performance for certain agents. Or also remove agents from here.
• Guest Mode IPs – I imagine these are IP’s of page score servers. You can add more if you know what you’re doing.

Cache > Cache:

• Enable Cache – ON (duh!)
• Cache Logged-in Users – OFF for most folks. Only practical if have very few logged-in users, AND they all see different info, AND they visit the site and log in often! Even then, I prefer to leave this off just in case of potential conflicts. You definitely shouldn’t use this if you have many users; it would create too many cached pages and hardly any will be used.
• Cache Commenters – doesn’t have much effect either way, but I prefer OFF.
• Cache REST API – won’t apply to most of you. Leave it ON, but turn off if any functions break.
• Cache Login Page – ON is faster since bots often attack the login page. Turn OFF if it breaks your login page (design, function, captcha). For those changing wp-login url, don’t do that! LiteSpeed servers natively protect admin urls. Much better performance to let LS shut down brute force attacks than to do it with slow security plugins!
• Cache favicon.ico – ON.
• Cache PHP Resources – ON. Really helps with poorly-coded themes/plugins.
• Cache Mobile – OFF for most sites! Don’t turn on unless you have AMP or mobile-specific design/content. Sites with responsive design doesn’t mean you need this!
• List of Mobile User Agents – leave it alone. It’s only used if “Cache Mobile” is on. Can add other devices here if you feel some are missing.
• Private Cached URIs – never used. It’s for pages that need to be cached separately for each visitor (assuming they each see different content). A good example would be user-account pages, but this caching isn’t necessary if your users don’t log in that much. Besides, they’re users already so they probably don’t mind a tiny bit of extra load time. I also don’t recommend since your server spends extra time building cache and users might not be back anytime soon to take advantage.
• Force Public Cache URIs – pages listed here will be cached. Useful for excluding specific pages from wide-reaching exclusion rules based on string.
• Drop Query String – incredibly useful to avoid unnecessary page-caching for some query strings. Some query strings cause content changes (e.g. language, currency, etc) and should be cached as separate pages. Other query strings don’t cause content changes (e.g. FB/Google trackers, affiliate cookies) and are only used for tracking, so these should be listed. I recommend placing these 3 on separate lines: fbclid, gclid, utm*, _ga.

Cache > TTL:

Safer to leave these all alone. Some can safely be raised if you never ever ever update your site.

• Default Public Cache TTL – don’t touch.
• Default Private Cache TTL – don’t touch.
• Default Front Page TTL – don’t touch.
• Default Feed TTL – don’t touch.
• Default REST TTL – don’t touch.
• Default HTTP STATUS 404 Page TTL – don’t touch.
• Default HTTP STATUS 403 Page TTL – don’t touch.
• Default HTTP STATUS 500 Page TTL – don’t touch.

Cache > Purge:

I never mess with any of these.

• Purge All On Upgrade – safest is to leave this ON.
• Purge Stale – I love the idea behind this (reducing server load during cache purge) but it shouldn’t be used for 98% of sites out there unless you know what you’re doing. Leave it OFF.
• Auto Purge Rules For Publish/Update – default settings are fine. You can uncheck certain options if you know they never get updated when new posts are made. Or you can also check “All pages” to be sure that everything gets purged upon new posts or updates. If you have widgets on blog posts that get new comments regularly, “All pages” would be a good idea.
• Serve Stale – OFF is safest so your site never displays outdated content. But if changes are very minimal and you’re constantly bombarded with heavy traffic, this is a nice way
• Scheduled Purge URLs – used to purge specific URL’s at a specific time.
• Scheduled Purge Time – exact time used for scheduled purge. This feature is for people not using auto-purge, or have content generated from external source that doesn’t trigger auto-purge.
• Purge All Hooks – these listed hooks trigger a site purge whenever certain actions are made. The default ones are should be left alone as they directly affect the site design. You can add other hooks from other plugins as well if they affect your site design. (If you don’t know how to add hooks, just manually purge cache whenever you make site changes that affect the frontend.)

Cache > Excludes:

I almost never use any of these. They only thing useful here for me is excluding certain pages from cache. All the other stuff is probably only for diagnostic purposes.

• Do Not Cache URIs – used to exclude pages from cache. (I recommend listing pages that have contact forms, logged-in pages, or any checkouts. Although WooCommerce checkout is already excluded by default.)
• Do Not Cache Query Strings – exclude certain query strings from cache. Good for certain use cases where some query string pages refresh content often.
• Do No Cache Categories – exclude categories from cache.
• Do Not Cache Tags – exclude tags from cache.
• Do Not Cache Cookies – exclude cookies.
• Do Not Cache User Agents – exclude user agents.
• Do Not Cache Roles – exclude specific user roles from cache. Not necessary unless you’re actually caching private pages or logged-in users.

Cache > ESI:

I love the advanced ESI function in that it allows you to benefit from cache even in (dynamic) pages that shouldn’t be cached. It’s an incredible feature and usually only configurable from the server and never from a plugin…but LiteSpeed is just special like that.

You can convert any functions or content, widgets to ESI and it will allow you to decide specifically how to cache it: privately, publicly with its own TTL (good for shorter TTL content), or not cached at all (remaining completely dynamic). In my few test cases, I found that the function worked perfectly BUT still has some issues for any functions that rely on their own specific triggers and JS functions and such. Test carefully and consult the documentation if you decide to use this.

• Enable ESI – I leave it OFF as I don’t use it much.
• Cache Admin Bar – ON seems safe and logical.
• Cache Comment Form – ON seems safe and logical.
• ESI Nonces – for certain plugins (using nonce security functions) to work seamlessly with private cache.
• Vary Group – don’t mess with unless you understand it.

Cache > Object:

Object caching usually isn’t enabled on servers unless A) your webhost specifically allows it or B) it’s your server and you have Memcache or Redis enabled.

• Object Cache – OFF is safe for most folks. You can turn ON if 1) you have memcache or redis installed, 2) you have lots of dynamic content or database queries.
• Method – Redis is preferred over Memcache.
• Host – should be localhost unless it has another address (probably slower and less ideal to have it on an external server).
• Port – default port should be fine unless you installed on custom port.
• Default Object Lifetime – default of 360 seconds is safe but you can increase if your dynamic content doesn’t get refreshed that fast.
• Username – usually not needed unless you’re using the SASL-secured fork version of memcache.
• Password – usually not needed.
• Redis Database ID – usually left alone unless you want to use different Redis database ID to improve performance on clogged up Redis databases.
• Global Groups – I don’t touch it. You can add more if needed.
• Do Not Cache Groups – I don’t touch it. You can add more if needed.
• Persistent Connection – ON is safest.
• Cache Wp-Admin – I prefer this OFF unless you’re actually using object cache to speed up backend. I usually recommend upgrading server if your backend is so slow.
• Store Transients – should be left ON.
• As for “Persistent Connection”, “Cache WP-Admin”, or “Store Transients”…you can enable or disable these depending on your needs. Safer option is to have all of them off or don’t even use object cache in the first place if you don’t know what you’re doing. Caching WP-admin is tempting considering that the admin area can run slow on heavy sites, but you risk showing outdated information.

Cache > Browser:

This is the same function as those HTML expiry lines in your htaccess or that some other plugins do.

• Browser Cache – I like this ON.
• Browser Cache TTL – anywhere from 2592000 seconds (which is 30 days) to 31557600 (1 year) is fine to me.

Cache – Advanced:

• Check Advanced Cache – usually checked unless you’re using multiple cache plugins together, which I highly don’t recommend. In case you ARE using LSC alongside another cache plugin, you can leave this checked or unchecked depending on which plugin needs or intends to use the advanced-cache.php file.
• Login Cookie – only needed if you have multiple sites sharing the same domain name (one in sub-directory). In this, one site needs to enter a unique lookie cookie identifier so LSC doesn’t mix up which visitors are logged in to which site.
• Improve HTTP/HTTPS Compatibility – should be OFF and you should not be having mixed content anyway as that affects your SSL status.
• Instant Click – I leave it OFF. It’s fun when it works but can be troublesome for many sites. The function preloads links when users hover over it. But can cause high server usage if users hover over many links before clicking. This function may also mess with your cookie tracking (affiliates, etc).

Cache > WooCommerce:

• Product Update Interval – the 1st option is safe. Second is better, and third option is best performance. The last is safest. Ultimately, you can decide based on whether or not A) you actually even track stock quantity, and B) show different store notice on category or product pages based on stock status.
• Use Front Page TTL for the Shop Page – ON makes sense.
• Privately Cache Cart – OFF. I don’t like how it’s ON by default and doesn’t make sense. This feature sometimes caused mixed cart sessions for me. I think caching non-empty carts are a waste as potential buyers don’t hang around for too long anyway. Either they buy or they don’t. And if they plan to buy, I think they can be patient for an extra second.

CDN > CDN Settings:

• QUIC.cloud CDN – I think everyone should register for a free QUIC.cloud account. Whether you should enable it is another matter. I personally don’t. QC has these features: HTML-caching on CDN (necessary if your server is slow and/or you don’t have LiteSpeed server), image compression (if you want to use LSC compression instead of ShortPixel/etc), generate critical CSS (I don’t recommend CCSS), CDN for static assets (if you don’t already use another CDN service), and some others.
• Use CDN Mapping – turn ON if using CDN. (Folks on Cloudflare or QC should ignore this.)
• CDN URL – put in the CDN URL and which file types to include. You can add multiple CDN’s (such as if you use one service for images, but another for videos). If using multiple CDN’s for the same assets, it will randomly choose.
• HTML Attribute To Replace – I don’t touch it. Add more if needed.
• Original URLs – you normally don’t have to change this unless your site spans multiple URL’s. For example some multi-sites or multi-lingual sites will use multiple domains or subdomains.
• Included Directories – the defaults should be enough but feel free to add other directories that you want to include.
• Exclude Path – used to exclude any directories sitting within the included directories above.
• Load JQuery Remotely – I leave it OFF but you’re welcome to see if the other options make any difference.
• Cloudflare API – for Cloudflare-users only. Enter email, global API key, and domain. This way, LSC purges Cloudflare cache when your LSC cache purges.

CDN > Manage:

• Cloudflare – I don’t mess with.
• Development – if you want to conveniently disable Cloudflare without having to log in and deal with 2-FA security (haha).
• Cloudflare Cache – convenient way to purge only Cloudflare cache (and not your LSC cache), such as when you update some images or other assets and want the change to show immediately.

Image Optimization > Image Optimization Summary:

LiteSpeed’s awesome free image compression service just got even easier to use! It’s really incredible. So easy to use. All the features of the top image compression plugins out there. And LiteSpeed Cache does it all for FREE! Yikes!

• Gather Image Data / Send Optimization Request – click this to request free image compression.
• Pull Images – when your image compression is ready, click this to download them to your site. (Your original images will be put into a backup directory; I assume somewhere in your “wp-content/uploads”.)
• Clean Up Unfinished Data – click this when some compression processes get stuck and never finish. then you can request more.
• Calculate Backups Disk Space – handy tool tells you how big the backup folder. You ought to download them from your server to your home computer and delete off the server to save space.
• Remove Original Image Backups – do this only after you backup using the previous option.
• Rescan New Thumbnails – if you made changes to existing images, click this so LSC is aware of them.
• Use Original Files & Use Optimized Files – how cool! You can switch back and forth to see the difference. Or if you want to revert quickly. If you want to revert specific images, you do it from your media library.
• Destroy All Optimization Data – in case you hate LSC’s compression and want your original images back.

Image Optimization > Image Optimization Settings:

• Auto Request Cron – turn it ON if you want your site to automatically request optimization for all newly added images.
• Auto Pull Cron – turn it ON if you want to automatically download optimized images to your site. I assume this option and the previous should be the same (whether ON or OFF).
• Optimize Original Images – probably ON.
• Remove Original Backups – OFF unless you’re 100% sure you like LSC’s image optimization quality. Enabling this automatically deletes your originals after optimizing (and you can’t revert).
• Optimize WebP Versions – I leave it OFF, but feel free to play with it if you got lots of time.
• Optimize Losslessly – safe way to optimize without any quality loss but file-size difference won’t be much either. Probably only useful if you want to clean out info and stuff. Really large images do get some benefit, though.
• Preserve EXIF data – OFF, unless you need that info or want to display it on frontend via plugin.
• Create WebP Versions – I don’t personally use WebP but it is indeed better compression and smaller file-sizes than JPEG/PNG. Turn it ON if you want. If there’s any drawback…it’s maybe that your site will now generate so much more images and take up more space….or that your site images aren’t as easily downloaded and viewed from other devices.
• Image WebP Replacement – OFF is default. I assume you should turn it ON if you’re creating WebP images as well.
• WebP Attribute To Replace – nice way to control which images will be replaced with WebP format. This is another way to tackle the server storage issue if you want to benefit from WebP only for some images. (Like maybe only really large images, and maybe if they’re using transparency?)
• WebP For Extra srcset – nice way to enable WebP image replacements for images not managed through WordPress media library.
• WordPress Image Quality Control – use the default 82, or test higher or lower as you like.

Page Optimization > CSS Settings:

Lots of fun options here that many of you will recognize from other caching/optimization plugins. My advice is to be careful! Most of your caching issues will result from choices made on this page here.

Most of you should really not be minifying or combining for a few reasons. Minifying creates extra work for the server and slows the initial visit. It’s great if you have tons of visitors. But otherwise, don’t minify from this plugin…it’s better to do it from Cloudflare or other CDN which already handles it on their servers at the DNS level. If your site is lean already, minify won’t have much effect anyway. Combining CSS or JS really shouldn’t be done because it often causes problems and doesn’t noticeably speed up the site anyway! (You can read why not to combine CSS/JS.)

• CSS Minify – OFF. Use Cloudflare or from your CDN if you want it.
• CSS Combine – OFF is safest. If you want to enable, test carefully!
• Generate UCSS – it either works amazing, or it breaks your site. Test carefully. I prefer off as my sites don’t have unused CSS bloat.
• UCSS Inline – I don’t use UCSS so I prefer off. You may have to test. I imagine, it’s better/safer for smaller sites than big ones.
• CSS Combine External and Inline – can put to ON if you’re doing CSS Combine (which I never do). Sounds like a good idea.
• Load CSS Asynchronously – leave this OFF or else you’ll get ugly FOUC issue. Sure, it helps your Pingdom/GTmetrix score but hurts UX.
• CCSS Per URL – ON is safer but eats up a ton of server. Clean-coded sites can just have this OFF. Test carefully either way.
• Generate Critical CSS – OFF! I don’t recommend critical CSS.
• Generate Critical CSS In Background – leave ON, it’s dependent on previous setting.
• Inline CSS Async Lib – OFF! True CSS should be render-blocking or else you’ll get FOUC issues.
• Font Display Optimization – in my UI point of view, you should only use Default or Block. Never ever do Swap or Fallback, as they cause FOUT issues!

Page Optimization > JS Settings:

• JS Minify – OFF. Use Cloudflare or from your CDN if you want it.
• JS Combine – OFF is safest. If you want to enable, test carefully!
• JS Combine External and Inline – ON seems like a great idea if you’re using JS Combine feature.
• Load JS Deferred – OFF is safest. Some JS is used for critical items above the fold and should not be deferred.
• Load Inline JS – DEFAULT is safest. Deferred or delaying until after DOM load may improve page scores or help other JS optimizations work properly….but it can also alter site design or function.
• Exclude JQuery – ON is safest. You can turn OFF (allowing JS optimizations on jQuery library) if you’ve tested it carefully.

Page Optimization > HTML Settings:

• HTML Minify – OFF. Do it from Cloudflare or CDN if you want it.
• DNS Prefetch – clever tactic of preloading DNS for external domains, so they load faster when you click on URLs to them or when your site loads external assets coming from them. Don’t know what to put? Simply open your site in Chrome Incognito > Inspect > Sources…now type all the external domain sources that you see. All the google analytics and font calls, social media stuff, chat service, CDN, etc.
• DNS Prefetch – specify external domains from which your site calls external assets and this feature prefetches the DNS so these external assets load faster. For example, my site has MailerLite and Google Analytics domains specified in here.
• HTML Lazy Load Selectors – clever option to lazy load entire sections of your web page. This helps page scores and possibly also your page load. I really like this tactic for bloated sites. Can start with common sections and then work your way to page-specific elements on your busier pages (like home page).
• Remove Comments – OFF is safer/faster for me. Doesn’t make much speed difference either way. It’s there mainly to help you improve Pingdom/GTmetrix vanity score.
• Remove Query Strings – no speed improvement when enabled IMO (most caching can handle query strings now). Most people enable it to get better test scores. I recommend to leave it OFF if you’re still adjusting your design, otherwise you’ll run into stale CSS/JS issue.
• Load Google Fonts Asynchronously – test carefully. I haven’t noticed much difference either way as I suspect the most common Google Fonts are already cached on your browser from other sites you visit.
• Remove Google Fonts – I’m a little confused why this option exists. From the way LS documentation explains it, it’s for those already locally-loading fonts and want to make sure to avoid any external Google font calls. But then again, I think anybody skilled enough to load fonts locally would be easily able to dequeue the Google font calls.
• Remove WordPress Emoji – safe to turn ON. It removes one tiny emoji JS call, which isn’t needed nowadays as modern browsers can render emojis natively.
• Remove Noscript Tags – safe to turn ON unless your site is often loaded by older browsers or ones without JS support (like maybe on a device?).

Page Optimization > Media Settings:

• Lazy Load Images – loads images only when browser scrolls to them. I prefer this OFF as I hate lazyload.
• Basic Image Placeholder – what users see before images load.
• Responsive Placeholder – I recommend ON if you’re lazy loading images. It reserves the space for images so that the layout doesn’t jump around when users scroll down. Then again, you might like this off if your website relies on mis-clicked ads to make money. 😉
• Responsive Placeholder SVG – the SVG used as your responsive placeholder.
• Responsive Placeholder Color – probably grey or something not noisy. Just enough to let users know something will appear.
• LQIP Cloud Generator – advanced placeholder technology showing a very low quality version of your image which is soon replaced by the high quality version. It’s great for helping image-heavy sites appear to load quick and decreasing the distraction of lazy-loaded images.
• LQIP Quality – use default setting of 4 or test other settings.
• LQUIP Minimum Dimensions – clever feature to avoid generating LQUIP for super small images that aren’t noticeable.
• Generate LQIP In Background – you’ll have to test it with it ON vs OFF on uncached pages to see it feels. ON is the safer option, probably.
• Lazy Load Iframes – great idea if you have iframes or video embeds that aren’t used above the fold.
• Add Missing Sizes – ON is a smart idea if you’re using lazy load features.
• Inline Lazy Load Images Library – I leave it OFF (better performance this way, I feel). Can turn ON if you want to remove another HTTP request for page score purposes or if your site design is super lean.

Page Optimization > Media Excludes:

• Lazy Load Image Excludes – exclude any images from lazy-load. Probably a good idea for any ATF-images or ones on pages that are constantly skimmed or quick-scrolled by users.
• Lazy Load Image Class Name Excludes – another clever way to exclude images from lazy-load by listing their CSS class.
• Lazy Load Image Parent Class Name Excludes – clever way to exclude images that don’t have a CSS class assigned. Instead, you exclude by their parent class.
• Lazy Load Iframe Class Name Excludes – really awesome way to exclude certain videos from lazy load (such as the ones used near the top of your site). Or ones that take longer to load and you don’t want to delay when it starts loading.
• Lazy Load Iframe Parent Class Name Excludes – convenient way to exclude iframes that don’t have a CSS class assigned.
• Lazy Load URI Excludes – awesome way to disable lazy load functions on certain pages. For example like a landing page where you want images and videos to load ASAP.
• LQIP Excludes – don’t generate LQIP for these images, ensuring they always appear in high quality.

Page Optimization > Discussion Settings:

• Gravatar Cache – great feature for sites with tons of comments. But not necessary (and not recommended IMO) if most of your posts don’t have many comments and/or don’t have much traffic.
• Gravatar Cache Cron – I imagine this should be ON if you’re caching Gravatar.
• Gravatar Cache TTL – default of 1 week is fine but I’d probably set something like 3 months. I feel people almost never update their Gravatar.

Page Optimization > Tuning Settings:

• CSS Excludes – list all CSS files you don’t want to be minified or combined. You can list their full string name (e.g. “elementor-builder.css”) or partial string name (e.g. “elementor”).
• JS Excludes – list all JS files you don’t want minified or combined. You can list their full string name (e.g. “elementor-builder.js”) or partial string name (e.g. “elementor”).
• UCSS Whitelist – makes sure these CSS selectors are always included in UCSS. (As that feature sometimes removes necessary CSS.)
• UCSS URI Excludes – always exclude these CSS selectors from UCSS.
• Separate CCSS Cache Post Types – if using critical CSS, you should list every post type that has its own page design and CSS! (Good examples would be WooCommerce category/product pages, pages with pricing table, etc.)
• Separate CCSS Cache URIs – used in similar manner as previous option but for single URLs. Probably used for any specific page that uses different CSS from other pages.
• Critical CSS Rules – if using “Load CSS asynchronously” feature, copy paste any critical CSS rules here to make sure they load first.
• JS Deferred Excludes – if using “Load JS Deferred” feature, you can exclude any specific JS here to keep them loading as they normally would. (Good idea for any JS needed to render critical content.)
• Guest Most JS Excludes – exclude certain JS from optimization for guest mode. Useful in case guest mode optimizations are affecting appearance or functionality.
• URI Excludes – list any page URL’s here that you want excluded from any page optimizations. Good idea to list pages that have broken design or functions caused by those optimizations.
• Optimize for Guests Only – ON looks like the proper default option. You would only set to OFF if you had guest users that logged-in? (Which seems unlikely.)
• Role Excludes – can exclude page optimizations for these logged-in users. You’ll probably never use this except for certain testing purposes.
• Combined CSS Priority – generally OFF and doesn’t apply unless you have both COMBINED CSS and UNCOMBINED CSS (created by excluding some CSS from combining). This feature loads the combined CSS before the uncombined CSS instead of the default setting (which is opposite). It’s up to you to know which scenario best fits your needs. Generally, we want critical CSS to load first and other CSS to load last. But other times, we have overlapping layers of CSS and want to make sure the correct final layer loads last to avoid any unwanted styles. It all depends on your strategy of deciding whether to have both combined and uncombined CSS, then deciding which CSS should be combined or not, and then finally whether combined CSS or uncombined CSS should load first.
• Combined JS Priority – same idea as the function up above but now for JS.
• Max Combined File Size – I’m sure there’s probably a nuance to what this should be set at. Personally, I don’t like combining CSS or JS at all. But if you had to, it’s safest to combine it all to one file. But if you want to take a step further, you could decrease the max size and chop it into smaller chunks to see if your browser can chew through it faster. I imagine it might help for slower devices or slower internet speeds.

Database > Manage:

Really incredible database cleaning and optimization tools in here. Some that are even sold as separate plugins by other developers. I love that LiteSpeed implemented my requests. <3

• Clean All – does all optimizations listed.
• Post Revisions – deletes all post revisions.
• Auto Drafts – some people check before deleting.
• Trashed Posts – some people check before deleting.
• Spam Comments – some people check before deleting.
• Trashed Comments – self-explanatory.
• Trackbacks/Pingbacks – self-explanatory.
• Expired Transients – safe to delete.
• All Transients – safe to delete.
• Optimize Tables – safe to do.
• Clean CSS/JS Optimizer – safe to do.
• Database Table Engine Converter > Convert to InnoDB – yes, do it for all tables! InnoDB is better MySQL table format than the older MyISAM.
• Database Summary – I love this for seeing what autoloads I have on the site. You should try to keep the total autoloads below 1mb, best is below 500kb.

Database > DB Optimization Settings:

• Revisions Max Number – set a limit if your database is too big and you have many posts. I leave this at 0 as my sites are lean. But other sites can do something like 10-50 to be conservative.
• Revisions Max Age – can set it to auto-delete revisions after a certain time. I personally think this is scary as sometimes one of your posts has an issue and you don’t notice until a long time after.

Crawler > Summary:

This section doesn’t have much effect unless you have your own server, as most LiteSpeed webhosts won’t enable the crawler option (since it can hog resources). You usually don’t have to mess with anything here except for if you want the crawler to pre-cache more aggressively. And wow, so many aggressive options! You can increase crawl intervals or thread-use, even precrawl for logged-in users and cookies, etc.

• Summary > Reset position – reset it if you want it to start over from the beginning, like maybe after a cache purge.
• Summary > Manually run – manually restarts the crawler instead of waiting till the next cron job run.
• Summary > Show crawler status – check and see if it’s running/enabled on your server.
• Map > Clean Crawler Map – a crawler map is like a sitemap for your crawler. You can clean it whenever you want to generate a new one (like after new pages are added).
• Map > Refresh Crawler Map – probably a good idea to refresh this after site changes or after you reset “cleaned” the crawler map. Then you can see which pages are crawled or not, also add to the blacklist to prevent pages from being auto-crawled.
• Blacklist > Empty blacklist – clear out your blacklist if needed.

Crawler > General Settings:

• Crawler – enable it for auto cache build. Uses resources so maybe not a good idea if this is a busy server with many sites that aren’t yours. Of course, if it’s your server and running your sites then you should enable it to use as many resources as you can!
• Delay – the default is fine. This only needs adjusting if you’ve got over 30k pages throughout the entire server.
• Run Duration – default value is fine but you can increase it for priority sites.
• Interval Between Runs – default value is fine but you can decrease it for priority sites and/or server is often idle.
• Crawl Interval – recommended value of 302400 (3.5 days) is totally fine but you can push it up to 86400 (1 day) if your site is small (less than 3k pages) or you have your own server.
• Threads – default value of 3 is fine. Setting higher crawls it faster but doesn’t matter much unless you have at least a couple hundred pages. It also uses more CPU so don’t set it high if you have a busy server with many sites.
• Timeout – 30 seconds is a safe default. Fast sites can go with less (10 seconds?). Bloated sites would need more, maybe 60 seconds tops.
• Server Load Limit – recommended value of 1 is a nice safe limit. But I much prefer 2 or 3 if have your own server.

Crawler > Simulation Settings:

This area is only needed if you want to precrawl pages for logged-in users. (The regular crawl function already covers public non-logged-in users.)

• Role Simulation – precache pages for specific users. Talk about aggressive!
• Cookie Simulation – pre-crawl for specific cookies.

Crawler > Sitemap Settings:

• Custom Sitemap – LSC can precrawl your site automatically but I like entering a sitemap for large sites or ones with many post types, to make sure it doesn’t waste time on non-important urls. You can use your own sitemap like one generated from XML sitemap plugin. Or maybe if you want to use a separate crawler sitemap (such as to exclude certain items from pre-crawl).
• Drop Domain from Sitemap – leave it ON unless you have multiple domains in the sitemap (such as for multisite, multi-lingual).
• Include Posts/Pages/Cats/Tags – usually all should be on, unless you want to exclude certain low-traffic items from pre-crawling.
• Exclude Custom Post Types – copy over the items in the “Available Custom Post Type” box that you don’t want included in your sitemap. You should be excluding all CPT’s that aren’t normally browsed through their own frontend URL. For example, if you have “faqs” but they’re usually browsed through pages, then you can exclude them here. The idea is to exclude as many CPT’s from your sitemap as possible so crawlers (like LSC or Google) can focus on your higher-traffic content.
• Order links by – “Date, descending” makes the most sense to me unless you live in some alternate reality where your older content is worth more, or that your content is placed in alphabetical hierarchy.

Toolbox > Purge:

I love this area dedicated to granular purge options; it’s great for selectively purging things so you don’t overwhelm the server for high-traffic sites (since thousands of users will hit uncached pages). But I never use it for most sites. I just purge everything all at once.

• All options are self-explanatory – I don’t really have to explain them, do I?
• Notable ones are probably the pages, CSS/JS, and Opcode cache. These are most common in day-to-day purging for giant sites.
• Extra note: if you plan to configure your site for only manual purging, don’t forget to disable the auto-purge rules in the cache section!

Toolbox > Import/Export:

This area is good for testing and saving different configurations you had. Do I use it? No because I’ve configured LSC on so many hundreds of sites that I can do it in my sleep.

One question I’m asked a lot is if you can save one global config and import it across all your sites? You can but only if those configured settings don’t have site-specific configurations. I never use it as I prefer to set each site manually just to be sure.

• Export – saves all settings to a convenient LSC settings file.
• Import – imports settings from a LSC settings file. Here’s my default LSC configs if you want.
• Reset Settings – resets all LSC settings to default.

Toolbox > Edit .htaccess:

Love this feature. So handy to quickly view/edit htaccess without having to get server access or FTP. Really useful for troubleshooting things or when you just want to clean up or edit htaccess.

• .htaccess Path Settings – the auto detect should work fine. Specifying the path is usually not necessary unless you have your site in some non-standard directory or using non-standard htaccess file name.
• Current .htaccess Contents – use it safely!

Toolbox > Heartbeat Control:

Before you go around messing with WordPress heartbeat controls, please understand what it’s used for. The WordPress heartbeat is the AJAX call that uses the “/wp-admin/admin-ajax.php” file. Most sites shouldn’t ever have to optimize this unless it causes high CPU usage (seen from slow admin-ajax.php calls in your speed test waterfalls).

In the event that you need to optimize this, be careful how you do it. You shouldn’t completely disable unless it was unnecessarily called from some bloated plugin. Usually, we optimize by raising the interval in places where it’s used and disabling it from the pages where it’s not used.

The 2 most common uses cases for heartbeat are A) auto-saving posts in your editor and B) updating WooCommerce cart count as people add/remove products from your cart in WooCommerce. There are many other uses cases as well but will vary from site-to-site depending on the plugins used. Just be careful before disabling!

• Frontend Heartbeat Control – turn it ON if you want to change the interval.
• Frontend Heartbeat TTL – can double to 120 seconds if it’s still used on frontend or set to 0 to disable.
• Backend Heart Control – turn it ON if you want to change the interval.
• Backend Heartbeat TTL – usually the backend is a safe place to completely disable the heartbeat as most functions don’t rely on it there.
• Editor Heartbeat – I highly recommend leaving this OFF as WordPress uses it to auto-save your work. Should your internet ever cut out or you accidentally close the page, etc…your work will be saved.
• Editor Heartbeat TTL – you can increase the interval if you have so many writers on the site at the same time, but don’t ever disable this!

Toolbox > Report:

• Install DoLogin Security – useful plugin that gives other people instant WP-admin access using a temporary link (instead of login user/pass).
• LiteSpeed Report – useful for sending to official LS support.
• Passwordless Link – generates auto-login link to WP-admin. Requires the DoLogin Security plugin mentioned above.
• Notes – put whatever extra useful info. Like what you did, what you changed, where you noticed the issue and how to recreate it.
• Send to LiteSpeed – sends the report to LiteSpeed. Then you reference the report number in the support forum or anywhere that you’re making a support request.

Toolbox > Debug:

You shouldn’t be changing anything in here unless you’re debugging issues with your site. Honestly, I’ve never had to use it as most issues related to caching have been easy to fix for me.

• Disable All Features – turn ON only if you’re debugging issues.
• Debug Log – turn ON only when debugging. Use the Admin IP option if you have so much traffic that your debug logs get too big.
• Admin IPs – enter your external IP to run debug actions from your browser.
• Debug Level – choose Basic or Advanced depending on your needs.
• Log File Size Limit – increase only if you need it.
• Log Cookies – turn ON if needed.
• Collapse Query Strings – turn ON if needed.
• Debug URI Includes – logs on the pages listed. Useful if you’re only having issues on a certain page.
• Debug URI Excludes – exclude pages from your debug log.

Toolbox > Log View:

• [D] Clear Log – clears the log.
• Clear Log – clears the log

Toolbox > Beta Test:

This is a really useful option if you want to test different versions of LSC (preferably on a staging site) and switch back and forth between BETA and STABLE versions. I imagine it could also be useful for rolling back to a previous version if the new ones are giving problems.

• Use latest GitHub commit – click this to try the latest GitHub version.
• Use latest WordPress release version – click this to use the latest STABLE version of LSC.

STEP #3 – Check if LiteSpeed Cache is working

1. Open up your site on a browser (not logged in).
2. Load and reload a few pages.
3. Then view source, scroll to the bottom and see if the LiteSpeed Cache comments show at the bottom.

Naturally, the page may be a little slower on initial visit but should be blazing fast on all subsequent visits.

STEP #4 – Resolving Issues

• LiteSpeed cache comment not showing – either LSC isn’t working or maybe you enabled Cloudflare’s feature which strips out HTML comments.
• Delayed CSS issues (FOUC or FOUT) – don’t use critical CSS. Don’t combine CSS!
• Broken visuals or functions – try not combining CSS or JS. Or you can use my diagnostic steps for excluding problematic CSS/JS below.
• Contact forms not working – if you can’t get the contact forms to work, the easiest fix is to exclude the page entirely. Another idea is to make sure you exclude the contact form CSS/JS from combining. (I also recommend not to use Contact Form 7.)
• WSOD or error 500 – it’s unfortunate but not every plugin is compatible with others. You can restore your site by deleting the LScache section in htaccess, delete the “advanced-cache.php” and “object-cache.php” files in the “wp-content” directory. You can also increase your WP memory limits.
• Admin area showing incorrectly – this can be due to caching logged-in users, caching private content, or object-caching. Try disabling all and slowly re-enable one by one until you find the issue.

How to find and exclude problematic CSS/JS from combining:

1. Isolation Method #1 – leave COMBINE CSS or JS enabled, open up the site in Chrome > Developer Tools > Network (tab), and reload the page. Click the little red error circle to see which CSS/JS are missing. Exclude them from merging and see if things work.
2. Isolation Method #2 – disable COMBINE CSS or JS (or even caching altogether), and scan your site in Pingdom. Scroll down to the waterfall and sort the loaded items by file-type (neatly displaying all CSS/JS). Now go back to Swift settings and merge scripts/styles again but manually exclude whichever CSS/JS you think is causing the issue. (Hint: whatever’s breaking is probably related to the problem. Did a certain plugin or theme function stop working? Try disabling those CSS/JS.) Yes, it will take a lot of trial and error. It could be anywhere; maybe a plugin, maybe a theme.

There’s a lot I’m not spelling out because this is very technical and should be handled by advanced users. If you’re having this much issue with merging CSS/JS, you shouldn’t be doing it. It’s nobody’s fault…not yours, not the cache plugin, not your other plugins/themes. (Sure you can try another CSS/JS merge plugin like Autoptimize and it might work for your current setup but then break another day.) I really really don’t recommend merging CSS/JS!

STEP #5 – Playing with Aggressive optimizations

CSS/JS Combine strategy

Again, I hate combining CSS/JS but if you really wanted to do it…I think that should be messing with CSS/JS combining are those with really small or really big sites. If your site is somewhat average-ish, you’ll probably get far better performance and hassle-free operation by not messing with combining CSS/JS at all. If your site is really small (imagine 5 CSS files but only 7KB total), combining them into a single request is not much hassle (less likelihood of conflict) and also speeds up the site because of having fewer HTTP requests. If your site is really big (imagine 20 CSS files and 800KB total), it might benefit you slightly to combine some but not all.

Now, why is it that I don’t recommend to combine all CSS/JS or large sites? It’s because they have so much CSS/JS that it all can’t be loaded at once. And to delay the page rendering by waiting for all of them to load is silly. This is why we should combine some but not all. And more importantly, we have to decide which ones to load first.

There are 2 tactics that come to mind:

• Combine all, exclude a few – this makes the most sense and is most aligned with how cache plugins function. I suggest you combine all CSS/JS and exclude all the ones most necessary for rendering the top of the page.
• Combine a few, exclude the rest – this is even safer since only fewer CSS/JS files would be combined, causing less conflicts, but would require a bit of extra work for you to manually specify which files to exclude.

Notice how I didn’t mention critical CSS anywhere in here. This is because I hate how finicky critical CSS can be. Don’t use it unless you absolutely know what you’re doing. And if you already do, then I don’t have to explain how to use it here.

Object-Caching strategy

I only recommend this for large sites with lots of database-querying and short-term cacheable dynamic content. Anything with a lot of numbers and relatively “live” or “dynamic” info is a good candidate for object caching. Enable it and use redis. Then feel free to mess with the object cache expiry time that works for you and doesn’t serve outdated content. I’ve also heard it’s more performant to use redis in a Unix socket (although I’ve never done it). Here’s the guide for the admin-guys.

NOTE: if it seems most of your content is static and numbers never change, then you don’t need object caching!

Enabling the crawler (or alternative cache-warming function)

Ever notice those other cache plugins that allow pre-caching, preloading, or cache-warming? I absolutely love that feature as it prevents the slow first load for visitors. Unfortunately, LiteSpeed Cache was built to compliment LiteSpeed server which is typically used for high traffic sites which don’t have to worry about cache-warming (since the first visitor pre-warms the cache for everyone else)…but for sites with low traffic, the cache is often cold since nobody has visited for a while.

So you got 2 choices:

• You can enable LS cache crawler from the server – but this requires access to the server and some Linux skill to install/configure it. Once installed, you can then set the crawler settings as aggressive or as conservative as you want.
• Use an alternate cache-warming function –  it’s possible that you might not have server access and your webhost doesn’t want to enable the crawler. They’re afraid of you hogging server resources. So your alternate option is to use a plugin like Warm Cache which pre-crawls your pages defined in XML sitemaps (from your SEO plugin like YOAST, or sitemap plugin like Google XML Sitemaps) using cron jobs set at your chosen interval.

Caching private content

Lots of information to read through. I’ll leave it up to you (and/or your developer).

• Choosing Between Public Cache, Private Cache, and ESI
• Private Cache vs. Public Cache
• ESI and LiteSpeed Cache

Need Expert Help?

I’ve tried my best to offer detailed advice for everyone. But there will always be sites that need special configuration. Still have problems? Visit one of the LiteSpeed support channels mentioned below.

• Free help is available on the LiteSpeed WordPress Community Facebook group (convenient, official support team and myself are on there), Slack group (more active and more skilled-users than FB group), LiteSpeed Cache WordPress repo (slower response), or official LiteSpeed support page (great option and more privacy for paid users).
• More explanations about features can be found on official LiteSpeed documentation, wiki, and forums.
• Official LiteSpeed cache plugin page.
• Official LiteSpeed cache beginner’s guide.
• If you need help but still insist on doing things on your own, please respect your level and avoid messing with settings that you don’t understand. Litespeed has features for newbies as well as developers and server experts.

If you would like paid help or even just a free look at your site, don’t hesitate to contact me. (I configure LiteSpeed on dozens of sites/servers every month.)

Take care and hope to see your site at LITESPEED! 😀