It is a must to use LiteSpeed Cache Best Settings in WordPress. Otherwise, it won’t work properly, or even worse it may break your site. Especially, its caching feature is very delicate and requires the best LiteSpeed Cache settings to output expected results.
If you have ever faced any of the LiteSpeed Cache features not working like the image optimization, CSS and JS optimization, or anything else, there is a very good chance of it happening because of misconfiguration in the plugin. Additionally, wrong settings may cause your website to behave unexpectedly, like seeing contents in your website that doesn’t have proper styles when it starts loading, known as Flash of Unstyled Content (FOUS), noticing any functionality in your website not working, and so on.
I have thoroughly tested LiteSpeed Cache plugin and all its settings before coming up with this LiteSpeed Cache best settings guide. So, I have seen which settings cause which issues. Now, I will guide you through all those so that you can get the most out of LiteSpeed Cache plugin without facing any problems.
About LiteSpeed Cache
I think LiteSpeed Cache is the best cache plugin for WordPress if you are on a LiteSpeed server. And if you are on a different server like NGINX or Apache, LiteSpeed Cache is still one of the top performers for WordPress optimization. You just won’t be able to take advantage of its amazing server-level caching capabilities on other servers. But, you know what, you can use any other caching plugin to make up for that. They all do pretty much the same thing without much of a specialization.
Regardless of the web server you are using, you can use its HTML, CSS, JS, database, and other optimizations without any problems. In fact, you can even take advantage of its special features like Critical CSS, Image optimization, Low-Quality Image Placeholder, and QUIC.cloud CDN in any WordPress site. These services don’t even consume your server resources instead they are done in their QUIC.cloud servers. That’s awesome considering that you get a pretty generous free monthly limits for these services when everyone else is charging for them. And all other features in LiteSpeed Cache are completely free.
Speaking of which, check out this article to know about the free limits of LiteSpeed Cache features that require QUIC.cloud.
Combining all its features, you can get a very fast website loading speed. It may well be all that your website needs to go from a low score in Google PageSpeed Insights to a very high score like in the 90s range.
See this LiteSpeed Cache review to know more about why LiteSpeed is different from any other caching plugins in WordPress.
LiteSpeed Cache Best Settings
The following LiteSpeed Cache best settings guide is based on my first-hand experience with the LiteSpeed Cache plugin for WordPress. I have tried and tested all these settings on multiple sites and found the most optimized settings that actually work. What I mean is that some of its settings conflict with other settings and cause various issues like broken site, FOUC, etc. Additionally, some settings cause more damage than good for individual requirements.
That’s why I have described all the LiteSpeed Cache settings in detail so that you can tell if a setting is useful for your need and also if that setting is going to conflict with any other setting that might result in unwanted outcomes.
Let’s start with installing and activating the LiteSpeed Cache plugin.
From your WordPress dashboard, go to Plugins > Add New. Then search for LiteSpeed Cache. Then for the LiteSpeed Cache plugin result, click on Install and then Activate.
Now your LiteSpeed Cache plugin is installed on your site. This will add a LiteSpeed Cache item in the menu of your WordPress dashboard. Click on LiteSpeed Cache from that menu to open its settings.
LiteSpeed Cache > Dashboard.
It is just a summary of different service status. On the first row, you will see your current month’s usage of the services that require QUIC.cloud.
QUIC.cloud isn’t just used for CDN by LiteSpeed Cache, it is also used for Image optimization, Critical CSS (CCSS) generation, and Low Quality Image Placeholder (LQIP) generation.
Also, QUIC.cloud services are based on a monthly free usage limit. Though their free tier limits are pretty generous, you will need to pay if you exhaust your limits or wait for the next month when the limit will reset again. That is to say, all the features of LiteSpeed cache that doesn’t require the use of QUIC.cloud are completely free to use.
See this page to know about the free limits of the QUIC.cloud services in LiteSpeed Cache and the cost after the monthly limits are used up.
Back to the LiteSpeed Cache dashboard. after the QUIC.cloud services you will see tabs containing how much LiteSpeed helped increase your site performance in terms of Page Load Time and PageSpeed Score.
Then some additional information about Image Optimization Summary, Critical CSS, and Low Quality Image Placeholder activities. It also shows you the Cache Status that tells you which caching is enabled and which are disabled. Then there is some information about the Craws Status on your site.
LiteSpeed Cache > General.
Automatically Upgrade – You can turn it On but I don’t want to be surprised by a big change overnight and face any issues though this is rarely the case. But if there happens to be an issue, the automatic upgrade would leave me clueless about why the issue might have happened. Also, I sometimes like to see the update log of the new versions but automatic upgrades would take that away for me. That’s why I turned this option Off.
I would like the option of automatically upgrading only minor versions but not major ones. But that isn’t available in LiteSpeed Cache, at least yet.
Domain Key – In order to use any of the services in LiteSpeed Cache that requires the use QUIC.cloud, you will need to have a domain key from QUIC.cloud. The services of QUIC.cloud include Image Optimization, Critical CSS generation, Low Quality Image Placeholder generation, and the CDN service of QUIC.cloud.
You can use the first three services by just getting a domain key for your site which doesn’t require linking your site to a QUIC.cloud account. But to use the QUIC.cloud CDN, you will also need to link your site to your QUIC.cloud account. Additionally, if you run out of the free monthly quota of QUIC.cloud services and want to buy more, you will need to connect your site with QUIC.cloud and then buy from there. Below are the steps describing how to do both of those.
To get a domain key for your site, click on the Request Domain Key button.
Now wait for sometime like a minute or so for your domain key to be automatically generated. Then refresh the page and you will see some asterisks in the Domain Key field. This will mean your domain key has been successfully generated.
Now to link your WordPress site to your QUIC.cloud account, click on the Link to QUIC.cloud button.
Then you will be prompted to log in to your QUIC.cloud account.
From this page, you can log in to your existing QUIC.cloud account or create an account for free. Then once you are logged in, you will be automatically returned back to the LiteSpeed Cache settings page.
Now you will see the Visit My Dashboard on QUIC.cloud button instead of the previous Link to QUIC.cloud button. This will mean your LiteSpeed Cache plugin is now successfully connected to your QUIC.cloud account.
One more thing, if you ever change your web server type like going from a non-LiteSpeed server to a LiteSpeed server, upgrading from OpenLiteSpeed to LiteSpeed Enterprise, or do anything like that and want your QUIC.cloud free monthly limits to reflect that change, you can click on the Refresh Domain Key button. Otherwise, LiteSpeed Cache wouldn’t automatically reflect that.
If you are on a LiteSpeed server and using a reverse proxy like Cloudflare on your site, you may only get the free monthly usage limits of the basic tier of QUIC.cloud after you get your domain key because QUIC.cloud will see your server type to be say Cloudflare. That’s why you can disable the reverse proxy first and then request or refresh your domain key to get the right QUIC.cloud free tier. After that, you can enable the reverse proxy. This way your QUIC.cloud free usage limits will stay the same even after enabling the reverse proxy.
Server IP – You can use the IP address of your server in this field. This will eliminate the extra DNS or CDN lookup time that is associated with using domain names. Therefore, QUIC.cloud will be able to communicate faster with your server thereby improving the speed at which your site can receive the QUIC.cloud services. You can click on the Check my public IP from DoAPI.us link to see the IP address of your server.
But this may not always give you the right IP address so it is better if you can get the IP address from your web hosting provider. Then enter that IP in the Server IP field. But if you aren’t certain for sure about your IP address, keep that field empty.
Notifications – Turning this notification On will show their updates in the WordPress dashboard. But I found that some of these update notifications can’t be remove from the LiteSpeed Cache settings pages like when there is a beta version available. That’s why I turned this Off.
LiteSpeed Cache > Cache
The settings in this category are mostly applicable for the users of the LiteSpeed web servers like LiteSpeed Enterprise and OpenLiteSpeed and QUIC.cloud CDN. However, this category also has object caching and browser caching features which can be used with other web servers like Apache and NGINX.
LiteSpeed Cache > Cache > Cache
Settings on this page are ONLY applicable for those using either a LiteSpeed web server or QUIC.cloud CDN or both.
By the way, the HTML/full-page caching feature in the LiteSpeed Cache works directly from the LiteSpeed web server. As such, LiteSpeed Cache provides server-level caching and not application-level caching which is provided by other WordPress cache plugins. This is one of the reasons you won’t find the HTML cached files by the LiteSpeed Cache plugin in your WordPress files directory.
Enable Cache – This is the magic switch for the amazing server-level caching of LiteSpeed Cache plugin. It is required to turn ON this option to enable the caching feature of LiteSpeed Cache. If you turn this option to OFF, the full page caching feature of this plugin will be disabled. So, I recommend turning this option ON.
Cache Logged-in Users – This option is for the private caching of front end pages. If your site has a lot of people who browse your WordPress site as logged-in users like members in a membership site, admins, authors, subscribers, and other WordPress user roles, your website’s cache size will grow significantly if you turn this option ON. So, if you don’t care about your web server storage, you can turn this option ON for faster delivery of your webpages to these users.
However, the pages won’t be cached until the second visit so the speed improvement will not be available to the users in their first visits. That’s why if most of that logged in users don’t visit the individual webpages more than once, you won’t really get many benefits from this. But if you have a handful of logged-in users, you can turn ON this option. Still, the handful of the logged-in users are already your site users so they probably wouldn’t mind the small speed improvement because of the caching. That’s why I turned it OFF.
Cache Commenters – This allows you to separately cache webpages for the visitors who have left a comment that comment is still pending to be approved or discarded. Its usage is similar to the usage of the previously mentioned Cache Logged-in Users option. So, I turned it OFF.
Cache REST API – This is generally used by the WordPress developers for functionality in themes and plugins. So, it wouldn’t be something to worry about for most people. You can keep its default status of turned ON.
Cache Login Page – Your WordPress login page will load faster while it is turned ON. This will also allow the login page to handle more requests. Because many online bots attack the login pages, a login page that loads faster and can handle more requests will do a better job at safeguarding your entire site from going down amid this attack. So, I recommend keeping it turned ON.
On a side note, LiteSpeed Enterprise web server and LiteSpeed WEB ADC come with some built-in security measures for the WordPress login page URL like protection against brute force attacks. This is why if you are on any of those servers, it may be better to not change your default WordPress login page URL which is wp-login.php because then LiteSpeed wouldn’t know what your login page is.
Cache favicon.ico – If your WordPress site doesn’t have a site icon that is shown in the browser tab beside your webpage name, favicon.ico is requested for using in place of that. This ultimately loads a WordPress icon. That’s why keep this option turned ON to make this favicon.ico response faster.
Cache PHP Resources – Some themes and plugins load CSS and JS files by running PHP scripts but those files are generally static files so they can cached without any problems. Also, by caching those files you can avoid running some PHP scripts which would improve your server performance. So, keep this option turned ON.
Cache Mobile – This option is pretty deceptive as it gives an idea that it should be turned ON when your site is mobile friendly. But that totally isn’t the case. Instead, it is meant to be used for only mobile specific content like when your site has an Accelerated Mobile Pages (AMP) version. So, regular responsive websites don’t usually require turning this ON. This is also the case for me so I turned it OFF.
List of Mobile User Agents – This is only applicable if your previous Cache Mobile option is turned ON. The list provided in the recommended field is also the default list used in WordPress so keep it alone or add more devices to the list if you know you need additional ones.
Private Cached URIs – This is applicable if you want some specific pages, posts, or anything on your site not to be cached as public (caching where everyone is served the same thing regardless of who is visiting the page) but as private. A good example would be the user profile or account pages where each user needs to see different contents on the same webpage. Because of private caching, its usage would be similar to the earlier Cache Logged-in Users option found earlier in this settings page. That’s why its usage doesn’t seem very attractive to me so I don’t use it.
Force Cache URIs – If you want to force some of your pages, posts, or anything on your site to be cached, this is the option for you. It isn’t generally necessary unless you have some specific use case.
Force Public Cache URIs – This option can be used to force some of your pages, posts, or anything on your site to be cached as public. Most sites don’t need to be doing anything in this but if you need to use this option, you would already know about it.
Drop Query String – This is an important setting. Query strings are generally used to mean the presence of dynamic contents (e.g. content changes because of things like changes in language, currency, etc) on the page. So, in order to serve the right contents to the right visitors, it is better to serve a non-cached version of the page or to separately cache the page for each separate query string when there is any query string present on an URL.
However, not all query strings are used to mean dynamic contents. For instance, when you click on a link from say Facebook, the link will automatically have a query string attached to it which is used for tracking but not for indicating dynamic contents. Query strings are also used for tracking purposes in marketing campaigns and so those query strings also don’t indicate dynamic contents. That’s why the webpages render the same with or without these query strings. So, you can safely serve cached pages when those types of query strings are present on the URL.
As you know serving cached contents can improve the website load time. So, you will be better off by serving cached contents or by not making multiple cached versions for these types of query strings that don’t indicate the presence of dynamic contents on the page.
In the Drop Query Strings field, you can use such query strings that should be ignored from the URL to allow the serving of cached pages without creating multiple cached versions by LiteSpeed Cache. The default list is this field is pretty good. You can also use some other query strings on the page if you think they are useful.
You can also get some other query string/parameter idea from Cloudlare’s APO supported Query parameter list for WordPress from this link.
LiteSpeed Cache > Cache > TTL
Settings on this page are ONLY applicable for those using either a LiteSpeed web server or QUIC.cloud CDN or both.
This TTL (Time to Live) setting page is for telling the LiteSpeed Cache plugin about the maximum time it should keep the different cached files. Once that time expires, any new request to the expired cached files will not be served from the cache. Instead, the new request will be dynamically generated and then served to the first new visitor. That newly generated page or response will also be cached for serving to any subsequent visitors.
Default Public Cache TTL – This is where you set the expiration time for the public pages or the pages that can be shown to anyone regardless of who is visiting the page. The default value is 1 week which is represented as 604800 seconds. Keeping the default value will do just fine. But you can increase or decrease it as per your need.
A larger value will increase your cache hit ratio or the chances of the pages being served from the cache. So you may want to increase this value especially because this affects most of the pages on your site. LiteSpeed Cache automatically purges/removes the cache for all related webpages when you update the contents of any of your webpages. So, even if you use a higher value, you won’t need to worry about serving stale/old content after updating any of your website content.
Default Private Cache TTL – This is similar to the Default Public Cache TTL settings except that it is for caching private pages or the pages that show different contents based on who is visiting the page. The default value is 30 minutes which is represented as 1800 seconds. Keeping this value will do just fine.
A larger value may cause your website’s cache size to significantly increase if your site needs to cache a lot of private pages. This may happen because of having many webpages and/or many private visitors. In this situation, you may want to keep a lower value.
Default Front Page TTL – You can specify the cache expiration time of your website’s front page in this field. Default value is 1 week or 604800 seconds. Keep this value or change at your discretion. If you want to decide about changing the value, see the Default Public Cache TTL field mentioned previously because these two will be similar.
Default Feed TTL – This field is for specifying how long your website feeds should be cached. Default value is 1 week or 604800 seconds. Keeping this value will do just fine.
A higher value will increase your cache hit ratio. LiteSpeed Cache automatically purges the cached feed pages on updates and on comments, so you won’t have to worry about keeping the page up to date while using any higher value.
Default REST TTL – As discussed in the Cache Rest API option in the previous section, this option wouldn’t be something to worry about for most people. So, you can just keep the default value of 1 week or 604800 seconds.
Default HTTP Status Code Page TTL – This is for specifying how long you want to cache the pages for different status code response. For instance, you can cache pages that return the HTTP 404 Not Found error for a certain expiration time. So, in this field, you need to specify the specific status code and the cache expiration time for that status code with a space between the two. You can include multiple status codes with their cache expiration time in separate lines. Just keep the default values or change at your discretion.
LiteSpeed Cache > Cache > Purge
Settings on this page are ONLY applicable for those using either a LiteSpeed web server or QUIC.cloud CDN or both.
LiteSpeed Cache > Cache > Excludes
LiteSpeed Cache > Cache > ESI
Settings on this page are ONLY applicable for those using either a LiteSpeed Enterprise web server or QUIC.cloud CDN or both.
LiteSpeed Cache > Cache > Object
LiteSpeed Cache > Cache > Browser
LiteSpeed Cache > Cache > Advanced
LiteSpeed Cache > CDN
LiteSpeed Cache > CDN > CDN Settings
LiteSpeed Cache > CDN > Manage
LiteSpeed Cache > Image Optimization
LiteSpeed Cache > Image Optimization > Image Optimization Summary
LiteSpeed Cache > Image Optimization > Image Optimization Settings
LiteSpeed Cache > Page Optimization
This section contains the main optimization settings options of the LiteSpeed Cache Plugin. These optimizations include HTML, CSS, JS files, and others. The aforementioned three files represent all the codes used on any website. So, they require optimizing properly, otherwise, your site may look broken. Also, an option from a settings page in this section can cause conflict with another option. That can make your site behave unexpectedly.
This is why you will need to be careful when setting up the options in this section. Also, if you find your site broken after setting up this plugin, there is a high chance that this section is the reason for that. So, properly read the option details and follow the recommended settings described in this section in order to avoid any of the issues caused by these optimizations.
LiteSpeed Cache > Page Optimization > CSS Settings
CSS files are used to design your website. So, they are required for your webpages but at the same time unoptimized CSS can slow down your website. Additionally, CSS files usually need to be loaded before any of your website contents can load on the screen which makes them render-blocking. And render-blocking resources contribute to slowing down your website’s perceived load speed. This means website visitors will think your site loads slower than it actually does.
So, properly optimizing CSS files is very important for a good user experience. However, optimizing CSS can be a little tricky because it may introduce the FOUC or Flash of Unstyled Content (FOUC) problem, and cause your site to look broken. But I will tell you how you can properly optimize CSS in the LiteSpeed Cache plugin.
CSS Minify – CSS minification will remove any extra white space characters, new line characters, and comments from the CSS files. This can make your site load a little faster because of the slightly reduced file size but the ultimate difference won’t be something very significant.
This minification process will take some time and use some server resources. However, the minification will only be necessary once per webpage until the minified CSS file is removed from the cache or the cache gets expired. So, the page load time for the first visitor of any webpage will be longer because of the necessity to generate the minified file. But all the subsequent visitors to the webpages will enjoy faster page speed.
Therefore, if your site has lots of visitors, you will benefit by turning this option on. But if your site has only a few visitors, you may not see much improvement in the website speed because of the extra time required to serve the first visit. In fact, this may also negatively impact your website speed for low traffic sites. However, you can solve this issue by using the Crawler feature of LiteSpeed Cache considering that your website is on a LiteSpeed server and your hosting provider allows using crawler. You will see more about Crawler in the Crawler section below in this article.
If your website has only a small number of visitors (and if you can’t use a crawler that will automatically trigger these minifications), you may be better off keeping this option turned OFF. But if your site has at least some decent number of visitors, you can get better results by turning it ON. But the ultimate result may not be very significant so you may also see similar results with or without minification.
You can read more about how minification affects your site speed from this article. This article will also discuss another option of how minifying CSS in CDN compares with this option of minifying in your web server.
CSS Combine – This option will combine all your internal CSS files (files that are loaded from the same domain of your website instead of from a different subdomain or an external domain) that are necessary to load a webpage. So, it reduces the total number of requests necessary to load your webpages but not the total size of your CSS files. Regardless, this reduced number of requests could make your site faster in the previous days because of the limitation in the then technology. But that limitation doesn’t exist anymore so CSS Combine is kind of unnecessary nowadays. In fact, in many cases, it can do more harm to your site speed than good.
You can read more about why you shouldn’t combine CSS files from this article. This article also tells you why you might see an increase or decrease in your website speed from both with or without combining CSS files. But regardless, you will ultimately get better results from not combining your CSS files.
In addition to all these, combining CSS files can sometimes cause issues and can break your site. So, it would be a safer bet to not combine the CSS files if you don’t want to worry about possible website issues. So, I recommend keeping the CSS Combine option turned OFF. But if you still decide to try it out, make sure to thoroughly check your WordPress site and see if there are any issues after combining your CSS files.
CSS Combine External and Inline – This option is similar to the previous CSS Combine option which combined only the internal CSS files. But enabling this option will also combine external CSS files (CSS files from a different subdomain of yours or from any external domains) and inline CSS (these are the CSS codes found inside the