LiteSpeed Cache Setup Guide: The Only 9 Settings That Matter

A LiteSpeed Cache setup guide from an agency running it on 30+ sites — the settings that matter, the ones that break WooCommerce, and what to skip.

Dobromir Dechev
Dobromir WordPress agency owner

Quick answer

LiteSpeed Cache is the fastest WordPress caching plugin and it's free — but only on a LiteSpeed server, and only if you configure nine specific settings. This guide covers those nine, in order, plus the three that break WooCommerce.

LiteSpeed Cache is the fastest WordPress caching plugin available, it costs nothing, and roughly half the people running it have configured it badly enough that they'd get the same result from any free alternative.

The plugin has over two hundred settings. Nine of them do the work. This guide covers those nine in the order I apply them on client sites, plus the three that will break a WooCommerce store if you enable them without thinking.

One thing before anything else, because it invalidates everything below if you get it wrong.


Step 1: Confirm you're actually on a LiteSpeed server

LiteSpeed Cache's page caching is handled by the LiteSpeed server, not the plugin. The plugin is a control panel for a server module. On Nginx or Apache, that module doesn't exist, and page caching silently does nothing while the settings screen happily shows everything switched on.

curl -I https://yoursite.com | grep -i server

You want server: LiteSpeed or server: openlitespeed. Anything else — Nginx, Apache, cloudflare — and you should stop here and read our WP Rocket review instead, because that's the plugin for your server.

Hosts that run LiteSpeed as standard include Hostinger, A2, NameHero, and most cPanel resellers built on CloudLinux. If you're choosing a host partly to get free server-level caching, that's a legitimate reason — the plugin genuinely is faster than anything you can buy for Nginx.

Confirmed LiteSpeed? Good. Everything below applies.


Step 2: Install, then apply the Basic preset

Install LiteSpeed Cache from the plugin directory. Then go straight to LiteSpeed Cache → Presets and apply Basic.

The presets are:

PresetWhat it doesUse it?
EssentialsPage cache onlyToo conservative to bother
BasicCache + browser cache + safe mediaStart here
AdvancedAdds CSS/JS minifyAfter you've tested Basic
AggressiveAdds CSS combine, unused CSSOnly per-setting, never as a preset
ExtremeEverything, including JS combineNever on a client site

Applying Aggressive or Extreme in one click is the single most common way people break a site with this plugin. You turn on eight risky settings simultaneously, something breaks, and you have no idea which one did it. Basic gets you the page caching — which is the majority of the gain — with essentially zero risk.


Step 3: Page caching and TTL

Cache → Cache Control

  • Enable Cache: ON
  • Default Public Cache TTL: 604800 (one week)
  • Default Private Cache TTL: 1800
  • Cache Logged-in Users: OFF
  • Cache Commenters: OFF
  • Cache REST API: ON

A week sounds aggressive to people used to setting an hour. It isn't. LiteSpeed purges the cache automatically when you publish or update a post, change a menu, or update a widget. The TTL is only the fallback for pages nothing has touched — and a page nothing has touched doesn't need re-generating every hour.

Verify it's working before you configure another thing:

curl -I https://yoursite.com | grep -i litespeed

You want x-litespeed-cache: hit. First request is usually miss; run it twice. If you never see a hit, you're logged in (admins are excluded by design), or something in front of the site is stripping the header.


Step 4: Get a QUIC.cloud domain key

General → Request Domain Key

QUIC.cloud is LiteSpeed's optional cloud service. It handles critical CSS generation, unused CSS removal, and image optimisation — jobs too heavy to run on your own server. The free tier covers a typical small site's monthly usage.

You don't need it for the core wins. Page caching, object caching and browser caching are all local and all free forever. Request the key now anyway, because the approval isn't instant and you'll want it in Step 8.


Step 5: Object caching with Redis

Cache → Object

If your host offers Redis:

  • Object Cache: ON
  • Method: Redis
  • Host: 127.0.0.1
  • Port: 6379
  • Default Object Lifetime: 360

The status field must read Connected. If it doesn't, Redis isn't running or isn't on that port, and the setting is doing nothing.

Object caching stores the results of database queries in memory. Page caching handles anonymous visitors; object caching is what helps everyone else — logged-in users, WooCommerce customers, and the admin area. On a store, this is the setting that stops checkout from crawling under load.

If your host has no Redis, our database optimisation guide covers the alternatives for keeping query load down.


Step 6: Browser caching

Cache → Browser

  • Browser Cache: ON
  • Browser Cache TTL: 31557600 (one year)

One toggle, and it clears the "serve static assets with an efficient cache policy" warning in PageSpeed Insights. WordPress adds version query strings to its assets, so a year-long TTL doesn't stop updated files from reaching visitors.


Step 7: Media and lazy loading

Page Optimization → Media

  • Lazy Load Images: ON
  • Lazy Load Iframes: ON
  • Add Missing Sizes: ON
  • Lazy Load Image Excludes: your logo and hero image

That last one matters more than it looks. Lazy loading your largest above-the-fold image defers the exact element that Core Web Vitals measures as your Largest Contentful Paint — you make a real metric worse to satisfy a synthetic one. Add the logo and hero image to the exclude list by filename or CSS class.

Skip LQIP (low quality image placeholders) on most sites. It's an extra QUIC.cloud round trip for a blurry preview that shifts layout, and our lazy loading guide explains when it's worth the trade.


Step 8: CSS and JS optimisation — one at a time

Page Optimization → CSS Settings / JS Settings

This is where sites break. The rule is absolute: enable one setting, purge all, then load a page from every template you have. Home, single post, archive, product, cart, and any custom template. Then move to the next.

The order I use, safest first:

  1. CSS Minify — very low risk
  2. JS Minify — low risk
  3. CSS Combine — moderate risk, can reorder rules
  4. Generate Critical CSS (needs QUIC.cloud) — low risk, real LCP gain
  5. JS Defer — moderate risk, breaks scripts expecting immediate execution
  6. Unused CSS (needs QUIC.cloud) — highest risk

JS Combine deserves its own warning. It's the last item in the Extreme preset and the first thing I turn off on inherited sites. Combining JavaScript files was a meaningful optimisation under HTTP/1.1. Under HTTP/2, which every LiteSpeed server speaks, parallel requests are cheap and combining mostly just creates one large blocking file and new dependency-order bugs. Leave it off.


Step 9: ESI, if you run WooCommerce

Cache → ESI

  • Enable ESI: ON
  • Cache Mini Cart: ON

ESI (Edge Side Includes) is LiteSpeed's real advantage over every other caching plugin, and almost nobody enables it.

The problem it solves: a product page showing "Cart (2 items)" can't be cached, because the next visitor has a different cart. Most plugins solve this by excluding the whole page from caching. LiteSpeed punches a hole in the cached page for the cart widget alone — the page is served from cache, the cart fragment is generated per visitor.

The result is that product and category pages stay fully cached on a live store. On a catalogue of any size that's the difference between a fast store and a store that's fast only for people who haven't added anything yet.

Cart, checkout and my-account remain excluded from page caching automatically — you don't need to configure that, and you shouldn't try to override it. Our WooCommerce speed benchmark has the numbers on what this is worth.


Verifying the whole thing works

Four checks, in a private browsing window:

  1. curl -I https://yoursite.com | grep -i litespeed → expect x-litespeed-cache: hit on the second request
  2. Cache → Object → status reads Connected
  3. Load a page from every template and look for broken layouts
  4. Run PageSpeed Insights on a cached URL, not a fresh one you just purged

That fourth point catches people out constantly. Purge the cache, immediately run PageSpeed, and you're measuring an uncached page generation — a score 20 points below reality. Load the page yourself first, then test. Our 100 PageSpeed score guide covers what to do with what's left.


Bottom line: nine settings, one server requirement

LiteSpeed Cache beats every paid caching plugin on a LiteSpeed server, and it costs nothing. The whole configuration is page caching with a long TTL, Redis object caching, browser caching, careful lazy loading, CSS optimisation added one setting at a time, and ESI if you sell things.

The server requirement is the entire catch. On Nginx or Apache this plugin is a minification tool wearing a caching plugin's interface — go to WP Rocket instead and don't feel bad about the €59.


Frequently Asked Questions

Does LiteSpeed Cache work on Nginx or Apache?
The optimisation features do — minification, lazy loading, image optimisation. The page caching does not, because it depends on the LiteSpeed server module. Running it on Nginx gives you a fraction of the benefit and a false sense of security. Check your server header first; if it isn't LiteSpeed, use WP Rocket.
Is LiteSpeed Cache really free?
The plugin is completely free with no paid tier. QUIC.cloud, the optional service behind critical CSS, unused CSS and image optimisation, has a free monthly allowance that covers a typical small site, with paid credits beyond that. Page caching, object caching and browser caching never cost anything.
Which LiteSpeed Cache preset should I use?
Basic. Essentials is too conservative to be worth installing a plugin for, and Aggressive or Extreme turn on CSS combination and unused-CSS removal in one shot, which is exactly how you end up with a broken layout you can't attribute to any single setting. Start at Basic and add settings deliberately.
Do I need QUIC.cloud to use LiteSpeed Cache?
No. Page caching, object caching, browser caching and lazy loading all work without it, and those deliver most of the speed gain. QUIC.cloud only adds critical CSS, unused CSS removal, image optimisation and the CDN.
Why is my LiteSpeed cache not working after setup?
Three usual causes, in order of likelihood: the server isn't actually LiteSpeed, a security plugin or CDN is stripping the x-litespeed-cache header, or you're testing while logged in — WordPress admins are excluded from page caching by design. Test in a private window and check for an x-litespeed-cache hit header.
Does LiteSpeed Cache handle WooCommerce safely?
Yes, once ESI is enabled. Cart, checkout and my-account are excluded from page caching automatically, and ESI lets the cart widget render per-visitor inside an otherwise cached page. Without ESI you either lose caching on every page showing a cart total, or risk showing one visitor's cart to another.

Was this article helpful?