LiteSpeed Cache for WordPress: The Settings That Actually Matter

2 Sep 2026 · 10 min read

LiteSpeed Cache (LSCWP) is by far the most powerful free caching plugin for WordPress — and the one with the steepest learning curve. More than 200 individual switches spread across a dozen tabs lead to two extremes in practice: either the page cache gets enabled and nothing else is ever touched, or everything gets switched on at once until the layout breaks and it all gets turned off again.

This article shows which settings deliver measurable gains, which ones you should leave alone, and in what order to work through them.

First check: is your site even running on LiteSpeed?

The plugin consists of two entirely separate halves, and this distinction determines everything that follows:

• The server cache works exclusively on LiteSpeed Enterprise or OpenLiteSpeed. On Apache or nginx, the entire cache tab has no effect.
• The optimisation half (CSS, JavaScript, images, lazy load, database) runs on any server.

You can see whether your host uses LiteSpeed in the response header:

curl -sI https://example.com | grep -i -E 'server|litespeed'

If server: LiteSpeed appears, and x-litespeed-cache: hit shows up on the second request, the server cache is working. If that line is missing, you have two options: move to different hosting, or put QUIC.cloud in front as a caching layer — more on that below.

The page cache: the foundation

LiteSpeed Cache → Cache holds the basic settings. The defaults are usable for most sites; these are the points that matter:

• Enable Cache: on. Without this switch, the rest of the tab does nothing.
• Cache Logged-in Users: off. On shops and membership sites, this switch is the most reliable way to serve one visitor's content to another.
• Cache REST API: on, as long as you don't serve personalised REST endpoints.
• TTL for public pages: the default of one week is perfectly fine. What counts is not the lifetime but a clean purge when you publish.
• Purge All On Upgrade: on. After every plugin or theme update, the old cache is potentially inconsistent.
• Browser Cache: on, unless your server already sends suitable Cache-Control headers.

The page cache alone delivers the biggest TTFB improvement — from several hundred milliseconds of PHP execution down to a directly served HTML file. How far that value can be pushed is covered in TTFB under 200 ms.

ESI: the real difference from other plugins

Edge Side Includes are the reason LiteSpeed has an advantage over classic caching plugins on dynamic pages. The idea: a page is cached in full, individual fragments are excluded from it and inserted fresh on every request — the cart counter, the greeting with the user name, a nonce field.

Without ESI, such pages leave you no alternative to skipping the cache entirely. With ESI, the static part of the page stays cached.

The setting sits under Cache → ESI. Two notes from practice:

• ESI requires a LiteSpeed server. On Apache or nginx, nothing happens.
• Badly scoped ESI blocks are the most common cause behind reports of wrong cart contents. After enabling it, always cross-check in two different browsers — once logged in, once anonymous.

CSS and JavaScript: where things break

The Page Optimization tab holds the most effective and the most dangerous options at the same time. A pragmatic order:

1. Minify CSS and JS — low risk, a small but safe gain. Start here.

2. Combine CSS / Combine JS — leave these off. Bundling many files into one made sense under HTTP/1.1, when parallel connections were scarce. Under HTTP/2 and HTTP/3 the browser multiplexes files over a single connection; combining barely helps any more, destroys granular browser caching, and is by a wide margin the most frequent cause of broken layouts and JavaScript errors after activation. HTTP/3 for WordPress covers the reasoning in detail.

3. Load JS Deferred — a noticeable lever for TBT and INP, because scripts no longer block the main thread before rendering. But sliders, consent banners and analytics snippets are sensitive to it. Click through every page template once after enabling.

4. Unused CSS (UCSS) and Critical CSS (CCSS) — the strongest remaining lever against render-blocking resources. LSCWP determines per page type which CSS rules are actually needed, serves those inline and defers the rest. Two limitations: the computation runs through QUIC.cloud, so a connection there is required. And elements that only appear via JavaScript (menus, modals, accordions) are regularly discarded by mistake — that is what the UCSS exclude list is there for.

5. Font Display: swap — prevents invisible text while fonts load and therefore improves LCP directly.

The most important principle for this tab: one setting at a time, then measure and click through the site. Anyone who flips five switches at once and then spots an error has no idea which one caused it — and, in practice, switches everything back off.

Images: the most common self-inflicted wound

Under Image Optimization, LSCWP converts your media library to WebP and compresses it. Processing runs through a QUIC.cloud queue, so the first pass takes a while on large libraries.

Two settings decide whether this is a gain or a regression:

• Lazy Load Images: sensible in principle — but the LCP element must never be lazy loaded. That is exactly what happens to hero images by default, and LCP gets worse through the optimisation. LSCWP offers Lazy Load Image Excludes as well as an option to skip the first images in the viewport. This exclusion is mandatory, not optional.
• Add Missing Sizes: on. It adds missing width and height attributes and prevents the layout shifts that would otherwise feed straight into CLS.

Object cache and database

The page cache does nothing for requests that are never cached by definition: cart, checkout, login, the entire admin area. That is where the object cache comes in.

Under Cache → Object you connect Redis or Memcached, provided your host offers either. The effect is most noticeable on WooCommerce and membership sites, because repeated database queries get answered from memory.

The Database tab cleans up on top of that: old post revisions, expired transients, orphaned metadata. This is no performance miracle, but it keeps tables lean — and above all: back up first, clean up second.

QUIC.cloud: when it pays off

QUIC.cloud is the accompanying CDN and processing service. It matters for three things:

• Image optimisation and WebP conversion run through it.
• UCSS and critical CSS are computed there.
• Edge caching works even when your host does not run LiteSpeed — which turns the plugin into a real caching solution on Apache and nginx servers too.

A free monthly allowance covers small to medium sites. Two points are worth settling in advance: with the CDN active, your traffic passes through a US provider, so you need a data processing agreement and a matching entry in your privacy policy. And image optimisation transfers your media library for processing — with sensitive content, that is a deliberate decision.

The five most common mistakes

1. Enabling everything at once. Afterwards it is anyone's guess which switch broke the layout.
2. Leaving Combine CSS/JS on. Little benefit under HTTP/2 and HTTP/3, plenty of risk.
3. Lazy loading the LCP image. The optimisation then degrades the exact metric it was meant to improve.
4. Caching logged-in users on WooCommerce without ESI. The fastest route to swapped shopping carts.
5. Testing while logged in. As a signed-in administrator you almost never see the cache — measurements belong in a private window.

What to measure afterwards

Optimising without measuring is guessing. The four values that actually tell you something about an LSCWP setup:

• TTFB — shows whether the page cache is working. Compare the first request to a page (cache miss) with the second (cache hit). If the second is not clearly lower, the cache is not doing its job.
• LCP — responds to image optimisation, critical CSS and the lazy load exclusion.
• TBT — responds to "Load JS Deferred".
• CLS — responds to "Add Missing Sizes" and to font display.

With turbometrics you scan your site before and after every change and see all four values side by side over time — including an alert when a plugin update quietly undoes the configuration. How lab values differ from real visitor data is covered in Measuring Core Web Vitals.

Conclusion

LiteSpeed Cache is not a plugin you enable once and forget. The short version:

1. Check whether a LiteSpeed server is running — that decides which half of the plugin does anything at all.
2. Enable page cache and browser cache, exclude logged-in users.
3. Minify yes, combine no.
4. Turn on UCSS and critical CSS and maintain the exclude list.
5. Enable lazy load, exclude the LCP image.
6. Connect an object cache if Redis or Memcached is available.

And measure after every single change, instead of guessing at the end.

Scan your site for free now →