LiteSpeed Cache (LSCWP) is the highest-leverage plugin most WordPress sites can install — if the site is running on LiteSpeed Enterprise or OpenLiteSpeed. Its server-level page cache serves pages without invoking PHP, which is architecturally faster than any PHP-based caching plugin can achieve. But its 300+ settings across 10 tabs mean that getting the most out of it requires more than clicking “Enable cache”.
This guide covers the settings that actually matter in 2026, the ones that commonly break sites, and the WooCommerce-specific configuration that most guides skip. It applies to any WordPress site running on LiteSpeed — shared, VPS, or bare metal.
The foundation: server-level caching vs plugin caching
Before settings, a quick primer on why this matters.
A PHP-based cache plugin (WP Rocket, W3 Total Cache, WP Super Cache) works like this:
- Request arrives at the webserver (Apache, Nginx)
- Webserver hands it to PHP
- WordPress bootstraps
- Cache plugin’s hook fires early in the WP bootstrap
- If a cached version exists, plugin serves it and exits
- Otherwise, WordPress continues, generates the page, and the plugin caches the output
LSCWP on LiteSpeed works differently:
- Request arrives at the LiteSpeed webserver
- LiteSpeed checks its internal cache
- If a cached version exists, LiteSpeed serves it directly — PHP never runs
- Otherwise, LiteSpeed passes the request to PHP as normal
The practical difference: PHP-based caches save 500-2000ms by skipping WordPress’s query execution, but still spend 100-200ms bootstrapping PHP and the plugin itself. LSCWP skips all of that. A cached page served by LSCWP typically responds in under 50ms because it never enters PHP at all.
This is the reason to use LSCWP when you’re on LiteSpeed. On Apache or Nginx, LSCWP falls back to storing cache files that PHP serves — which removes the architectural advantage and makes WP Rocket the better choice.
Settings Tab 1: General
Automatically Upgrade: Yes. Bug fixes and security updates ship frequently. The plugin is well-maintained and breaking changes are rare on point releases.
Domain Key: Required for QUIC.cloud integration (image optimisation, CDN, low-quality image placeholders). Click “Request Domain Key” — the key is automatically generated and populated within a few seconds. Without this, half the plugin’s features won’t function.
Guest Mode / Guest Optimization: Enable both. Guest Mode is LSCWP’s term for serving a pre-optimised page immediately on first visit while it builds the full optimised version in the background. This matters for first-time visitors who otherwise wait for the full optimisation to complete.
Settings Tab 2: Cache
Cache Control
Enable Cache: Yes. This is the primary switch.
Cache Logged-in Users: No for almost all sites. This enables caching of logged-in user pages, which sounds appealing but is a common cause of customers seeing other customers’ data. LSCWP has dedicated per-user private cache — use that instead, which it handles automatically.
Cache Commenters: Yes. Caches pages for users who have commented but are not logged in, using a cookie-based cache variation.
Cache REST API: Yes on standard sites. WordPress’s REST API is heavily used by blocks, page builders, and front-end apps. Caching it meaningfully reduces load.
Cache Login Page: No. Login pages should never be cached — brute-force attempts are then cached and look legitimate.
Cache Favicon / PHP Resources: Yes.
TTL
Default Public Cache TTL: 604800 (1 week) is standard. Higher than this doesn’t gain much because content updates trigger purge. Lower than this wastes your optimisation work.
Default Private Cache TTL: 1800 (30 minutes) is appropriate. Per-user content changes frequently; short TTL keeps content fresh.
Default Front Page TTL: 604800 (1 week). Same rationale.
Default Feed TTL: 604800.
Default REST TTL: 604800.
Purge
Purge All On Upgrade: Yes. Plugin or theme updates often change templates; clearing the whole cache ensures visitors see the new version.
Auto Purge Rules For Publish/Update: Enable the defaults plus “All pages” if your site relies heavily on related content widgets.
Scheduled Purge URLs: Leave empty unless you have a specific stale-content issue.
Excludes
Do Not Cache URIs: The WooCommerce pages are handled automatically, but add any custom endpoints that return per-user data. Common additions: /api/, /user-dashboard/, /account-settings/.
Do Not Cache Query Strings: Add tracking parameters that shouldn’t create separate cache entries: fbclid, gclid, utm_source, utm_medium, utm_campaign, utm_content, utm_term.
Do Not Cache Cookies: Leave defaults. LSCWP knows about WooCommerce, membership, and common authentication cookies.
Do Not Cache User Agents: Leave empty unless you have a specific bot management reason.
Object Cache
This tab is critical — see our Redis for WooCommerce guide for the full object caching picture. Quick checklist:
Object Cache: Enable
Method: Redis (Memcached works but Redis is better for WordPress in 2026)
Host: /var/run/redis/redis.sock for local Redis via Unix socket (preferred), or 127.0.0.1 for TCP
Port: 0 for socket, 6379 for TCP
Default Object Lifetime: 360 (6 minutes)
Database ID: 0 (or a higher number if Redis is shared with other applications)
Cache WP-Admin: Yes
Persistent Connection: Yes
Store Transients: Yes
Browser Cache
Browser Cache: Yes. Sets far-future expiry headers on static assets so browsers cache them.
Browser Cache TTL: 31557600 (1 year).
Settings Tab 3: CDN
If you use QUIC.cloud, enable this tab. The CDN tab integrates LSCWP with QUIC.cloud’s edge network for static asset delivery.
QUIC.cloud CDN: On.
HTML Optimization / Minify: Yes (processes HTML on the CDN side).
Manage Settings: Leave at “On” to let QUIC.cloud handle edge-level settings.
For alternative CDNs (Cloudflare, BunnyCDN), use their native integration and leave LSCWP’s CDN section off. Running LSCWP’s CDN alongside Cloudflare can double-cache and break purges.
See our upcoming QUIC.cloud vs Cloudflare guide for the comparison.
Settings Tab 4: Image Optimization
QUIC.cloud-backed image optimization. Worth the setup time — this alone typically saves 40-60% on image payload size.
Auto Request Cron: Yes. Schedules image optimisation to run in the background.
Optimize Original Images: Yes. Replaces the original with a compressed version, keeps a .bk. backup file so originals can be restored if needed.
Remove Original Backups: No (keep backups until you’re confident).
Optimize Losslessly: Your choice. Lossless preserves exact quality (smaller reduction). Lossy typically reduces file size 50-70% with visually imperceptible quality loss. For WooCommerce stores, lossy is usually the right call.
Preserve EXIF/XMP Data: No unless you have a specific reason.
Create WebP Versions: Yes.
Image WebP Replacement: Yes. Serves WebP to supporting browsers with JPEG/PNG fallback for older ones.
WebP Attribute To Replace: Leave defaults.
WebP For Extra srcset: Yes.
Settings Tab 5: Page Optimization
This is where most sites break things. LSCWP’s page optimisation features are powerful but interact with themes and page builders in ways that aren’t always predictable. Enable one at a time and test thoroughly.
CSS Settings
CSS Minify: Yes. Strips whitespace and comments. Low risk.
CSS Combine: Start with No. If your site has many small stylesheets, enable this and test. Common cause of style breakage on page builders.
Unique CSS File: Yes (creates a single hash-named file for each page). Leave if CSS Combine is off.
CSS Combine External and Inline: No (risky; rarely needed).
Generate Critical CSS: Yes. Inlines the above-the-fold CSS so the page renders before external stylesheets load.
Generate Critical CSS In Background: Yes.
Load CSS Asynchronously: Start with No. Fixes render-blocking but can cause a flash of unstyled content (FOUC) on many themes. Test carefully before enabling on production.
Inline CSS Async Lib: Yes if you enable Load CSS Asynchronously.
JS Settings
JS Minify: Yes. Low risk.
JS Combine: Start with No. On modern WordPress with many plugins, combining JS often breaks things. Enable carefully.
JS Combine External and Inline: No.
Load JS Deferred: “Delayed” is the safer option. “Deferred” can break scripts that need to run on DOM ready. Test specifically for page builders, analytics, and chat widgets.
HTML Settings
HTML Minify: Yes. Low risk.
DNS Prefetch: Add common third-party domains your site uses (fonts.googleapis.com, fonts.gstatic.com, your CDN domain, analytics domains).
Remove Query Strings: Yes (helps with CDN caching).
Load Google Fonts Asynchronously: Yes.
Remove WordPress Emoji: Yes unless you actively use emoji in content.
Media Settings
Lazy Load Images: Yes. Major Core Web Vitals win.
Lazy Load Image Excludes: Add above-the-fold hero images so they aren’t lazy-loaded (LCP penalty).
Lazy Load Iframes: Yes.
Add Missing Sizes: Yes. Automatically adds width/height attributes to images, fixing CLS.
VPI (Viewport Images)
Viewport Images: Yes. Automatically detects above-the-fold images and preloads them.
Viewport Images Cron: Yes.
Localization
Gravatar Cache: Yes if your site uses Gravatars (comments, authors).
Localize Resources: Yes. Moves third-party scripts (Google Analytics, etc.) to your own domain, which speeds up delivery and reduces external dependencies.
Settings Tab 6: Database
Post Revisions Max Number: 3 is a good balance. Too few = lose writing history; too many = bloat wp_posts with revisions.
Post Revisions Max Age: 30 days.
Scheduled DB Optimizer: Enable. Runs optimisation weekly.
Database Cleaner: Run once manually, then let it happen via the scheduler. Cleans: post revisions, auto-drafts, trashed posts, spam comments, trashed comments, expired transients, orphaned post meta, orphaned user meta.
Settings Tab 7: ESI (Edge Side Includes)
Enable ESI: Yes if you run WooCommerce or have user-specific widgets on cacheable pages.
Cache Admin Bar: No (privacy).
Cache Comment Form: Yes.
Custom ESI blocks: use for cart widgets, user greeting blocks, and personalised recommendation widgets. The ESI block approach means 95%+ of the page stays cached while the small dynamic fragment updates.
WooCommerce-specific configuration
The Cache tab has a WooCommerce subsection that’s easy to miss:
Product Update Interval: “Purge product on stock changes” is usually what you want. Other options affect how aggressively product pages are purged on backend updates.
Use Front Page Update Interval: No.
Privately Cache Cart: Yes. Critical — keeps per-user cart data isolated.
Exclude Checkout Processes: Yes. Prevents checkout from being cached even briefly.
Cache User Roles: Leave empty unless you have specific reasons.
Common pitfalls
Cached pages seem stale after updates. Either the purge hooks are not firing for your specific theme/plugin combination, or you have a CDN layer ahead of LSCWP that’s not purging. Check: LSCWP → Toolbox → Purge → Purge All. If that fixes the staleness, the issue is purge configuration, not cache age.
Layout breaks on mobile only. Typically Load CSS Asynchronously or JS Combine causing a race condition visible only on slower devices. Exclude specific problematic stylesheets via the CSS Excludes field.
WooCommerce cart shows wrong items. Almost always means the WooCommerce cookies have been added to “Do Not Cache Cookies” inconsistently. Revert to defaults and the issue usually disappears.
Admin takes forever. Object cache isn’t active or Redis isn’t responding. Check LSCWP → Toolbox → Object Cache → Status. Should show “Enabled” and a hit ratio.
Search engines seeing cached error pages. If you ever ran LSCWP in a broken state, purge the cache completely (Toolbox → Purge → Purge All) and resubmit URLs to Google Search Console for re-crawl.
Testing after configuration changes
Two essential testing commands:
# Verify cache is working
curl -I https://yourdomain.com
# Look for X-LiteSpeed-Cache: hit or X-LiteSpeed-Cache-Control: public,max-age=...
# Verify object cache
wp cli info
# Check for Redis object cache indicators
And in the browser: open any page in incognito, then refresh — the second load should be dramatically faster. Network tab should show the page itself arriving in under 100ms.
When to seek help
If you’ve worked through this guide and results are underwhelming, typical root causes:
- Site isn’t actually on LiteSpeed. Check:
curl -I https://yoursite.com | grep -i server. Should say “LiteSpeed” or “OpenLiteSpeed”. If it says “nginx” or “Apache”, LSCWP is running without the server integration and you’re not getting the main benefit. - Redis isn’t running. Check: Toolbox → Object Cache → Status.
- Theme or plugin is defeating cache. Some plugins (shopping cart integrations, session-heavy membership plugins) set cookies that make everything uncacheable. The Cache Tab → Cache → Exclude Query Strings and Do Not Cache Cookies are worth reviewing against your plugin setup.
For the broader caching picture beyond LSCWP, see our WordPress caching layers guide. For WooCommerce-specific setup, see WooCommerce performance guide.