Setting up LiteSpeed Cache
LiteSpeed Cache speeds up WordPress by serving pages from cache instead of rebuilding them each time. This guide covers installation, the settings that give real speed gains, which options to avoid, and how to verify the cache is working.
Setting up LiteSpeed Cache
Install the LiteSpeed Cache for WordPress plugin, turn caching on, and leave most defaults alone. The biggest wins come from enabling the cache itself, setting sensible TTL and purge behaviour, and testing for a cache hit. Be cautious with CSS and JavaScript optimisation, database clean-ups, and image “backup removal” options because those are the ones that break sites or are irreversible.
This picks up from a working WordPress site you can log in to as an administrator. You can be on Hostworld cPanel hosting or your own VPS that you manage.
Before you start
- Plugin status: as of September 2026, LiteSpeed Cache for WordPress is version 7.9.1. The plugin page shows minimum requirements WordPress 6.0+ and PHP 7.4+, “Tested up to 7.1.2,” and notes that 7.9 changed QUIC.cloud pairing and set the default “cache logged-in users” to false.
- Full-page caching needs a LiteSpeed stack. You only get full-page LSCache if your site runs on LiteSpeed Web Server Enterprise, OpenLiteSpeed, LiteSpeed Web ADC, or through QUIC.cloud CDN. Without that, the plugin’s caching functions will report unavailable, and you should use its Page Optimization features instead.
- QUIC.cloud pairing changed in v7. Use LiteSpeed Cache → General → Online Services and enable QUIC.cloud services there. Only point DNS to QUIC.cloud if you intend to use the CDN. Do not change DNS if you only want online optimisation services.
- DNS risk: changing nameservers for QUIC.cloud CDN can break web, email and third‑party records if you miss entries. If you need to point a domain back to Hostworld, set your registrar to use our nameservers: ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk.
- High‑risk toggles:
- Page Optimization: CSS/JS Combine, Load CSS Asynchronously, Unused CSS, and Delay/Defer JS can break layouts or scripts until tuned.
- Database Optimisation deletes revisions and other data permanently unless you cap revisions to keep.
- Image Optimisation “Remove Original Image Backups” is irreversible for rollback.
- Crawler can increase server load and may be disabled by the host.
- Guest Mode and Guest Optimization can deliver briefly incorrect per‑user content and consume QUIC.cloud quotas. Do not stack with Cloudflare APO.
Step 1: Install and activate LiteSpeed Cache
What you are doing: adding the official plugin so WordPress can talk to the LiteSpeed cache and provide optimisation tools.
- Log in to WordPress as an administrator.
- Go to Plugins → Add New and search for “LiteSpeed Cache”. Install and activate the plugin by LiteSpeed Technologies.
- After activation, if you see “LSCache caching functions… are currently unavailable,” your server is not providing LiteSpeed’s cache yet. You can still proceed for Page Optimization, or plan to use QUIC.cloud CDN in Step 3.
Undo: deactivate the plugin at Plugins if you want to back out. No content is changed by activation alone.
Step 2: Turn on the cache
What you are doing: enabling full‑page caching in the plugin so public pages can be served from cache.
- In WordPress, go to LiteSpeed Cache → Cache → Cache.
- Set Enable Cache = ON. Click Save.
- Review “Cache Logged‑in Users”. The v7.9 default on new installs is OFF. Leave it OFF unless you have a reason to cache logged‑in users. For dynamic dashboards or membership sites, OFF avoids mistakes.
- Leave the other defaults unless you know you need a change. They are picked to work for most sites.
Undo: set Enable Cache = OFF and Save. Then go to LiteSpeed Cache → Toolbox and Purge All (if you enabled caching previously) to avoid serving cached copies.
Step 3: Confirm your server supports LSCache and pick your route
What you are doing: verifying that the server or CDN can serve LiteSpeed pages from cache. If not, deciding whether to add QUIC.cloud CDN or to use only the optimisation features.
- Open a private browsing window and run the LSCache Check tool against a public URL on your site. It will confirm LSCache support and show caching headers.
- If the tool reports no LSCache:
- Option A: stay on your current server and use Page Optimization only. Skip to Step 7.
- Option B: enable QUIC.cloud services. In WordPress go to LiteSpeed Cache → General → Online Services and click Enable QUIC.cloud services. Follow the on‑screen pairing. To enable the QUIC.cloud CDN you must change DNS either by CNAME routing or by switching nameservers to QUIC.cloud. Do not change DNS if you will not use the CDN.
- If you change nameservers for QUIC.cloud CDN, review the imported DNS zone in QUIC.cloud before switching to avoid mail or third‑party records breaking.
Undo: if you switched nameservers to QUIC.cloud and need to revert to Hostworld, change them back at your registrar to ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk. Allow DNS time to propagate.
Step 4: Set the core cache controls that matter
What you are doing: controlling how long content stays cached, when it is purged, and what must be kept out of cache.
- TTL: go to LiteSpeed Cache → Cache → TTL. The TTL defines how long a cached page lives before it expires. Leave defaults if unsure. Shorten TTL for time‑sensitive content, lengthen it for mostly static pages.
- Purge rules: go to LiteSpeed Cache → Cache → Purge. Confirm that publishing or updating content purges related pages. Consider enabling Serve Stale so visitors see the last cached copy while a fresh copy is being rebuilt during a traffic spike. The trade‑off is that some users may see an older version for a short period.
- Excludes: go to LiteSpeed Cache → Cache → Excludes. Add any URLs, cookies, or user roles that should never be cached. With WooCommerce active, Cart, Checkout and My Account are excluded automatically.
Undo: put values back to defaults and Save. To roll back from Serve Stale, disable it and Purge All so visitors see fresh copies immediately.
Step 5: Test that caching works
What you are doing: confirming you get a cache MISS on the first request and a HIT on the second for a public page.
- Log out of WordPress or use a private browser window.
- Load a public page twice. On the second load it should be quicker.
- Check response headers:
- Linux or macOS:
curl -I https://yourdomain.example/ - Windows PowerShell:
iwr -UseBasicParsing -Headers @{} -Method Head https://yourdomain.example/ | Select-Object -ExpandProperty Headers
- Linux or macOS:
- Look for headers like:
- X-LiteSpeed-Cache: miss on the first request, then hit on subsequent requests.
- Depending on QUIC.cloud or ADC, alternative LiteSpeed cache headers may appear. The LSCache Check tool explains what you see.
- In the WordPress Admin Bar, use Purge this page – LSCache to clear a single page and retest.
Note: when both generic Cache-Control and X-LiteSpeed-Cache-Control headers are present, LiteSpeed honours its own X‑LiteSpeed header for cache behaviour.
Undo: if you see unexpected hits for pages that should be private, add excludes for the URL or cookie, or disable “Cache Logged‑in Users.” Purge the page and retest.
Step 6: Consider Object Cache for dynamic queries
What you are doing: caching database query results in Redis or Memcached if your server provides it.
- Go to LiteSpeed Cache → Cache → Object. If your host or server admin has enabled Redis or Memcached, select the method and enable Object Cache.
- Save and watch the status. Recent plugin versions auto‑disable if the connection fails, which avoids slowdowns.
Undo: set Enable Object Cache = OFF and Save.
Step 7: Use Page Optimisation carefully for extra speed
What you are doing: reducing CSS/JS bloat and render‑blocking. These settings are optional and the common source of breakage. Proceed in this order.
- Establish a baseline without optimisations:
- Open a problem page with
?LSCWP_CTRL=before_optmappended to the URL. That parameter shows the page as it would be without the plugin’s optimisation features. If the page looks fine that way, any breakage you see later is due to optimisation settings.
- Open a problem page with
- CSS minify: enable CSS Minify and Save. Purge All. Check key pages. If layouts break, disable and use Page Optimization → Tuning to exclude specific CSS files before re‑enabling.
- JS minify: enable JS Minify and Save. Purge All. Test menus, sliders and forms.
- Combining files: leave CSS Combine and JS Combine OFF unless you have a strong reason. Combined assets often conflict and can cause large caches. If you enable Combine and see frequent cache misses due to changing filenames, exclude those assets from Combine in Tuning.
- Load CSS Asynchronously and Critical CSS: only enable once the above is stable. Using QUIC.cloud for CCSS can improve scores but may produce flashes of unstyled content until tuned.
- Delay/Defer JS: test carefully. Add problem scripts to the Excludes lists in Tuning if features break.
Undo: turn the last setting you changed OFF, Save, then Purge All. Use ?LSCWP_CTRL=before_optm to confirm the site returns to normal. Then re‑enable features one by one, excluding specific assets as needed.
Step 8: WooCommerce, logged‑in content and ESI
What you are doing: keeping sensitive pages uncached and optionally using ESI to cache around private fragments.
- WooCommerce: with WooCommerce active, LiteSpeed adds a WooCommerce tab and automatically excludes Cart, Checkout and My Account pages from cache. Leave those defaults in place.
- Logged‑in users: caching for logged‑in users defaults to OFF on new installs. Keep it OFF unless you have tested your user flows carefully. If you must cache around private widgets, consider ESI.
- ESI: Edge Side Includes let you punch holes in a public cached page for private fragments like a mini‑cart. ESI requires LiteSpeed Web Server Enterprise, Web ADC, or QUIC.cloud CDN. OpenLiteSpeed does not support ESI.
Undo: disable ESI in LiteSpeed Cache → Cache → ESI and Purge All to return to standard whole‑page caching rules.
Step 9: Decide on Guest Mode and Guest Optimization
What you are doing: improving first‑visit speed for anonymous users with trade‑offs.
- Guest Mode: serves a default cached page very quickly to new visitors, then corrects it via AJAX. Good for TTFB. Risk: momentary wrong language or pricing until it updates.
- Guest Optimization: forces maximum optimisation, including CCSS/UCSS/VPI, for first‑time visits and bots. This uses QUIC.cloud quotas, creates more variants on disk, and increases tuning work.
- Do not use Cloudflare APO together with Guest Mode. Stacking page caches causes conflicts.
Undo: turn Guest Mode and Guest Optimization OFF and Purge All. Your site returns to standard caching.
Step 10: Image Optimisation and safe rollback
What you are doing: reducing image weight and producing next‑gen formats via QUIC.cloud.
- In LiteSpeed Cache → Image Optimization, request optimisation and allow time for processing. The plugin can create WebP or AVIF versions and keeps the originals as backups.
- Test a few pages on different devices. Confirm images look acceptable.
- Only when you are happy, decide whether to keep or remove original backups. Keeping them lets you use “Use Original Files” to revert. Removing backups is irreversible for rollback.
Undo: use “Use Original Files” to revert to originals while backups exist. If you have removed original backups, you cannot revert through the plugin.
Step 11: Database Optimisation with care
What you are doing: pruning old revisions and clutter to reduce database size.
- Go to LiteSpeed Cache → Database. Before running clean‑ups, set “Revisions Max Number to Keep” to a non‑zero value if you need version history, for example 1.
- Run the specific clean‑ups you want: revisions, auto‑drafts, spam or trashed comments, table optimisation.
Undo: there is no full undo. Deleted revisions and comments are gone. If in doubt, skip this step.
Step 12: Leave the Crawler off unless you know you need it
What you are doing: deciding whether to pre‑warm cache. The crawler is disabled by default and may be disabled at host level. It is resource‑intensive on small plans. Only enable after you have stable cache rules and if you have capacity.
Undo: set the crawler OFF and Save. If you tuned delays or concurrency, reset them conservatively.
Step 13: Troubleshoot layout or script breakages
What you are doing: following the official sequence to isolate the cause and fix it without turning everything off.
- Open the page with
?LSCWP_CTRL=before_optm. If it looks correct, the problem is in Page Optimization. - Re‑enable Page Optimization, Purge All, then use the Tuning section to exclude the specific CSS/JS file that affects the broken feature.
- If you enabled Combine and your assets change filenames often, exclude those files from Combine to stop constant purges and cache misses.
- Retest. Use the Admin Bar “Purge this page – LSCache” between changes.
- If headers show no X‑LiteSpeed‑Cache on public pages, revisit Step 3. Do not stack multiple page caches. For example, if you enabled Cloudflare APO and also turned on Guest Mode, disable one of them and test again.
If you are stuck, open a support ticket. Tell us the URL that misbehaves, the settings you changed, and what you saw in the cache headers. We will check your Hostworld hosting environment and advise.
What next
If you need server‑level control for LiteSpeed Web Server or Redis, a VPS gives you that freedom. See our VPS guides for next steps, or order a plan on our Linux VPS page. If you are continuing the WordPress performance playbook, the next step is to measure and monitor. Set a baseline in your analytics and lab tests now that caching is in place, then move on to image formats and theme/script trimming.
Common questions
Do I need a LiteSpeed server to benefit from this plugin?
For full‑page caching, yes. You need LiteSpeed Web Server Enterprise, OpenLiteSpeed, Web ADC, or the QUIC.cloud CDN. Without that, the plugin’s cache layer is unavailable, but you can still use the Page Optimization, Image Optimisation and Database tools.
How do I check if a page is actually cached?
Use a private browser or a logged‑out session. Load a public page twice and inspect headers. You should see X‑LiteSpeed‑Cache: miss on the first request, hit on the next. The LSCache Check tool will confirm support and explain the headers. Make sure you are not logged in, as many sites do not cache logged‑in views by design.
Should I cache logged‑in users?
Usually not. The default on new installs in 7.9 is OFF for safety. Logged‑in pages change per user. If you need performance around private widgets, look at ESI with a compatible LiteSpeed stack or QUIC.cloud. Test flows like account updates and carts carefully if you consider turning it ON.
Can I use Cloudflare with LiteSpeed Cache?
Yes, but avoid stacking page caches that fight each other. Do not use Cloudflare APO together with Guest Mode. If you use QUIC.cloud CDN for LSCache, follow their DNS guidance. If you later revert to Hostworld DNS, set your registrar to our nameservers: ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk.
Is Object Cache worth enabling?
It can help dynamic sites by caching database query results, especially with WooCommerce or large plugins. It requires Redis or Memcached provided server‑side. If the connection fails, newer plugin versions will auto‑disable operations. If you do not have Redis or Memcached, leave it off.