Install LiteSpeed Cache for WordPress on a VPS

Your WordPress site can still feel “slow” even when CPU and RAM look fine. A common culprit is TTFB. The server keeps rebuilding pages that should be served from cache.

This walkthrough shows you how to install LiteSpeed Cache for WordPress on a VPS, enable server-side caching, connect QUIC.cloud, and apply cache rules. The goal is to keep carts, accounts, and logged-in sessions behaving correctly.

You’ll need root (or sudo) access to your VPS or dedicated server. You’ll also need control over your domain’s DNS.

If you don’t have a VPS yet, start with a predictable baseline. A small-to-mid WordPress stack runs well on a HostMyCode VPS. If you’d rather not babysit OS updates or web stack tuning, managed VPS hosting keeps routine maintenance handled.

What you’ll build (and what you should see at the end)

LiteSpeed Web Server (OpenLiteSpeed or LiteSpeed Enterprise) serving WordPress
LSCache enabled at the web server + WordPress plugin level
QUIC.cloud linked for CDN/edge caching (optional but recommended)
Safe cache exclusions for logged-in users, WooCommerce carts/checkout, and wp-admin
Verification steps: headers, cache hits, TTFB checks, and common “why isn’t it caching?” fixes

Prerequisites and a quick reality check

Before you change anything, confirm the site is stable. Then capture a baseline so you can measure improvement.

A domain (example: example.com) pointing to your server’s IP
WordPress installed and working over HTTPS
SSH access and sudo privileges
10 minutes to baseline TTFB so you can prove the change helped

Baseline TTFB: run this from your laptop/terminal (replace the domain):

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

Save the TTFB number. Once LSCache is working, repeated requests should drop noticeably.

You’ll often see ~0.4–1.2s fall to ~0.05–0.2s, depending on theme/plugins and server.

If you still need to set up TLS, follow HostMyCode’s step-by-step guide: Configure HTTPS with Let’s Encrypt on a VPS.

Choose your LiteSpeed path: OpenLiteSpeed vs Enterprise

You have two practical options for running LSCache on a VPS:

OpenLiteSpeed (OLS): free, fast, and supports LSCache. A solid fit for single sites and most small-to-medium installs.
LiteSpeed Enterprise (LSE): paid, often works as a drop-in replacement for Apache, with extra features and a smoother path in cPanel/WHM environments.

This tutorial uses OpenLiteSpeed because it’s straightforward on a clean VPS.

If you’re on cPanel/WHM and want to keep Apache-compatible workflows, LSE is usually the better match.

Step 1 — Install OpenLiteSpeed on Ubuntu 24.04 / Debian 12

On a fresh Ubuntu 24.04 or Debian 12 VPS, install OpenLiteSpeed from the official repository packages.

Ubuntu 24.04

sudo apt update
sudo apt install -y wget gnupg ca-certificates lsb-release

wget -qO- https://rpms.litespeedtech.com/debian/enable_lst_debian_repo.sh | sudo bash

sudo apt update
sudo apt install -y openlitespeed

Debian 12

sudo apt update
sudo apt install -y wget gnupg ca-certificates lsb-release

wget -qO- https://rpms.litespeedtech.com/debian/enable_lst_debian_repo.sh | sudo bash

sudo apt update
sudo apt install -y openlitespeed

Start and enable the service:

sudo systemctl enable --now lsws
sudo systemctl status lsws --no-pager

Verify: OpenLiteSpeed typically listens on:

HTTP: :8088 (default test page)
WebAdmin: :7080

Check listening ports:

sudo ss -ltnp | egrep '(:7080|:8088)'

Step 2 — Lock down the WebAdmin port (don’t leave :7080 open)

Port 7080 is the LiteSpeed admin UI. Treat it like a control panel login.

Restrict access.

The simplest approach is firewall allowlisting for your IP.

If you use UFW:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from YOUR.IP.ADDR.HERE to any port 7080 proto tcp
sudo ufw enable
sudo ufw status verbose

Need a safe baseline firewall setup? Use: Set up UFW on Ubuntu for a web server.

Set the WebAdmin password (OLS ships a helper):

sudo /usr/local/lsws/admin/misc/admpass.sh

Verify: Visit https://YOUR_SERVER_IP:7080. You’ll likely see a browser warning because it uses a self-signed certificate. That’s fine for admin access.

(You can later reverse proxy it internally if needed.)

Step 3 — Install PHP (lsphp) and common extensions

WordPress needs PHP plus a handful of modules. LiteSpeed uses its own PHP packages named lsphp.

Install PHP 8.3 packages (a stable default in 2026 for WordPress on modern distros).

sudo apt install -y lsphp83 lsphp83-common lsphp83-mysql lsphp83-curl lsphp83-opcache \
  lsphp83-xml lsphp83-gd lsphp83-imagick lsphp83-zip lsphp83-mbstring lsphp83-intl

Verify PHP:

/usr/local/lsws/lsphp83/bin/php -v

A common slip-up is installing system PHP (php-fpm) and never wiring LiteSpeed to it. Sticking with lsphp avoids that mismatch.

Step 4 — Create a vhost for your domain and point it at WordPress

You can build the vhost entirely in WebAdmin. Focus on the settings that control behavior: document root, PHP handler, and rewrite rules.

Assume your WordPress code will live at:

/var/www/example.com/public_html

Create the directory and set ownership. Use a dedicated user if you prefer.

Here we’ll use www-data on Ubuntu/Debian:

sudo mkdir -p /var/www/example.com/public_html
sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 755 {} \;
sudo find /var/www/example.com -type f -exec chmod 644 {} \;

If you’re migrating an existing WordPress site, do the cutover carefully. HostMyCode has a solid runbook: DNS cutover tutorial for migrating a website to a new VPS.

WebAdmin steps (high-level, but exact fields):

Log into WebAdmin: https://SERVER_IP:7080
Go to Virtual Hosts → Add
- Virtual Host Name: example
- Virtual Host Root: /var/www/example.com
- Config File: /var/www/example.com/conf/vhconf.conf
Click the vhost → General
- Document Root: /var/www/example.com/public_html
Go to Script Handler → add:
- Suffixes: php
- Handler Type: lsapi
- Handler Name: lsphp83
Go to Rewrite
- Enable Rewrite: Yes
- Auto Load from .htaccess: Yes
Go to Listeners → add listener on :80 and map domain example.com to the vhost.

Apply changes: click Graceful Restart in WebAdmin.

Verify:

curl -I http://example.com

You should get a response, even if WordPress isn’t in place yet.

Step 5 — Install WordPress and create the database

If you already have WordPress running, skip ahead to the plugin step.

For a fresh install, MariaDB is the usual choice.

Install MariaDB:

sudo apt install -y mariadb-server
sudo systemctl enable --now mariadb

Secure it:

sudo mysql_secure_installation

Create DB/user (replace values):

sudo mysql -u root -p <<'SQL'
CREATE DATABASE wp_example DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'REPLACE_WITH_STRONG_PASSWORD';
GRANT ALL PRIVILEGES ON wp_example.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;
SQL

Install WordPress files:

cd /var/www/example.com/public_html
sudo -u www-data wget -q https://wordpress.org/latest.tar.gz
sudo -u www-data tar xzf latest.tar.gz --strip-components=1
sudo -u www-data rm -f latest.tar.gz

Finish setup by visiting http://example.com in your browser.

If you want a backup-safe DB routine as you grow, keep this tutorial bookmarked: Install MariaDB and create secure backups on Ubuntu.

Step 6 — Enable HTTPS for the site (needed for QUIC.cloud and real-world performance)

OpenLiteSpeed can handle Let’s Encrypt, or you can terminate TLS in front with another proxy.

On a typical single-site VPS, terminating TLS directly in LiteSpeed is usually simplest.

If you want a known-good checklist (including common SSL errors), use HostMyCode’s 2026 TLS tutorial: TLS setup guide tutorial (2026).

Verify HTTPS:

curl -I https://example.com

Step 7 — Install LiteSpeed Cache for WordPress and confirm it can talk to LSWS

This is where many installs go sideways. The plugin alone isn’t the point.

You need LiteSpeed at the web server layer, and it must send (and honor) the right cache headers.

In WordPress Admin → Plugins → Add New
Search LiteSpeed Cache → Install → Activate

Verify it’s detected correctly: go to LiteSpeed Cache → Dashboard. You want to see that LiteSpeed is detected and caching is available.

Then confirm from your terminal. Run two requests back-to-back:

curl -I https://example.com/ | egrep -i 'x-litespeed-cache|x-qc-cache|cache-control|x-powered-by'

On a working setup, you’ll usually see LiteSpeed-related headers.

After the cache is warm, subsequent requests should show a cache hit header such as X-LiteSpeed-Cache: hit.

Step 8 — Turn on LSCache with safe defaults (don’t cache what shouldn’t be cached)

Open LiteSpeed Cache → Cache. These settings are a safe starting point for most sites:

Enable Cache: ON
Cache Logged-in Users: OFF (leave it off unless you truly need it)
Cache Commenters: OFF
Cache REST API: OFF (many sites break if cached)

If you run WooCommerce:

WooCommerce tab → Enable WooCommerce Cache: ON
Make sure cart/checkout/my-account pages are excluded (the plugin typically handles this automatically, but verify below)

Verify exclusions quickly: while logged in as an admin, browse a few pages. Check response headers in DevTools → Network.

You should not see cache hits on wp-admin screens. You should also never see cached HTML for personalized pages.

Step 9 — Configure QUIC.cloud CDN (optional, but usually worth it)

QUIC.cloud can add edge caching, image optimization, and bandwidth offload. If your visitors are spread out geographically, it can also reduce latency in Core Web Vitals.

In WordPress → LiteSpeed Cache → General
Set Request Domain Key and follow the prompts to link your domain
Turn QUIC.cloud CDN ON after the key is active

Verify QUIC.cloud is active:

curl -I https://example.com/ | egrep -i 'x-qc-cache|server|cf-cache-status|x-litespeed-cache'

You’re looking for QUIC.cloud headers such as X-QC-Cache on cached responses. A first-request miss is normal.

The cache needs a warm-up pass.

Common mistake: the CDN is enabled, but DNS still points at an old IP.

Another common issue is mixed content. Fix mixed content before you judge performance.

Step 10 — Page optimization settings that usually help (and the ones that commonly break sites)

LSCache includes a lot of toggles. Treat each one like a production change.

Enable one group, test key pages, then continue.

Start with these “low drama” wins

LiteSpeed Cache → Page Optimization → CSS Settings
- CSS Minify: ON
- Combine CSS: OFF (often breaks HTTP/2+ sites with many plugins)
JS Settings
- JS Minify: ON
- Combine JS: OFF (common source of checkout/login issues)
- Load JS Deferred: ON (test carefully if you have heavy page builders)
HTML Settings
- HTML Minify: ON

Image optimization (often large savings)

In LiteSpeed Cache → Image Optimization:

Auto Request Cron: ON
Auto Pull Cron: ON
WebP Replacement: ON

Verify: after optimization runs, inspect an image request in DevTools. You should see image/webp (where supported) and smaller transfer sizes.

Settings that break sites most often

Combine CSS/JS: breaks dependency order
Inline critical CSS: can cause flashes and layout shifts if misconfigured
Delay JS: can break analytics, cookie banners, and add-to-cart events

Only touch those after caching is stable and you’ve tested the basics end to end.

Step 11 — Make cache purges predictable (so your edits show up instantly)

A good caching setup disappears into the background. Purge rules are what keep editors and stores from fighting the cache.

In LiteSpeed Cache → Cache → Purge:

Leave the defaults unless you publish high-frequency content.
If you run WooCommerce with frequent price/stock changes, ensure product pages purge on updates (typically default behavior).

Quick test: edit a page, update it, then refresh in an incognito window. If you still see the old version, check the plugin’s purge log.

Also confirm your page isn’t stuck behind an external cache.

Step 12 — Verify you’re getting real cache hits (server-side, not “browser cache”)

Don’t guess. Check headers and measure the difference.

Check cache hit/miss headers

# First request (likely MISS)
curl -I https://example.com/ | egrep -i 'x-litespeed-cache|x-qc-cache|age|cache-control'

# Second request (should become HIT for public pages)
curl -I https://example.com/ | egrep -i 'x-litespeed-cache|x-qc-cache|age|cache-control'

Measure TTFB improvement

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

The second run should be lower. If it isn’t, you’re not caching.

Another possibility is that something is forcing no-cache headers.

Confirm logged-in pages aren’t cached

Log into wp-admin, then request the homepage with your logged-in cookies. The easiest check is in a browser.

Verify you don’t see cache hit headers on personalized/admin views.

Step 13 — Common reasons LSCache doesn’t work (and how to fix each)

You’re still behind Nginx/Apache serving the site. The plugin can’t do server-side LSCache without LiteSpeed serving the vhost. Confirm the Server header and what process binds to :80/:443 (sudo ss -ltnp | egrep '(:80|:443)').
WordPress is sending no-cache headers globally. Check for security plugins, membership plugins, or custom code setting Cache-Control: no-store.
Mixed content or wrong site URL. Fix WordPress Address / Site Address in Settings and ensure HTTPS redirect is correct.
WooCommerce cart/checkout caching. Keep “Cache Logged-in Users” OFF, and verify WooCommerce exclusions are active.
Cloud proxy cache conflict. If you use an external CDN/proxy, avoid double-caching HTML with competing rules.

Step 14 — Add monitoring so you notice regressions (before customers do)

Caching issues often show up as TTFB spikes. They don’t always show up as obvious CPU alarms.

Add lightweight monitoring plus an uptime check so you catch problems early.

For server metrics: Run Netdata on a VPS for live server monitoring
For external checks and simple alerts: Self-host Uptime Kuma on a VPS

After enabling LSCache, keep an eye on:

Lower average response time and fewer PHP workers busy
Reduced database queries per page view (indirectly, because fewer pages hit PHP)
Stable login/checkout flows (no “wrong user’s data” symptoms)

Step 15 — Basic hardening you should do on the same day

It’s easy to get tunnel vision on performance. Do the basic security tasks while you already have SSH open.

Disable XML-RPC if you don’t need it (many sites don’t).
Use correct file permissions and keep wp-config.php locked down.
Limit wp-admin access if you can (VPN or allowlist IPs).

Follow this practical hardening checklist: WordPress hardening tutorial (2026).

Summary: the “working setup” checklist

LiteSpeed (OLS/LSE) is actually serving the site on :80/:443
LiteSpeed Cache plugin installed and enabled
Public pages show cache HIT headers on repeat requests
Logged-in pages and WooCommerce cart/checkout are not cached incorrectly
QUIC.cloud enabled (optional) and verified via response headers
TTFB improved measurably with curl before/after

If you want LSCache speed without wondering whether your VPS has enough headroom, start with a plan sized for WordPress traffic. A HostMyCode VPS gives you dedicated resources, and HostMyCode WordPress hosting is the simpler option if you’d rather skip server maintenance.

FAQ

Do I need LiteSpeed Web Server for LiteSpeed Cache to work?

For full server-side page caching, yes. The plugin can still handle some optimizations on other stacks, but LSCache (the fast part) requires LiteSpeed to serve the site.

Will LiteSpeed Cache break WooCommerce checkout or logged-in pages?

Not if you keep “Cache Logged-in Users” off and confirm WooCommerce exclusions. Always test add-to-cart, checkout, and account pages after enabling any page optimization toggle.

How do I confirm I’m getting cache hits?

Check response headers. Run curl -I https://example.com twice and look for X-LiteSpeed-Cache: hit (or QUIC.cloud cache headers if you enabled it).

Should I enable CSS/JS combining?

Usually no on modern HTTP/2/HTTP/3 sites. Minification is safer. Combining often breaks plugin scripts and can create harder-to-debug layout issues.

What’s the quickest rollback if something goes wrong?

Disable page caching in LiteSpeed Cache → Cache, then disable Page Optimization toggles (especially JS defer/delay). If needed, temporarily deactivate the plugin and purge all caches.