LiteSpeed and LSCache for WordPress, Explained

LiteSpeed shows up in two places when you run WordPress. LiteSpeed Web Server is software some hosts run on their machines. LiteSpeed Cache, usually called LSCache, is a free WordPress plugin. The plugin installs on any WordPress site, but its main job, caching your pages, only works when the server underneath is LiteSpeed.

I run WordPress sites on LiteSpeed servers. Here's how the pieces fit, including QUIC.cloud and Cloudflare, drawn from each company's own documentation, and then how I put them together.

What LiteSpeed Web Server is

A web server is the program that answers each visitor's request and hands the work to WordPress when a page has to be built. Apache and nginx are two; LiteSpeed Web Server is another.

LiteSpeed Technologies sells LiteSpeed Web Server as a drop-in replacement for Apache. It reads Apache's configuration files directly, supports .htaccess files, and works with control panels written for Apache, such as cPanel, Plesk and DirectAdmin. LiteSpeed describes it as event-driven like nginx, rather than process-based like Apache, and says that lets it serve more visitors with less memory and CPU.

OpenLiteSpeed is the free, open-source edition. For WordPress, two differences matter: it doesn't support ESI (more on that below), and plugin settings that change .htaccess need a server restart (LiteSpeed FAQ).

The cache itself is built into the server. The plugin is the interface: it tells the server's cache what to store, for how long, and when to clear it.

What the plugin does on each kind of server

LiteSpeed Cache is free, open source and made by LiteSpeed Technologies. Its features fall into two groups:

• Cache features need a LiteSpeed product underneath: LiteSpeed Web Server, OpenLiteSpeed, LiteSpeed Web ADC (LiteSpeed's load balancer), or QUIC.cloud CDN.
• Optimization features work on any server, Apache and nginx included.

That's from the plugin's WordPress.org page. On Apache or nginx without QUIC.cloud, LiteSpeed's installation guide says none of the caching functionality is available there: it's an optimization plugin, not a page cache.

Server-level page caching

Normally, every visit to a WordPress page makes the server run PHP, query the database and build the HTML from scratch. A page cache saves the finished page and hands that copy to the next visitor instead. LSCache does this in the server, not inside WordPress, so as the plugin's FAQ puts it, the server can skip PHP and the database altogether. Nothing is written into your WordPress files.

From LiteSpeed's cache documentation:

• Public and private cache. The public cache holds pages that are the same for everyone. The private cache holds copies for each logged-in user, identified by IP address and session ID.
• ESI. Edge Side Includes let LSCache "punch holes" in a cached page for the parts that differ per person, like the admin bar, and cache each piece separately. LiteSpeed notes it costs some server efficiency.
• WooCommerce. My Account, Checkout and Cart are left out of the cache by default, and LiteSpeed recommends ESI for stores.
• One page cache at a time. Deactivate any other full-page cache plugin before activating LSCache.

To switch caching on, go to LiteSpeed Cache > Cache > Cache and set Enable Cache to ON. LiteSpeed's beginner's guide says the defaults are chosen to work for most sites.

To check it's working, open a page in a private window, open your browser's developer tools and reload. In the Network tab, the first item's response headers should show X-LiteSpeed-Cache: miss (just stored), then hit on the next reload (served from the cache). If neither appears, LSCache isn't caching that page (LiteSpeed's instructions). Through QUIC.cloud's CDN, the header is X-QC-Cache.

Purging: how cached pages stay current

Purging means clearing pages out of the cache so visitors don't get an old copy. By default, most pages stay cached for a week unless something purges them sooner (TTL settings).

Most purging happens on its own. When you edit a page, the plugin purges it along with related pages such as category, tag and date archives. Under LiteSpeed Cache > Cache > Purge, the Auto Purge Rules For Publish/Update decide which related pages get cleared. The same tab has Purge All on Upgrade, which clears everything when WordPress, a theme or a plugin updates; LiteSpeed's docs recommend having it on.

You can also purge by hand:

• One page: while logged in, visit the page and choose Purge this page - LSCache from the LiteSpeed menu in the admin bar.
• The whole site: in LiteSpeed Cache > Toolbox > Purge, Purge All - LSCache clears every cached page for this WordPress install. Purge All also clears the plugin's other caches, except Critical CSS, Unique CSS and image placeholders, which would cost QUIC.cloud credit to regenerate (Toolbox documentation).

LiteSpeed says you shouldn't need to purge the whole site often, if at all. After updates is the usual time; it's step five of my monthly WordPress maintenance checklist.

Image optimization and the other extras

The rest of the plugin is optional, and much of it runs through QUIC.cloud (next section).

Image optimization. On request, the plugin sends your images to QUIC.cloud's servers, which shrink them and send them back; per the plugin's privacy notes, QUIC.cloud deletes its copies within seven days. It isn't automatic unless you turn on Auto Request Cron, and it makes WebP and AVIF copies only if you enable that. Each image can end up as three files: optimized, next-generation format, and a backup of the original (Image Optimization documentation).

Page optimization. Minifying and combining CSS and JavaScript, deferring scripts, lazy-loading images, and QUIC.cloud's Critical CSS and Unique CSS services. LiteSpeed's documentation for this section opens with a warning: test these options thoroughly before using them on your live site, and Purge All after changing them (Page Optimization documentation).

Presets. LiteSpeed Cache > Presets has five bundles: Essentials, Basic, Advanced, Aggressive and Extreme. Applying one backs up your settings first, so you can go back. LiteSpeed rates the risk itself: Essentials can't break your site, Aggressive may introduce CSS or JavaScript conflicts, and Extreme is likely to. Every preset above Essentials needs QUIC.cloud (Presets documentation).

Guest Optimization. Used with Guest Mode, this setting gives first-time visitors and speed-test tools a cached page with the maximum level of optimization. LiteSpeed is frank: it improves page speed scores, it can mask real problems, and you should turn it off when you want an accurate result from a speed test (General settings documentation).

What it costs. The plugin is free. Some QUIC.cloud services are free up to a monthly allowance and charge after that; LiteSpeed's FAQ points to your QUIC.cloud dashboard for current costs.

What QUIC.cloud is

QUIC.cloud is where LiteSpeed's online services live: LiteSpeed's docs say all of them, image optimization included, are hosted there. It offers two things:

• Online services: Image Optimization, Critical CSS, Unique CSS, Viewport Images and Low-Quality Image Placeholders. You don't have to use the CDN to use these (QUIC.cloud documentation).
• A CDN: QUIC.cloud CDN uses the LiteSpeed Cache plugin to capture cached copies of your pages and serves them from locations around the world (CDN overview). Because it follows the plugin's purge rules, QUIC.cloud describes it as caching WordPress's dynamic pages, not just static files. It also counts as a LiteSpeed product for the plugin's cache features, which is how a site on Apache or nginx gets LSCache's page caching.

QUIC.cloud's CDN also lists security features such as WordPress brute-force protection. For security on the site itself, see my WordPress security checklist.

To connect a site, go to LiteSpeed Cache > General > Online Services and press Enable QUIC.cloud services. Older guides tell you to add a domain key; that setting was deprecated in version 7 of the plugin.

Where a CDN fits: QUIC.cloud or Cloudflare

Cloudflare defines a content delivery network as a group of servers spread across many places that speeds up delivery by caching content closer to visitors. It doesn't replace your hosting: WordPress still runs on your server, and the CDN sits in front of it (Cloudflare). Either one means changing your domain's DNS so visitors reach the CDN first: QUIC.cloud's onboarding includes pointing your DNS to it, and a full Cloudflare setup makes Cloudflare your primary DNS provider (Cloudflare DNS documentation).

QUIC.cloud is built around LSCache. It can cache the pages themselves, not only images and files, and clear them with the purge rules the plugin already applies.

Cloudflare decides what to cache by file extension, and by default it doesn't cache HTML (Cloudflare cache documentation). So with default settings, Cloudflare serves your images, CSS and JavaScript, while each page's HTML still comes from your server, where LSCache can answer from its cache. Cloudflare's Automatic Platform Optimization (APO) caches the whole WordPress site, dynamic pages included, and needs the Cloudflare for WordPress plugin. Cloudflare's DDoS protection is available on all plans.

The LiteSpeed Cache plugin has a Cloudflare tab. With your Cloudflare API details in it, you can purge Cloudflare's cache from WordPress and have it purged automatically whenever LiteSpeed's Purge All runs (CDN documentation). One caution from LiteSpeed: don't turn on APO alongside LSCache's Guest Mode or ESI. APO is a page cache too, and LiteSpeed says not to run two tools that do the same job.

Two questions before adding either. Where are your visitors? A CDN helps by serving from somewhere near them, so if most are close to your server, the network matters less than the cache. And who will test it? After setup, edit a page and check, logged out, that the change shows.

Measuring whether it helped

Don't take a speed claim on trust, including LiteSpeed's:

• Check the cache header on your key pages while logged out, as above.
• Run them through PageSpeed Insights and look at the field data, what real visitors experienced, not just the lab score, which Guest Optimization can flatter. My guide to Core Web Vitals explains the three numbers and where to find them.
• Re-test after changes, including the contact form, cart and checkout, logged out.

How I run it

Every WordPress site I host sits on the same stack:

• LiteSpeed Web Server, so the plugin's server-level page cache can do its job.
• The LSCache plugin, set up on each site to work with the server's cache.
• Cloudflare in front, as the CDN. It caches at its edge, and its firewall runs a set of custom rules I've written and keep up to date. I don't publish the rules themselves: a firewall works better when attackers can't read it.
• QUIC.cloud's online services, not its CDN, for image compression and other optimization work. I also turn on the plugin's guest mode.

The result is that most visitors get a page that's already built instead of one WordPress has to assemble for them, and requests my rules flag are stopped at Cloudflare before they reach the server.

How I can help

I host and look after existing WordPress sites on that setup, case by case. Tell me about yours and I'll send a written quote for hosting and upkeep before anything changes. Content and design changes aren't included. A $500 deposit starts the quote. It's refundable until you accept, and credited to the work. Ask for a quote.

For what that upkeep covers, see what it takes to look after a WordPress site.