Speeding Up WordPress with OpenLiteSpeed: A Practical Guide

WordPress is flexible, but out of the box it is rarely fast. Every page view can trigger dozens of database queries, PHP execution, and remote calls before a single byte reaches the browser. OpenLiteSpeed (the open source edition of the LiteSpeed web server) tackles this at the server level, and when paired with the LiteSpeed Cache plugin it can turn a sluggish site into one that serves most requests as static files in milliseconds.

This guide walks through why OpenLiteSpeed helps, how to install it for WordPress, and how to configure caching and other tuning so the speedup is real rather than theoretical.

Why OpenLiteSpeed for WordPress

Apache and Nginx are both capable, but each has trade-offs for WordPress. Apache with mod_php is easy to configure but heavy under load. Nginx is fast but needs a separate PHP-FPM process and does not have a native, integrated page cache tied to WordPress.

OpenLiteSpeed sits in a useful middle ground:

• Event-driven architecture. Like Nginx, it uses an event-based model instead of one thread or process per connection, so it stays lean under concurrent traffic.
• Native LiteSpeed Cache integration. The LiteSpeed Cache (LSCache) plugin talks directly to the server, storing fully rendered pages and serving them without invoking PHP at all.
• Apache-compatible rewrite rules. It reads most .htaccess directives, so migrating an existing WordPress site is usually straightforward.
• Built-in HTTP/2, HTTP/3, and QUIC support, which reduce latency for modern browsers.

The single biggest win is the full-page cache. Once a page is cached, WordPress and the database are bypassed entirely for subsequent visitors, which is where most of the perceived speed improvement comes from.

Installing OpenLiteSpeed and PHP

The examples below assume a fresh Ubuntu server with root or sudo access. Adjust package names for your distribution.

Add the LiteSpeed repository and install the server:

wget -O - https://repo.litespeed.sh | sudo bash
sudo apt update
sudo apt install openlitespeed

Install a LiteSpeed-optimized PHP build. The lsphp packages are compiled to work efficiently with the server. Pick a current, supported PHP version and install the common extensions WordPress needs:

sudo apt install lsphp83 lsphp83-common lsphp83-mysql \
  lsphp83-curl lsphp83-imagick lsphp83-opcache

OpenLiteSpeed ships with a web admin console, by default on port 7080. Set the admin password before you log in:

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

Then visit https://your-server-ip:7080 to reach the admin panel. The public site is served on port 8088 by default until you configure it to listen on the standard ports 80 and 443.

Configuring the site and PHP handler

Inside the admin console, the main tasks are:

1. Point the virtual host to your WordPress directory. Set the document root to where WordPress lives (for example /var/www/wordpress).
2. Attach the correct lsphp handler. Under the virtual host script handler settings, make sure PHP requests are routed to the lsphp83 binary you installed.
3. Switch listeners to ports 80 and 443. Edit the listener configuration so the public site serves on standard ports, then map your domain to the virtual host.

After any configuration change, apply it by performing a graceful restart:

sudo /usr/local/lsws/bin/lswsctrl restart

Enable OpCache through your lsphp configuration. OpCache stores precompiled PHP bytecode in memory so the interpreter does not reparse your plugin and theme files on every request. This is a meaningful gain even for uncached, dynamic pages such as logged-in admin views.

Installing and tuning LiteSpeed Cache

The server alone speeds things up, but the LiteSpeed Cache plugin is where WordPress-specific caching happens. Install it from the WordPress plugin directory (search for “LiteSpeed Cache”) and activate it.

Once active, work through these core settings:

• Enable the cache. Turn on the main cache toggle. With OpenLiteSpeed detected, the plugin will store full-page output that the server serves directly.
• Set sensible TTLs. A public page TTL of an hour or more is common for content that changes infrequently. The plugin automatically purges relevant pages when you publish or edit a post, so long TTLs are safe.
• Exclude what must stay dynamic. Cart, checkout, account, and admin pages should never be cached for logged-in users. LiteSpeed Cache handles most of this automatically for WooCommerce, but verify it on your own site.
• Enable object caching if available. If you have Redis or Memcached installed, point the plugin at it. Object caching stores the results of database queries, which speeds up pages that cannot be fully page-cached (like the admin dashboard).

Optimizing assets and images

Serving cached HTML is only part of the story. The browser still has to download CSS, JavaScript, fonts, and images. LiteSpeed Cache includes optimization features that reduce this payload:

• Minify and combine CSS/JS. Start with minification, which is low risk. Combining files can occasionally break themes, so test each toggle and check the front end before moving on.
• Defer or lazy-load JavaScript. Deferring non-critical scripts lets the page render before all JS finishes downloading.
• Lazy-load images. Images below the fold load only as the user scrolls, cutting initial page weight.
• Generate and serve WebP. Modern image formats are significantly smaller than JPEG or PNG at equivalent quality.

Change one optimization at a time and re-test. Aggressive combining and deferral are the most common cause of visual glitches, so incremental changes make it easy to identify a culprit.

Verifying the speedup

Do not trust the settings, measure them. Use a few complementary tools:

• Response headers. Fetch a page and look for an x-litespeed-cache header. A value of hit confirms the request was served from cache rather than regenerated by PHP.
• Browser dev tools. Check the Network tab for time to first byte (TTFB) and total transfer size before and after your changes.
• Command line timing. A quick loop with curl against a public URL gives you a repeatable TTFB number:

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

Run the check twice. The first request may miss the cache and be slow; the second should hit the cache and drop sharply. That gap is the value OpenLiteSpeed plus LSCache is delivering.

Common pitfalls

A few issues trip up most first-time setups:

• Personalized content served from cache. If visitors see someone else’s cart or a stale logged-in state, your cache exclusions are wrong. Double-check that user-specific pages bypass the cache.
• PHP handler mismatch. If the site returns raw PHP code or a blank page, the virtual host is not routing requests to the lsphp binary.
• Firewall blocking ports. Remember to open 80, 443, and (temporarily) 7080 for the admin console, and consider restricting 7080 to your own IP afterward.
• Over-optimizing assets. If the layout breaks after enabling combine or defer, disable those toggles and reintroduce them one by one.

Takeaway

Most WordPress slowness comes from regenerating the same pages over and over. OpenLiteSpeed with LiteSpeed Cache attacks that directly: full-page caching serves visitors static HTML at the server level, OpCache accelerates the dynamic requests that remain, and asset optimization trims what the browser downloads. Install the server and matching lsphp build, wire up the cache plugin with sensible exclusions, then measure your TTFB and cache hit headers to confirm the gains. Change settings incrementally, verify each step, and you will get a fast site that also stands up under real traffic.