LiteSpeed Cache Settings That Actually Matter

· 7 min read
Close-up of colorful code on a screen

The LiteSpeed Cache plugin (LSCWP) has an intimidating settings screen — a dozen tabs, hundreds of toggles, and no indication of which ones matter.

Most of them do not. Here are the eight that do, and the three that break stores.

If you want the background on why server-level caching is different from plugin caching, how LiteSpeed makes your site faster covers the architecture.

Start here: turn the cache on, change nothing else

Cache → Enable Cache → ON.

That single toggle does most of the work. LSCWP talks directly to the server, so cached pages are served before PHP starts.

Measure before touching anything else:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://yourdomain.com/

Run it twice — the second request should be dramatically faster. If it is not, the cache is not engaging, and no amount of optimisation below will help until that is fixed.

The eight settings worth changing

1. Object Cache (Redis) — Cache → Object

The biggest win for dynamic sites, and the most commonly skipped. It caches database query results in memory, so repeated queries never reach MySQL.

Set method to Redis, host localhost, port 6379. Confirm the status shows connected — if it silently fails, you get no benefit and no warning.

This is what makes admin and uncached pages faster, which page cache cannot touch.

2. Browser Cache — Cache → Browser

Tells returning visitors to reuse assets they already have. One toggle, meaningful repeat-visit improvement.

3. CSS/JS Minify — Page Optimization

Enable Minify for CSS and JS. It is safe on nearly every site.

Combine is a different matter — it merges files and frequently breaks themes with inline dependencies. Under HTTP/3 the benefit is close to zero anyway, because multiplexing removes the per-file penalty combining used to solve. Leave Combine off.

4. Lazy Load Images — Page Optimization → Media

Defers offscreen images. Real Largest Contentful Paint improvement on long pages.

One critical exclusion: your hero image must not be lazy-loaded. Lazy-loading the LCP element makes the metric worse. Add it to the Lazy Load Image Excludes list.

5. WebP Replacement — Image Optimization

Serves WebP to browsers that support it, typically 25–35% smaller than JPEG at equivalent quality. Run the optimisation once and it applies to the existing library.

6. Critical CSS — Page Optimization → CSS

Generates above-the-fold CSS inline and defers the rest. This is the setting that moves Core Web Vitals most, and also the one most likely to cause a brief flash of unstyled content. Enable it, then actually look at the site on a phone before deciding it worked.

7. Cache TTL — Cache → TTL

The default public TTL is 604800 seconds (one week). That is fine for most sites. For a news site or anything updated several times daily, drop it to 86400. Do not set it very low “to be safe” — that defeats the cache.

8. Purge rules — Cache → Purge

Confirm Purge All on Upgrade is on, and that publishing a post purges the homepage and relevant archives. The default rules are sensible; the failure mode is people disabling them after a confusing stale-content episode and then serving week-old pages forever.

The three that break stores

This is the part worth reading twice if you run WooCommerce.

Never cache cart, checkout or account pages

LSCWP normally detects WooCommerce and excludes these automatically. Verify it rather than assuming, especially after a theme change or if a custom checkout URL is in use.

Under Cache → Excludes → Do Not Cache URIs, confirm:

/cart
/checkout
/my-account

The failure mode here is serving one shopper’s cart to another. It is rare, catastrophic, and entirely preventable.

Be careful with “Cache Logged-in Users”

Off by default for good reason. Turning it on without a per-role cache configuration means logged-in users can be served each other’s personalised pages.

ESI is powerful and easy to get wrong

Edge Side Includes let you cache a page while leaving fragments dynamic — a cached shop page with a live cart total. Genuinely useful, and it needs deliberate configuration per block. If you are not going to test it properly, leave it off; a partially configured ESI setup is worse than no ESI.

Broader store-hosting considerations are in hosting for WooCommerce stores in Costa Rica.

What to skip

  • Combine CSS/JS — breaks themes, negligible gain on HTTP/3
  • Load CSS Asynchronously without Critical CSS configured — guarantees a flash of unstyled content
  • DNS Prefetch for every third-party domain — marginal, and easy to overdo
  • Cloudflare integration, unless you actually use Cloudflare

A sane order of operations

  1. Enable cache. Measure.
  2. Enable Object Cache (Redis). Measure again — this is usually the big one.
  3. Enable Browser Cache and Minify. Measure.
  4. Enable Lazy Load, excluding the hero image. Check on a phone.
  5. Enable WebP. Run the optimisation.
  6. Enable Critical CSS last. Look at the site carefully.
  7. For stores: verify the cart/checkout exclusions.

Change one thing at a time and re-measure. Enabling twelve settings at once and finding the site broken gives you no information about which one did it.

If the cache is not engaging

Check, in order:

  • Is the site actually on a LiteSpeed server? curl -sI https://yourdomain.com | grep -i "^server:" should say LiteSpeed.
  • Is another caching plugin installed? Two page caches fight and the result is usually neither working.
  • Are you testing while logged in? Logged-in requests bypass page cache by design — test in a private window.

That last one accounts for a surprising share of “the cache is not working” reports.

LiteSpeed and Redis are available on every HOSTEMCLOUD plan, with store-aware exclusions configured at setup. If your numbers still look wrong after step 2, the constraint is probably elsewhere — what “high-performance hosting” actually means covers how to find it.

← Back to blog