LiteSpeed Cache opens with a dashboard, a row of menus and more toggles than most people will ever need. Some tutorials tell you to switch nearly everything on. Then the mobile menu stops opening, the slider freezes or the contact form refuses to send, and you cannot remember which of the twenty changes did it.
A calmer approach is to treat LiteSpeed Cache settings as three separate jobs, done in order: caching first, then the low-risk extras, then the optimisation features that change your code, one at a time with a test after each. Menu names shift a little between plugin versions, so the descriptions here are general rather than click-by-click.
First, confirm the plugin suits your server
LiteSpeed Cache’s page cache only works on servers running LiteSpeed Web Server or OpenLiteSpeed, because the server itself stores and serves the cached pages. On Apache or Nginx, the plugin installs and its other features run, but the page cache does nothing. If you are not sure which server your host uses, or whether this is the right plugin for you at all, read choosing a caching plugin for your server first.
To check quickly, open your site logged out in a private window, open the browser’s developer tools, go to the Network tab and reload. Click the first request and look in the response headers for x-litespeed-cache. If you see it, the server is LiteSpeed and the plugin can cache pages. Once caching is on, the value shows hit or miss.
Before you configure LiteSpeed Cache
- Take a full backup, files and database, and know how to restore it.
- Use a staging copy if your host offers one. Our post on using a WordPress staging site explains how. On a shop, this matters more than on a brochure site.
- Remove other caching and optimisation plugins. Two page caches, or two tools minifying the same files, produce the hardest bugs to track down. Deactivate and delete the old ones and check .htaccess for their leftover rules.
- Record a baseline. Run the same speed test three times on the home page and one inner page, logged out. Note the server response time as well as the overall result.
- Make a short test list for your own site: main menu on mobile, any slider or gallery, the contact form, login and logout, search, and on a shop, add to cart and a test checkout.
Some versions of the plugin offer presets that switch on groups of settings in one go, from cautious to aggressive. They are a quick way to try things on a staging copy. On a live site, the stage-by-stage approach below makes it far easier to find the cause when something breaks.
Stage one: LiteSpeed Cache settings for caching only
This stage gives most of the speed benefit with very little risk. Leave every optimisation feature off for now.
Turn page caching on
Enable the cache in the plugin’s cache settings. The defaults for public pages are reasonable for most sites.
Leave logged-in caching off
There is an option to cache pages for logged-in users separately. It can work well on membership sites, but it needs understanding and testing. Leave it off at first, so logged-in visitors always get fresh pages.
Mobile cache only if your site needs it
A separate mobile cache is only needed if your theme or a plugin sends different HTML to phones. Most modern responsive themes do not. If you are unsure, test the site on a phone with the option off. If phones show the desktop menu or layout, turn it on.
Purge settings
Make sure the cache is purged when plugins, themes or WordPress itself are updated. The default purge rules when you publish a post, clearing related pages like archives and the home page, are a good starting point.
Exclusions
WooCommerce cart, checkout and account pages are handled automatically. If you use other plugins that show personal or changing content, such as bookings, memberships, currency switchers or location-based prices, add their pages or cookies to the exclusion lists. Check those pages logged out in two different browsers once caching is on.
Now test. Load each test page twice in a private window so the cache fills, confirm the header shows hit on the second load, rerun your speed tests and work through your test list. Server response time should drop clearly on cached pages. If it does not, find out why before going further.
Stage two: low-risk extras
Browser cache
The plugin can set browser cache headers for static files, so returning visitors reuse your images, CSS and fonts. This is low risk. If your host already sets these headers, enabling it changes little.
Object cache, only if the host provides one
LiteSpeed Cache can connect to Redis or Memcached for object caching, which helps logged-in users and shops. It only works if your host actually runs one of those services for your account. The plugin shows a connection test. If it does not show the service as connected, leave the option off. Turning it on without a working backend can slow the site down.
The crawler
The crawler visits your pages in the background to rebuild the cache after a purge. It can help a quiet site where pages expire before anyone visits. It also uses server resources, and on shared hosting some providers restrict or disable it. Start with it off. If you later turn it on, watch your hosting resource usage for a few days.
Test again after this stage, especially logged-in pages if you enabled the object cache.
Stage three: CSS and JavaScript, with care
This is where layouts break. Each of these features rewrites how your files are delivered. Enable one, purge all, test your list, and only then move on to the next.
- CSS minify. Removes spaces and comments. Usually safe, small gain.
- JS minify. Same idea for scripts. Usually safe, small gain.
- CSS combine and JS combine. Merges files together. On servers with HTTP/2 or HTTP/3, which LiteSpeed supports, the gain is often small and the risk of ordering problems is real. Skipping these is a reasonable choice.
- Load JS deferred or delayed. Lets the page show before scripts run. It can make a noticeable difference, and it is the most common cause of broken menus, sliders, cookie notices and forms. If something breaks, the plugin lets you exclude specific scripts from deferring. Exclude the one that broke rather than turning the whole feature off.
- Load CSS asynchronously, critical CSS and unused CSS removal. These rely on generated CSS, created through the plugin’s online service. They can improve how quickly the first view appears, and when they go wrong the page flashes unstyled or loses styles on some templates. Try them last, on staging if possible, and check several page types, not just the home page.
HTML minify exists too. The gain is tiny, and it can occasionally upset inline scripts. It is fine to leave off.
Image settings
LiteSpeed Cache can optimise images through its online service and serve WebP versions. If you already use another image plugin, choose one tool for this job, not two.
Lazy loading images is useful for long pages, but the image at the top of the page, such as a hero banner or the main product photo, should not be lazy loaded. Delaying it makes the main content appear later. The plugin lets you exclude images from lazy loading by file name or class. Add your hero image there.
Guest mode and similar features aimed at first-time visitors change what those visitors are served. Leave them until the rest of the setup is stable and you understand what they alter.
What to check after every change
- Purge all from the admin bar, then load the page logged out in a private window, twice.
- Check the mobile menu, sliders, galleries and pop-ups on a real phone.
- Submit the contact form and confirm the email arrives.
- Log in and out. On a shop, add to cart, change quantity and reach the payment step.
- Look at the browser console in developer tools for new red errors.
- Rerun your speed test and compare with the baseline.
Keep a simple note of each change and its result. It takes a minute and turns a frustrating hunt into a quick fix later.
Undoing a change that broke something
Switch off the last feature you enabled, purge all and test again. Because you made one change at a time, that is usually enough. The plugin’s toolbox area can export your settings, which is worth doing once you reach a working setup, and it offers ways to reset them if you need a clean start.
If the site is so broken you cannot reach the admin, or it stays broken after turning features off, our post on recovering when a caching plugin breaks a site covers the safe rollback steps, including working without the dashboard.
Caching and file optimisation are only part of the picture, and our guide on how to make a website load faster covers the images, scripts and hosting questions that settings alone cannot answer. For how the page cache fits with the browser, CDN and server caches, see our overview of website caching.
Frequently asked questions
Can I use LiteSpeed Cache together with Cloudflare?
Yes, and plenty of sites do. With default settings Cloudflare stores static files and LiteSpeed caches the pages on your server, so they do different jobs. Trouble starts when both try to cache HTML, or both optimise scripts or images. Keep one tool per job, and make sure purging in WordPress also clears anything Cloudflare holds.
Why does my site look unstyled for a moment after enabling CSS options?
That flash usually comes from loading CSS asynchronously or from generated critical CSS that does not cover the page being viewed. The page shows before its full stylesheet arrives. Turn the last CSS option off and purge the cache. If you want to keep it, regenerate the critical CSS and test several different page types.
Should I use the LiteSpeed crawler on shared hosting?
Start without it. The crawler requests your pages in the background to refill the cache, which uses server resources, and some shared hosts restrict it. On a small site with modest traffic it can help. If you enable it, keep its settings gentle and watch your hosting resource usage for a few days.
Do I need a QUIC.cloud account for LiteSpeed Cache?
Not for page caching, which happens on your server. Some features rely on LiteSpeed’s online services, such as image optimisation and generating critical or unused CSS, and those need the site connected to the service. If you only use caching and basic minification, you can leave the online services alone.
On LiteSpeed hosting, our speed optimisation service follows the same staged approach: changes applied with your approval, checked against your own forms, menus and checkout, then re-measured against the starting numbers.
Next in this series: Caching WooCommerce Cart and Checkout: What to Exclude
