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 it’s complementing LiteSpeed Cache plugin!!!
Learn how to configure this advanced plugin for maximum speed and hassle-free caching!
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
- 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.)
- Install LiteSpeed WordPress Cache Plugin (free). Then go to settings from admin side-panel, or diamond icon on the top bar. Click [Show Advanced Options].
- Cache > Cache Logged-in Users – OFF
- Optimize > Generate Critical CSS – OFF
- Inline CSS Async Lib – OFF
- Tuning > Remove WordPress Emoji – ON (if you don’t use emojis)
- CDN > Cloudflare API (Cloudflare-users only) – enter email, global API key, and domain.
- Advanced > Browser Cache – ON
- WooCommerce > Privately Cache Cart – OFF
- Hit [SAVE CHANGES] and you’re flying at light-speed!
- No need to exclude or worry about anything, LSC is fantastic out of the box!
DETAILED Setup Guide
STEP #1 – Install LiteSpeed WordPress Cache Plugin (LSWCP)
- Install LiteSpeed WordPress Cache Plugin (free).
- You must be running on LiteSpeed webserver or else the caching mechanism won’t work.
- If you’re purchasing webhosting from a 3rd-party service, you should be fine.
- If you’re managing your own web-server, make sure you configured the cache roots for LS.
STEP #2 – Configure LiteSpeed Cache plugin
Go to settings from admin side-panel, or top-bar diamond icon. Click [Show Advanced Options].
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.
- Enable LiteSpeed Cache – ENABLE (duh!)
- 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 404 Page TTL – don’t touch.
- Default 403 Page TTL – don’t touch.
- Default 500 Page TTL – don’t touch.
- Automatically Upgrade – OFF is safest, but honestly you could totally put it to ON. LSC is built to 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.
- 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 should leave this off!
- 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.
- 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 almost never use any of these.
- Purge All On Upgrade – safest is to leave this ON.
- 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.
- Scheduled Purge URLs – used to purge specific URL’s at a specific time.
- Scheduled Purge Time – exact time used for scheduled purge.
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.
- Force Cache URIs – forcing “non-cacheable” pages to cache.
- Do Not Cache URIs – used to exclude pages from cache.
- Do Not Cache Query Strings – exclude certain query strings from cache.
- 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 – excluding specific user roles from cache.
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 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 if you want it.
- CSS Combine – OFF is safest. If you want to enable, test carefully!
- CSS HTTP/2 Push – OFF is safest, doesn’t make much difference for most sites.
- JS Minify – OFF. Use Cloudflare if you want it.
- JS Combine – OFF is safest. If you want to enable, test carefully!
- JS HTTP/2 Push – OFF is safest, doesn’t make much difference for most sites.
- CSS/JS Cache TTL – default is safe. Use shorter when you’re making many development changes.
- HTML Minify – OFF. Use Cloudflare if you want it.
- Inline CSS Minify – OFF. Doesn’t make much difference.
- Inline JS Minify – OFF. Doesn’t make much difference.
- Load CSS Asynchronously – Helps your Pingdom/GTmetrix score but not much real-world impact.
- Generate Critical CSS – OFF! I don’t recommend critical CSS.
- Generate Critical CSS In Background – leave ON, it’s dependent on previous setting.
- Separate CCSS Cache Post Types – if using critical CSS, you should list every page type that has its own page design!
- Separate CCSS Cache URIs – unnecessary IMO, but used in similar manner as previous option.
- Inline CSS Async Lib – OFF! True CSS should be render-blocking or else you’ll get FOUC issues.
- Load JS Deferred – OFF is safest. Some JS is used for critical items above the fold and should not be deferred.
- Exclude JQuery – ON is safest. You should only turn OFF if you know for sure your theme and plugins don’t use jQuery at all. (Probably only applies to very simple sites!)
- 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.
- Remove Comments – OFF is safer/faster for me. Doesn’t make much speed difference either way. It’s here mainly to help you improve Pingdom/GTmetrix vanity score.
- 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.
- 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”).
- Combined JS Priority – same idea as the function up above but now for JS.
- JS Excludes – list all JS files to be excluded from minification/combination.
- 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.
- Remove Query Strings – not much speed improvement when enabled IMO. 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 outdated CSS/JS issue.
- Load Google Fonts Asynchronously – sounds like a great idea. I haven’t noticed much different 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.
- Critical CSS Rules – if using “Optimize > Load CSS asynchronously” feature, copy paste any critical CSS rules here to make sure they load first.
- JS Deferred Excludes – if using “Optimize > 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.)
- Remove WordPress Emoji – removes one tiny emoji JS call. You’ll probably be fine without as browsers can render emoji’s as well.
- URI Excludes – list any page URL’s here that you want excluded from any of these optimizations.
- Role Excludes – exclude all optimizations for these logged-in users. You can ignore this if everything works fine, but if not, then check all the user roles having problems…or you can simply turn off the optimizations causing issues.
- Lazy Load Images – loads images only when browser scrolls do them. I prefer this OFF as I hate lazyload.
- 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 Placeholder – specify a specific image or block color for lazy-loaded images.
- 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 Background Color – grey is most common but you can change to another color (like the content background) if you like.
- Generate Responsive Placeholder in Background – I leave this ON.
- Lazy Load Iframes – great idea if you have iframes or video embeds that isn’t used above the fold.
- Inline Lazy Load Images Library – I leave it OFF.
- Optimize Automatically – can leave it ON if you have tons of images to optimize. I personally don’t use LSC image optimization features.
- Optimization Cron – should probably be ON.
- Optimize Original Images – probably ON.
- Remove Original Backups – OFF unless you’re 100% sure you like LSC’s image optimization quality.
- Optimize WebP Versions – I leave it OFF, but feel free to play with it if you got lots of time.
- Optimize Losslessly – a safe way to optimize but won’t make as much difference for your images.
- Preserve EXIF data – OFF, unless you need that info or want to display it on the frontend via plugin.
- Image WebP Replacement – OFF is default. I haven’t played with it yet but if it works well, WebP is a nice step up from the old JPEG/PNG formats.
- WebP Attribute To Replace – nice way to control which types of images will be replaced with WebP format.
- WebP For Extra srcset – a nice way to enable WebP image replacements for images not managed through WordPress media library.
- Enable CDN – turn ON if using CDN. (Folks on Cloudflare should ignore this.)
- CDN Mapping – put in the CDN URL and which file types to include.
- Original URLs – you normally don’t have to change this unless your site spans multiple URL’s (like 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 that are 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.
- Enable ESI – I leave it OFF as this stuff isn’t something I’ve played with enough.
- Cache Admin Bar – ON seems safe.
- Cache Comment Form – ON seems safe.
- Vary Group – don’t mess with unless you understand it.
- 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. If you’re enabling it, all you usually need to do is pick memcache or redis (preferred) and leave the other settings alone. Default Object Lifetime should remain as default or something relatively short as database objects are usually only cached for the short-term. 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.
- Browser Cache – I like this ON.
- Browser Cache TTL – default of 2592000 seconds (which is 30 days)is fine to me.
- 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.
- Purge All Hooks – default is fine, but you can also add other hooks used by your theme or plugins. Basically, LSC cache is purged when any of these hooks are triggered.
- 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. Other folks also complain that it causes high server usage.
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 so you can 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.
- Heartbeat – put this to OFF if any site functions break during debugging.
- Log Cookies – turn ON if needed.
- Collapse Query Strings – turn ON if needed.
- Log Filters – turn ON if needed.
- Exclude Filters – exclude unwanted filters from your debug log. This is for developers.
- Exclude Part Filters – another way of exclude filters from debug logs.
This section doesn’t have much effect unless you own your own server, as webhosts won’t give you much power over it. 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.
- Delay – use default.
- 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 own your own server.
- Threads – default value of 3 is fine. 10 is great. It doesn’t matter much unless you have at least couple hundred pages.
- Server Load Limit – recommended value of 1 is a nice safe limit. But I much prefer 2 or 3 if you own your server.
- Site IP – really cool function, but only works if you have dedicated IP for your site, and beneficial only if you have so many thousands of pages.
- Role Simulation – precache pages for specific users. Talk about aggressive!
- Cookie Simulation – pre-crawl for specific cookies.
- Custom Sitemap – you can use your own sitemap like one generated from XML sitemap plugin.
- Sitemap Generation > Include Posts/Pages/Cats/Tags – all should be on!
- Sitemap Generation > 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 exclude 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 intended content.
- Sitemap Generation > 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.
- Product Update Interval – the 1st option makes the most sense. The
- Use Front Page TTL for the Shop Page –
- Privately Cache Cart – OFF. I don’t understand why it’s ON by default and doesn’t make sense. This feature has always caused mixed cart sessions for me.
STEP #3 – Check if LiteSpeed Cache is working
- Open up your site on a browser (not logged in).
- Load and reload a few pages.
- 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:
- 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.
- 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.
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! 😀