LiteSpeed Cache: The Six Settings That Actually Move Scores

Before you open the settings screen, ask the server one question:

curl -sI https://awplife.com/ | grep -i -E 'x-litespeed-cache|x-qc-cache|x-lsadc-cache'

If that command prints nothing, the plugin cannot cache your pages, no matter which toggles you flip. LiteSpeed’s own installation guide is blunt about it: on Apache, nginx, or any other non-LiteSpeed server, “none of the plugin’s caching functionality will be available to you.” You can still use the CSS and JS optimization features. The page cache requires a LiteSpeed server or the QUIC.cloud CDN in front of the site.

That single fact explains most of the disappointing LiteSpeed advice online. People publish checklists of thirty toggles without checking whether the cache layer exists. Then they enable CSS Combine, wonder why the score moved two points, and add more toggles.

Six settings carry most of the result. The rest are either conditional, paid, or actively risky. If you are still deciding whether LiteSpeed is the right layer for your site, our guide to effective cache plugins for WordPress covers where page caching ends and object caching begins. Here is the order that makes sense.

First, Prove the Cache Is Working

A 200 OK does not mean the page came from cache. Check the response header. On a first request you should see something like:

X-LiteSpeed-Cache: miss
X-LiteSpeed-Cache-Control:public,max-age=1800

Reload, and the same URL should return X-LiteSpeed-Cache: hit. That is the confirmation LiteSpeed documents. Sites behind the LiteSpeed Web ADC use X-LSADC-Cache; sites behind QUIC.cloud use X-QC-Cache and X-QC-Pop. Any of those headers means the cache layer is live. None of them means it is not.

Two things to check while you are there:

• Are you logged in? Cache Logged-in Users is ON by default, and those pages go to a private cache keyed by IP and session ID. An admin browsing the site is not seeing what an anonymous visitor sees.
• Is the URL excluded? The Excludes tab accepts partial URIs, and a loose entry like shop will quietly match more than you intended. Add ^ and $ when you mean an exact path.

If the header never appears, the problem is the server layer, not the plugin settings. That is the first thing to fix, and no amount of CSS minification compensates for it. Our comparison of free cache plugins is useful if you need a fallback on a host that does not offer LiteSpeed.

1. Enable Cache, Then Decide About Logged-In Users

Enable Cache is the master switch, and it is ON by default on a single site. Turning it off purges everything. There is no partial mode.

The decision worth making is Cache Logged-in Users. Leaving it ON gives members a cached page stored privately for them, which helps sites with a large logged-in audience. On a membership site where every account sees different data, that private cache can also create a lot of entries for little benefit. Test with an incognito window and a real account before changing it.

For WooCommerce, the plugin already excludes My Account, Checkout, and Cart by default. If those pages are misclassified — usually because the WooCommerce page assignments are wrong — the cache will serve the wrong thing. Verify each one with the header check rather than trusting the checkbox.

2. Default Public Cache TTL Is Not a Freshness Setting

The default is 604800 seconds, one week. The other options are an hour, a day, and two weeks. A value under 30 seconds tells LiteSpeed not to cache the page at all.

The number is a maximum age, not a promise that readers see a week-old page. Purge rules decide freshness. When a post is published or updated, the Auto Purge Rules setting decides which related pages get cleared: the front page, category archives, tag archives, the post itself. If those rules are incomplete, the TTL becomes the real delay, and a corrected typo can survive for seven days.

Two settings pair with TTL:

• Auto Purge Rules for Publish/Update. Select the archives your theme actually renders. A news site with a busy homepage needs different rules from a site with a static front page.
• Purge All on Upgrade. Default OFF; LiteSpeed recommends ON because a plugin or core update can change any page. The cost is a cold cache after every update. The benefit is not serving markup from a version that no longer exists.

A long TTL plus good purge rules is the stable configuration. A short TTL hides bad purge rules and throws away most of the benefit.

If the cache is cold after a purge and the origin is slow, the crawler can warm it. LiteSpeed’s crawler walks the sitemap and requests pages so the first visitor gets a hit. It is optional, and on a small site the first few requests are usually enough.

3. Serve Stale Protects the Origin, Not the Reader

Serve Stale is OFF by default. It is the one setting in this list that does not move a lab score; it protects the moment the cache is cold, which is when a fast site can suddenly behave like a slow one. When a page is purged, the next request rebuilds it. On a busy page, a hundred visitors can arrive during that rebuild and each one can invoke PHP. That is the stampede the setting exists to prevent.

With Serve Stale ON, visitors get the last cached copy while the new one is generated. The page stays fast under load. The trade-off is obvious: for a short window, someone can read the version you just corrected.

For articles, documentation, and most marketing pages, that is a good trade. For stock levels, prices, or anything with a legal deadline, it is not. Decide per site, not per checklist.

4. Load CSS Asynchronously Is the Biggest Render-Blocking Lever

This one is OFF by default, and it is the setting most likely to improve Largest Contentful Paint on a WordPress site weighed down by theme and plugin stylesheets. When enabled, CSS and HTML download in parallel instead of the browser waiting for stylesheets before it paints.

LiteSpeed handles the usual side effect automatically: it generates Critical CSS, the styles needed for above-the-fold content, and inlines them so the page does not flash unstyled. That generation is not instant on the first request, so test a cold page, not a warm one.

The failure mode is a page that renders with missing layout because the critical CSS missed a component. Check:

1. The homepage on a cold cache.
2. A long article with tables, code blocks, and embeds.
3. A WooCommerce product and cart page.
4. A mobile viewport, where the above-the-fold set is different.

If a component breaks, the fix is usually to exclude that stylesheet or fix the critical CSS, not to turn the feature off forever. The performance difference is worth a little testing. For context on what LCP actually measures, see web.dev’s LCP guide; for the wider sequence, our guide to hitting 90+ Core Web Vitals puts this setting next to images, fonts, and caching.

5. Load JS Deferred Has Two Modes, and One Is Much Riskier

Deferred and Delayed both wait for the HTML to finish parsing. The difference is what they wait for next.

• Deferred runs scripts as soon as the HTML is parsed. This is standard defer behavior.
• Delayed waits for user activity, such as a key press or a mouse movement.

LiteSpeed’s documentation says both improve the score, and Delayed has more potential because scripts that never run are excluded from the measurement. That is exactly why it needs caution. Analytics events, form validation, and consent banners can all miss their moment if nothing triggers the script.

Start with Deferred. Then, if you want to test Delayed, do it on staging with a list of scripts that must run immediately. A contact form that only validates after the first mouse movement is a worse outcome than four points on a lab score.

There is a second reason to be conservative: the score is a lab measurement. Google’s Core Web Vitals use field data from real visits, and a script delayed until interaction still runs for the people who interact. The field metric that captures that cost is INP, not “time to first mouse wiggle.”

6. Lazy Load Images Is OFF by Default, and That Is Fine

LiteSpeed does not enable image lazy loading out of the box. When you turn it on, WordPress core’s own lazy loading is disabled so the two do not fight.

The rule that matters: never lazy-load the image that is your LCP element. A hero image that waits for a scroll is a self-inflicted LCP problem. LiteSpeed’s Viewport Images service identifies the images in the first viewport and loads them eagerly; everything below the fold is lazy-loaded. VPI runs on QUIC.cloud, so it requires that service and may carry a fee.

If you are not using QUIC.cloud, exclude the hero image manually in the plugin’s lazy-load exclusions and keep the rest lazy. If QUIC.cloud is one option among several you are weighing, the CDN comparison covers what each network adds in front of the origin. The image optimization guide covers the format and sizing side; lazy loading only decides when the bytes are requested.

One more detail: lazy loading is a loading strategy, not a compression strategy. If the image is 2 MB, delaying it moves the problem down the page. Compress first, then decide when to load it. Browser-level behavior is documented in web.dev’s lazy loading guide.

The Settings That Usually Don’t Earn Their Risk

These are the ones most checklists enable by default. Each has a case, and none belongs in a first pass.

• CSS Combine and JS Combine. Both are OFF by default. On HTTP/2 and HTTP/3, many small files are not the penalty they were a decade ago, and combining can break plugins that expect their own handle. LiteSpeed’s own docs warn to test thoroughly. Turn them on only if you can measure a gain.
• Generate UCSS. Unique CSS is a QUIC.cloud service that builds a per-page stylesheet. It can shrink CSS a lot, and it needs storage for one file per page, two if Cache Mobile is on. It is a paid service with a real operational cost. Measure before committing.
• Cache Mobile. OFF by default. A responsive theme serves the same HTML to both viewports, so separate caches double the storage for no gain. It becomes relevant with a mobile-specific theme, AMP, or certain QUIC.cloud services.
• Instant Click. Prefetches a page when a visitor hovers a link. It can feel faster, and it generates requests for clicks that never happen. On a large navigation menu, that is real server load.

There is also a removed setting worth knowing about: Preload Featured Image no longer exists. Viewport Images replaced it. Advice that tells you to enable it is out of date.

Measure the Cache, Not the Score

A PageSpeed score is a lab estimate from one throttled run. The cache is a server behavior you can measure directly. This script samples URLs from a sitemap, records the cache header, and reports the hit rate and median time to first byte:

import re
import statistics
import time
import urllib.request

SITEMAP = "https://awplife.com/sitemap_index.xml"
LIMIT = 25

def fetch(url):
    request = urllib.request.Request(
        url, headers={"User-Agent": "cache-check/1.0"}
    )
    start = time.perf_counter()
    with urllib.request.urlopen(request, timeout=30) as response:
        body = response.read()
        elapsed = (time.perf_counter() - start) * 1000
        cache = (
            response.headers.get("x-litespeed-cache")
            or response.headers.get("x-qc-cache")
            or response.headers.get("x-lsadc-cache")
            or "none"
        )
        return body, cache, elapsed

index, _, _ = fetch(SITEMAP)
children = re.findall(r"<loc>([^<]+)</loc>", index.decode("utf-8", "ignore"))

urls = []
for child in children:
    if child.endswith(".xml"):
        body, _, _ = fetch(child)
        urls += re.findall(r"<loc>([^<]+)</loc>", body.decode("utf-8", "ignore"))

urls = [u for u in urls if not u.endswith(".xml")][:LIMIT]

results = []
for url in urls:
    _, cache, ms = fetch(url)
    results.append((url, cache, ms))

hits = [r for r in results if r[1] == "hit"]
median = statistics.median(r[2] for r in results)
print(f"{len(hits)}/{len(results)} cached, median TTFB {median:.0f} ms")
for url, cache, ms in results:
    print(f"{cache:>6}  {ms:>6.0f} ms  {url}")

Run it twice. The first request to a cold page produces a miss; the second pass shows the steady state visitors actually get. If the hit rate stays low, look for cookies, excluded URIs, or a page that sets no-cache itself.

Purge deliberately after changes:

wp litespeed-purge all

Then sample again. A cache that works is boring: high hit rate, stable TTFB, and a settings screen you rarely open. If you want a broader pass over the site after the change, the functionality, speed, and security check covers the parts a cache test cannot see.

Where This Leaves the Checklist

The plugin has dozens of options because WordPress sites differ. The six above are the ones tied to a measurable mechanism: storing a page, expiring it, rebuilding it under load, unblocking rendering, deferring scripts, and delaying off-screen images.

Everything else is conditional. That is not a reason to ignore it. It is a reason to stop enabling features because a list said so.

FAQ

Does LiteSpeed Cache work on Apache or nginx?

The optimization features work. The page cache does not. LiteSpeed’s documentation says caching requires a LiteSpeed server or the QUIC.cloud CDN, regardless of which server runs WordPress. Verify with the response header before configuring anything else.

What should I set for Default Public Cache TTL?

The one-week default is a reasonable starting point. Shorten it only if your purge rules are unreliable, and lengthen it to two weeks for pages that rarely change. The TTL caps how long a stale copy can live; purge rules decide when it is replaced.

Why do I always see X-LiteSpeed-Cache: miss?

Either the cache is not enabled, the server is not LiteSpeed, the request carries a cookie that forces a private copy, or the URI is excluded. Check the Excludes tab and test in a private window while logged out.

Is Delayed JavaScript worth the risk?

It can remove scripts from the lab measurement entirely, which flatters the score. It also delays analytics, forms, and consent logic until the visitor interacts. Test Deferred first, and only try Delayed on staging with a list of scripts that must run immediately.

Should I enable Lazy Load Images?

Yes for long pages with images below the fold, as long as the LCP image is excluded or handled by Viewport Images. LiteSpeed leaves the feature off by default, so turning it on is a choice you should make per site rather than per checklist.

Do CSS and JS Combine still help?

Less than they used to. HTTP/2 and HTTP/3 reduce the cost of multiple files, and combining can break plugins that expect separate handles. LiteSpeed marks both OFF by default and recommends testing. Enable them only when you can show a gain on your own pages.

Why did my PageSpeed score go up while Search Console stayed flat?

The lab score and field data measure different things. Core Web Vitals in Search Console use real visits over 28 days; a single Lighthouse run is synthetic. A cache hit can improve both, but a delayed script or a smaller CSS file may only move the lab number.