Optimization

Making WordPress Fast with LiteSpeed and LSCache on a VPS

BM BizMaC Team Jul 15, 2026 6 min read

WordPress is fast when the server stops rebuilding the same HTML on every request. The LiteSpeed stack solves that at two levels: a web server that reads a cache entry straight from memory, and a WordPress plugin that knows when to purge it. This guide walks through choosing between OpenLiteSpeed and LiteSpeed Enterprise, installing the stack on a fresh VPS, wiring up the LiteSpeed Cache plugin with page cache and a Redis object cache, and then measuring whether any of it actually moved TTFB. Versions cited are current as of mid 2026.

OpenLiteSpeed or LiteSpeed Enterprise

Both run the same LSCache engine, so both can serve cached pages from memory. The differences that matter in practice:

  • OpenLiteSpeed (OLS) is free and open source. The current branch as of 2026 ships QUIC v2, ACME auto SSL, and a rebuilt WebAdmin UI. It has one deliberate limitation: no .htaccess support, and configuration reloads are graceful but not instant.
  • LiteSpeed Enterprise (LSWS) is a paid, drop-in replacement for Apache. It reads .htaccess, supports Apache-style config, and adds ESI (edge side includes) for caching logged-in pages hole by hole.

For a single WordPress site on a VPS, OpenLiteSpeed is the pragmatic default. The cache hit path is identical, so the TTFB win comes from LSCache, not from paying for Enterprise. Reach for LSWS when you migrate an existing Apache setup that depends on .htaccess, or when you need ESI for personalized-but-cacheable pages. Check current details on the OpenLiteSpeed site and the LiteSpeed Web Server page.

Installing the stack

The one-click ols1clk script installs OpenLiteSpeed, PHP with the LSAPI connector, and MariaDB in one pass. Run it on a clean Debian or Ubuntu box as root:

wget https://raw.githubusercontent.com/litespeedtech/ols1clk/master/ols1clk.sh
chmod +x ols1clk.sh
./ols1clk.sh --lsphp 84 --wordpress --wordpresspath /var/www/html

This pulls lsphp84 (PHP 8.4, in active support through 2028; PHP 8.5 is the newest stable line if you prefer it). Install extensions WordPress and the plugin rely on, then set the WebAdmin password:

apt install lsphp84-redis lsphp84-imagick lsphp84-opcache
/usr/local/lsws/admin/misc/admpass.sh

The WebAdmin console lives on port 7080. Set the external port to 80 or 443 under the listener config so the site answers on standard ports. A modest VPS with dedicated CPU and RAM gives the cache real memory to hold hot pages and the object store, rather than swapping under a noisy shared host.

The LiteSpeed Cache plugin

LSCache is the component that delivers the TTFB win. The web server can only serve a cache entry that the plugin created and tagged. Install the current plugin (7.8.1 as of April 2026) from inside WordPress or over WP-CLI:

wp plugin install litespeed-cache --activate

Out of the box the plugin enables page caching if it detects a LiteSpeed server. Confirm it is on under LiteSpeed Cache > Cache, then verify with a header check:

curl -sI https://example.com/ | grep -i x-litespeed-cache

A miss on the first request followed by hit on the second means the page cache is live. If you never see the header, the request is not reaching LSCache, usually a listener or vhost mapping issue rather than a plugin one. The full option reference is in the LSCache for WordPress docs.

What page cache does and does not cover

Page cache stores the rendered HTML of guest-facing pages. It does not help logged-in users, the WordPress admin, or AJAX calls that hit the database directly. Those paths still run PHP and MySQL on every request, which is where object cache comes in.

Object cache with Redis

WordPress recomputes option lookups, term queries, and transients on requests that bypass the page cache. Redis holds those results in memory so PHP skips the round trip to MySQL. Install and start Redis:

apt install redis-server
systemctl enable --now redis-server

You already installed lsphp84-redis above, which is the PHP extension the plugin needs. Enable it under LiteSpeed Cache > Cache > Object, or over WP-CLI:

wp litespeed-option set object true
wp litespeed-option set object-kind 1
wp litespeed-option set object-host 127.0.0.1
wp litespeed-option set object-port 6379

Setting object-kind to 1 selects Redis over Memcached. Confirm the connection reports Connected in the plugin panel, then watch Redis take traffic:

redis-cli info stats | grep keyspace

Rising keyspace_hits means WordPress is reading from Redis instead of MySQL. Keep Redis bound to 127.0.0.1 and never expose 6379 to the public interface.

Image, CSS, and JS optimization

Cache fixes TTFB; front-end optimization fixes the rest of the load. LSCache handles this in the same plugin, so you avoid stacking a second optimization plugin that would fight it.

  • Images: the plugin can generate WebP and AVIF and serve them to browsers that accept them. The 2026 releases extended AVIF and WebP delivery to Safari 16.4 and later. Enable lazy load for images and iframes to cut initial payload.
  • CSS and JS: minify and combine, then enable Generate UCSS (unused CSS removal) to strip rules a given page never uses. Defer or async JS to unblock rendering.
  • Critical CSS: the plugin inlines above-the-fold CSS so the page paints before the full stylesheet arrives.

Turn these on one at a time and reload the front end after each. Combine and defer are the two settings most likely to break a theme, so test them in isolation rather than flipping every toggle at once.

Measuring TTFB and tuning PHP

Do not trust a settings panel to tell you it worked. Measure time to first byte directly, cold and warm:

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

Run it twice. The first request may be a cache miss; the second should return the cached page. On a working LSCache setup a warm guest request typically drops well under 100ms of server time, because the server returns HTML from memory without invoking PHP at all. If the warm number stays high, the page is not being cached, recheck the x-litespeed-cache header before touching anything else.

For the uncached paths (admin, checkout, logged-in views) PHP throughput is the ceiling. Two levers:

  1. OPcache: the lsphp84-opcache extension keeps compiled PHP bytecode in memory. Raise opcache.memory_consumption and opcache.max_accelerated_files in the lsphp INI for a large plugin set.
  2. LSAPI children: the LSAPI_CHILDREN value caps concurrent PHP workers. Set it against available RAM, roughly one worker per 40 to 60MB of real PHP process size, so bursts do not push the box into swap.
; /usr/local/lsws/lsphp84/etc/php/8.4/litespeed/php.ini
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1

Restart the server after INI changes with systemctl restart lsws, then re-run the TTFB check to confirm the numbers held.

Wrap-up

The stack works in layers, and each layer answers a different request type. LSCache page cache serves guest HTML from memory, which is where the headline TTFB win comes from. Redis object cache speeds up the logged-in and dynamic paths that skip the page cache. Image, CSS, and JS optimization trims what the browser downloads after that first byte. OpenLiteSpeed is free and enough for a single site; keep Enterprise in reserve for .htaccess or ESI needs. Verify every step with the x-litespeed-cache header and a curl TTFB measurement, because the only setting that counts is the one you can observe changing.