How to Optimize WordPress Performance on LiteSpeed Hosting
Google's 2025 Core Web Vitals report found that WordPress sites with a Time to First Byte (TTFB) under 200ms are 53% more likely to rank on page one than sites with TTFB above 800ms. The gap isn't about content quality or backlink profiles. It's about how the server processes and delivers each request.
The hosting stack underneath WordPress determines more about speed than any theme or plugin choice. LiteSpeed Web Server, paired with the right caching and PHP configuration, consistently produces TTFB measurements in the 80-180ms range. Apache on the same hardware lands between 400ms and 1.2 seconds.
This article walks through every optimization layer available on a LiteSpeed hosting environment, with specific benchmarks at each step.
LSCache: The Single Biggest Speed Improvement
LiteSpeed Cache (LSCache) is a server-level caching engine built into LiteSpeed Web Server. Unlike application-level caching plugins that run inside PHP, LSCache stores pre-rendered HTML pages at the web server layer and serves them without touching PHP or MySQL.
How LSCache Works
When a visitor requests a WordPress page, PHP executes, queries the database 30-80 times, assembles the HTML, and sends it to the browser. LSCache intercepts the final rendered output and stores it as a static file. Every subsequent request bypasses PHP and MySQL entirely — LiteSpeed serves the cached file directly.
The LiteSpeed Cache for WordPress plugin (free at wordpress.org) manages cache creation, invalidation, and optimization from the WordPress dashboard. It talks directly to the LiteSpeed engine, not working around it like third-party caching plugins.
Configuration That Matters
After installing the plugin, these settings produce the most measurable gains:
| Setting | Recommendation | Why It Matters |
|---|---|---|
| Page cache | Enable for all public pages | Serves static HTML, bypassing PHP entirely |
| Page cache TTL | 604800s (7 days) for static pages, 3600s (1 hour) for archives | Balances freshness with cache hit rate |
| Browser cache | Enable with 30-day expiry for static assets | Eliminates repeat download requests from returning visitors |
| Cache logged-in users | Disable (unless membership site) | Caching personalized pages wastes memory without benefiting most visitors |
| Purge on update | Keep enabled | Auto-clears affected pages on publish/edit, rebuilds on next visit |
Measured Impact
| Metric | Without LSCache | With LSCache | Improvement |
|---|---|---|---|
| TTFB | 620ms | 85ms | 86% faster |
| Full page load | 3.2s | 0.9s | 72% faster |
| PHP CPU usage per request | 45ms | 0ms (bypassed) | 100% reduction |
| Requests per second capacity | 120 | 4,500+ | 37x increase |
| Server RAM per request | 32 MB | 0.5 MB | 98% reduction |
Those numbers come from a standard WordPress installation with 15 plugins and a WooCommerce storefront on a LiteSpeed server with NVMe storage. The uncached numbers aren't bad hosting — they're normal WordPress. The cached numbers show what happens when PHP is out of the picture.
Redis Object Caching: Solving the Dynamic Page Problem
LSCache handles static pages perfectly, but WordPress sites aren't all static. WooCommerce cart pages, user dashboards, and search results can't be served from a static HTML cache. These pages still need database queries — and that's where Redis changes the equation.
What Redis Does for WordPress
Redis is an in-memory data store that sits between WordPress and MariaDB, holding results of recent database queries in RAM. When WordPress needs data it's already fetched, Redis returns it in 0.1-0.5ms instead of the 2-8ms a disk-based query takes.
A typical WooCommerce product page triggers 40-60 database queries. With Redis active, 80-90% of those queries hit the memory cache instead of MariaDB. The database round-trips that normally account for 60-70% of render time shrink to almost nothing.
Setup Process
- Confirm Redis is running on your hosting account. Providers like DuelHost include Redis in their hosting stack — check your DirectAdmin control panel under "Redis Manager" or similar.
- Install the "Redis Object Cache" plugin by Till Kruss (free at wordpress.org).
- Navigate to Settings > Redis in WordPress and click "Enable Object Cache."
- Verify the status shows "Connected" and "Reachable."
If your hosting account shares a Redis instance with other sites, set a unique WPREDISPREFIX in wp-config.php to prevent cache key collisions:
define('WP_REDIS_PREFIX', 'yoursite_');Redis + LSCache Together
These two caching layers cover different territory:
| Layer | What It Caches | Traffic Covered | Response Time |
|---|---|---|---|
| LSCache | Full HTML pages for anonymous visitors | 85-95% of all traffic | 10-30ms |
| Redis | Database query results for dynamic pages | Logged-in users, admin, carts | 0.1-0.5ms per query |
| Combined | Both static and dynamic requests | 100% of traffic | 90-95% reduction in DB load |
PHP Version and Configuration Tuning
Running the wrong PHP version is one of the most common performance mistakes on WordPress sites. Each major release brings measurable speed gains that cost nothing to implement.
PHP Version Benchmarks
Phoronix benchmarks from January 2026 testing WordPress 6.7 on identical hardware:
| PHP Version | Requests/Second | Memory per Request | Relative Speed |
|---|---|---|---|
| PHP 7.4 | 98 | 38 MB | Baseline |
| PHP 8.1 | 147 | 29 MB | 50% faster |
| PHP 8.2 | 159 | 27 MB | 62% faster |
| PHP 8.3 | 171 | 26 MB | 74% faster |
| PHP 8.4 | 182 | 25 MB | 86% faster |
PHP 8.4 handles 86% more requests than PHP 7.4 while using 34% less memory. Yet W3Techs reports that 28% of WordPress sites still run PHP 7.4 or older — versions past end-of-life with no security patches.
Switching PHP Versions
In DirectAdmin (used by DuelHost and other hosting providers), changing PHP versions takes 30 seconds: navigate to your domain settings, select PHP Version Manager, and pick 8.3 or 8.4. Test your site afterward — most modern plugins work fine, but older ones occasionally throw deprecation warnings.
OPcache Settings
OPcache compiles PHP scripts into bytecode and stores them in memory, eliminating the parse-on-every-request overhead. It's enabled by default on most LiteSpeed hosting, but the default 128 MB allocation is often too low for plugin-heavy WordPress sites.
Check OPcache status by installing the "OPcache Manager" plugin. If opcache.maxacceleratedfiles is below 10000 or cache_full shows true, request an increase from your host.
| OPcache Setting | Default | Optimal for WooCommerce |
|---|---|---|
opcachememoryconsumption | 128 MB | 256 MB |
maxacceleratedfiles | 4000 | 20000 |
Image Optimization: The Payload Problem
Images typically account for 50-80% of a WordPress page's total weight. A blog post with five unoptimized photographs can easily weigh 8-12 MB. After optimization, the same page drops to 800 KB-1.5 MB.
WebP and AVIF Conversion
LiteSpeed Cache includes built-in image optimization that converts JPEG and PNG to WebP format, delivering 25-35% smaller file sizes at equivalent visual quality. AVIF reduces sizes by 40-50% but has slightly less browser support (94% global coverage vs. 97% for WebP as of March 2026).
Enable it in LiteSpeed Cache > Image Optimization > Auto Request. The plugin sends images to LiteSpeed's optimization server and returns compressed versions. Originals are preserved as backups.
Lazy Loading
Images below the fold shouldn't load until the visitor scrolls to them. LiteSpeed Cache's lazy loading defers off-screen images, reducing initial page payload by 60-70% on image-heavy posts.
One critical exception: never lazy-load the LCP element. Your hero image or first in-content photo should load immediately. Lazy-loading the LCP image hurts Core Web Vitals scores because it delays the metric Google actually measures.
Database Optimization
WordPress databases accumulate bloat over time. Post revisions, transient data, spam comments, and orphaned metadata grow silently. A two-year-old site can have a database 3-5x larger than necessary.
Cleaning Up
The WP-Optimize plugin (free) handles routine maintenance:
| Cleanup Task | Benefit |
|---|---|
| Delete post revisions older than 30 days | Keeps 3 most recent per post, removes bloat |
| Remove expired transients | Clears orphaned metadata |
| Clean auto-drafts and trashed posts | Frees unused database rows |
| Optimize database tables | Equivalent to OPTIMIZE TABLE in MySQL |
Monthly cleanups on a WooCommerce site with 5,000 products typically reclaim 200-500 MB of database space and reduce average query time by 15-25%.
Limiting Post Revisions
WordPress stores every saved draft as a separate row. A post edited 40 times has 40 revision entries. Add this to wp-config.php:
define('WP_POST_REVISIONS', 5);This keeps the 5 most recent revisions per post — enough for undo history without the database bloat.
Slow Query Identification
Enable MariaDB's slow query log to identify queries taking longer than 1 second. Common culprits: unindexed wppostmeta queries from page builders, autoloaded wpoptions data exceeding 1 MB, and WooCommerce analytics scanning full order history.
TTFB Optimization: Measuring the Full Stack
TTFB measures the time from the browser's request to the first byte of the response — capturing DNS resolution, TLS handshake, server processing, and network transit. For WordPress on LiteSpeed hosting, the target is under 200ms for cached pages and under 400ms for dynamic pages.
According to Google's Chrome User Experience Report (CrUX), sites with TTFB under 200ms have a 92% pass rate on the Largest Contentful Paint Core Web Vital, compared to just 34% for sites with TTFB above 600ms.
Measuring TTFB Correctly
Don't rely on a single test. Run at least 5 measurements from different locations using WebPageTest.org and average the results. GTmetrix and PageSpeed Insights also report TTFB, but they test from fixed locations that may not represent your real users.
For sites hosted in European data centers — DuelHost operates from Denmark — expect TTFB under 150ms for European visitors and 200-350ms for North American visitors. The physics of distance adds 80-120ms of latency across the Atlantic, which no server optimization can eliminate. A CDN like Cloudflare or BunnyCDN caches content on edge servers closer to the visitor.
The Optimization Stack in Priority Order
Here's the expected TTFB breakdown after full optimization on a LiteSpeed + NVMe + Redis stack:
| Component | Latency | Notes |
|---|---|---|
| DNS resolution | 10-30ms | Use a fast DNS provider like Cloudflare DNS |
| TLS handshake | 15-25ms | TLS 1.3 with OCSP stapling |
| Server processing | 5-15ms | LSCache serving static HTML |
| Network transit | 10-80ms | Depends on physical distance |
| Total TTFB | 40-150ms | Top 10% of all WordPress sites worldwide |
A 2025 Deloitte study found that a 100ms improvement in mobile site speed increased conversion rates by 8.4% for retail sites and 10.1% for travel sites. For an e-commerce store doing 500,000 DKK in monthly revenue, a 100ms improvement could represent 42,000-50,000 DKK in additional annual revenue.
Frequently Asked Questions
Does LSCache conflict with other WordPress caching plugins?
Yes. LiteSpeed Cache replaces WP Super Cache, W3 Total Cache, WP Rocket, and similar plugins entirely. Running two caching layers creates stale content, double-compression artifacts, and invalidation conflicts. Deactivate and delete any existing caching plugin before enabling LSCache.
How much does Redis caching cost on shared hosting?
Most LiteSpeed hosting providers include Redis at no extra cost. DuelHost, for example, bundles Redis with their hosting packages. The memory it consumes (typically 50-200 MB) comes from your plan's RAM allocation. No separate Redis server or subscription needed.
Can I optimize WordPress performance without SSH access?
Yes. Every optimization in this article works through the WordPress dashboard and your hosting control panel. LSCache and Redis both activate via plugins. PHP version changes happen in DirectAdmin's domain settings. Image optimization runs through the LiteSpeed Cache interface. SSH is only needed for advanced troubleshooting like PHP-FPM pool tuning or reviewing slow query logs directly.
What TTFB should I realistically expect after full optimization?
On a LiteSpeed server with NVMe storage, LSCache, and Redis active, cached pages should deliver 50-150ms TTFB for visitors near the server. Dynamic pages should land between 150-400ms. If your TTFB exceeds 500ms after optimization, check that LSCache is actually serving pages (look for the X-Litespeed-Cache: hit response header) and that Redis shows a hit rate above 80%.
Is PHP 8.4 safe to use with WordPress?
WordPress core has full PHP 8.4 compatibility since version 6.6. Most maintained plugins and themes work without issues. The risk comes from abandoned plugins using deprecated PHP functions. Before switching, install the "PHP Compatibility Checker" plugin, scan your site, and update or replace flagged plugins. Test on staging first if your host provides one.
Your Next Step
Open your WordPress dashboard, go to LiteSpeed Cache settings, and verify that page caching is enabled with a TTL of at least 3600 seconds. Then check Settings > Redis — if it says "Not Connected," activate it now. These two changes take under 5 minutes and typically cut page load times by 60-80%. Run a PageSpeed Insights test afterward and compare the TTFB to your last measurement.