Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

Cache lab · Beginner · 20 min

LiteSpeed Cache: Prove the Hit Before You Tune Anything

Installing the plugin is not the same as caching the site — the only proof is a hit in the response headers on a logged-out repeat request.

View Reseller Hosting plansBrowse more How-To Library

The short answer

Install, activate, enable caching — then verify with curl -sI https://example.com | grep -i x-litespeed-cache, run twice: the first request should report a miss and the second a hit. Until you have seen that hit, nothing else on the settings page is worth touching.

The reason is architectural. LiteSpeed Enterprise on the server holds the cached page; the plugin only tells it what to store, what to skip and when to purge. So a plugin that is installed and configured but reporting miss on every request is not caching anything, and tuning its options will not change that.

By the HostingFast team · Reviewed 15 August 2026

Beginner

Assumed level

5

Stages to verified

Free

Support cost

Proven

Verified on production

Twenty minutes, and fifteen of them are verification. The install itself is three clicks, which is precisely why so many sites have the plugin active and no cache working.

NVMe storage behind a LiteSpeed cache is standard on every tier here, from Sprint upwards, so the server side of this is already in place on whatever plan you are on.

What is caching what

LiteSpeed Enterprise runs on the server and holds fully rendered pages in its own store. When it has a valid copy, the request is answered without starting PHP, without opening a database connection and without your application running at all. That is why a cache hit is not a small optimisation — it removes essentially all of the server-side work.

The plugin is the control surface. It declares which URLs are cacheable, how long copies live, which cookies mark a request as private, and what invalidates a copy when you publish. It does not do the caching, which is the single most useful thing to understand about it.

The verification loop, in one command

curl -sI https://example.com | grep -i x-litespeed-cache, twice. First run: miss, because nothing was stored. Second run: hit, because the first one populated the store. That two-line output is your whole proof of function, and it takes four seconds.

Do it logged out and without a query string. A login cookie marks the request as private and a query string can make the URL unique, so testing in the browser you administer the site from is the most common way to convince yourself the cache is broken when it is working perfectly.

The four things that guarantee a permanent miss

One: a login or session cookie on the request, which is correct behaviour rather than a fault. Two: a cache-busting query string, whether from an analytics parameter or your own code. Three: another plugin sending no-cache or private headers, which the cache is obliged to respect — a security or membership plugin is the usual culprit. Four: an exclusion rule already in the settings that you or a previous developer added and forgot.

Work through them in that order and the cause is almost always in the first two. If it is the third, the response headers will show a cache-control directive that explains the refusal, which is a much faster diagnosis than reading through settings pages.

Exclusions and a purge policy tied to deploys

Dynamic paths must not be cached. Cart, checkout and account pages on a store should have been excluded automatically, but verify it rather than assume: add something to a basket, then check the header on the cart URL and confirm it does not report a hit. Any bespoke dynamic endpoint you have written needs adding to the exclusion list yourself.

Then adopt a purge habit. Template edits, CSS changes and menu changes need a purge before visitors see them, and roughly every my change is not appearing report resolves at that button. Tie it to your deploy step and the question stops arising.

A performance-test needle sweeping hard to the right

The cache engine already running underneath you

LiteSpeed caching is built into the server on every plan here rather than patched in by plugin, and it sits in front of NVMe SSD storage on every tier from Sprint upwards.

That means the plugin you install is a control surface for hardware-adjacent caching rather than a PHP-level imitation of it.

  • Server and plugin roles separated clearly
  • One curl command that proves the cache works
  • Four causes of a permanent miss, in likelihood order
  • Support who will check the headers with you

Why HostingFast

Standard on every plan

Architecture before options

You learn that the server caches and the plugin instructs, which makes every later symptom interpretable.

Proof in four seconds

A single curl command run twice tells you whether the cache is functioning, before you spend an hour in the settings.

Miss causes ranked

Cookies, query strings, third-party no-cache headers, forgotten exclusions — checked in the order they actually occur.

Exclusions verified, not assumed

The store paths are supposed to be excluded automatically; the guide tells you to confirm it with a real basket.

Purge tied to deploys

Making the purge part of shipping removes the most common support question about caching entirely.

Server-level caching included

LiteSpeed is in the server on every tier, so none of this depends on buying a performance add-on.

Quick Start

From order to online

  1. 1

    Install, activate, enable — then stop configuring

    The stock lifetimes and rules suit most sites. Resist opening every tab before the basics are proven, because tuning an inactive cache produces confident changes with no effect.

  2. 2

    Prove the hit from the command line

    curl -sI https://example.com | grep -i x-litespeed-cache, run twice, logged out, no query string. Miss then hit is success. Miss then miss means work through the four causes before touching anything else.

  3. 3

    Measure what the cache is worth on your site

    TTFB logged out versus logged in, three runs each. The gap between those two numbers is the cache's contribution, expressed in milliseconds you can quote.

  4. 4

    Verify the exclusions against a real transaction

    Add an item to a basket, sign in, and check the headers on the cart, checkout and account URLs. They should not report hits. Add any custom dynamic endpoint of your own to the exclusion list.

  5. 5

    Make the purge part of shipping

    Purge after template, CSS and menu changes, as a step in your deploy rather than a thing you remember. Then re-run the curl check so the first visitor is not the one warming the cache.

Built In

Loaded onto every plan

  • LiteSpeed caching built into the server rather than patched in by plugin
  • NVMe SSD storage behind that cache on every tier, Sprint included
  • A purge control you own, in the panel and in the plugin
  • Per-site PHP version switching from the control panel
  • Full SSH access with Git and Composer for curl and WP-CLI checks
  • Built-in WebP image optimisation at no extra cost
  • Staging environments for testing cache changes before they ship
  • 99.9% uptime as the target, monitored around the clock
  • Money-back cover: 30 days on hosting plans, 7 on reseller
  • Human support on duty every hour of every day

Frequently Asked

What people ask us most often

Which requests can a page cache never serve?

Anything whose response depends on who is asking. A logged-in session, a basket with contents, a checkout, an account page, a personalised dashboard, and any endpoint that writes data. Those are all correctly excluded, and their exclusion is not a gap in your setup — it is what stops one customer seeing another's details. The performance work for those paths is a different job: PHP version, OPcache, object caching and query tuning.

How do I measure what the cache is actually saving me?

Compare TTFB logged out with TTFB logged in, three runs each, on the same template. The logged-out number is a cache hit; the logged-in number is your uncacheable path running in full. The difference is what the cache removes, in milliseconds, on your site rather than in a vendor's benchmark. It is also the number to quote when someone asks whether caching is worth configuring.

Do I still need a CDN if the server cache is working?

It depends on where your visitors are. Server-level caching removes the compute time; a CDN removes distance for static assets. If your audience is largely in one country and your server is in the same region, the cache does the heavy lifting and a CDN is a refinement. If your visitors are spread across continents, the network latency a CDN removes becomes the larger remaining share. Measure TTFB from a couple of distant locations before deciding.

What needs purging after a deploy?

Anything that changes the rendered HTML or the assets it references: templates, CSS, JavaScript, menus, widgets, and site-wide settings. Content edits normally purge their own page and its archives automatically. The safe habit is a full purge as the last step of a deploy, followed by one curl check so the cache is warm before a visitor arrives rather than after.

Keep reading

Changing hosts? Run through our checklist first.

A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

Caching that lives in the server.

LiteSpeed Enterprise in front of NVMe on every tier, a purge you control, WebP optimisation included, and engineers who will read the headers with you.

View Reseller Hosting plans