Redis cache can cut your WordPress database load by up to 80% and drop your TTFB to under 200ms. Here is how to set it up in under 5 minutes on WebHostMost – no server configuration needed.
Redis cache WordPress setup reduces database load by up to 80% and cuts Time to First Byte (TTFB) to under 200ms – without touching a single server configuration file. Redis is an open-source, in-memory data structure store that saves MySQL query results in RAM, so WordPress skips the database entirely on repeat requests. On WebHostMost, Redis is pre-installed on every hosting plan at no extra cost, and enabling it takes under 5 minutes through the LiteSpeed Cache plugin.
Every WordPress page load triggers a chain of MySQL queries. A standard blog post generates 40 to 60 database queries. A WooCommerce product page with related products, pricing rules, and stock checks generates 80 to 150 queries per load. Each query adds latency, and that latency stacks up into a slow TTFB.
Redis is an object cache – a system that stores the results of those database queries in server RAM instead of re-running them on every request. RAM access completes in under 1 millisecond. A MySQL query on a shared server takes 5 to 50 milliseconds depending on complexity and load. Multiply that by 100 queries per page and the difference becomes measurable in hundreds of milliseconds of TTFB reduction.
Here is what actually happens when Redis is active on a WordPress site:
The practical result on a busy WordPress or WooCommerce site: database CPU load drops by 60 to 80%, TTFB drops from 400 to 800ms to under 200ms, and the server handles 3 to 5 times more concurrent users before performance degrades.
One critical distinction: Redis is an object cache, not a page cache. Page cache stores the full rendered HTML output. Object cache stores the database building blocks used to generate that HTML. You need both layers running simultaneously for maximum performance – which is exactly what LiteSpeed Cache provides when Redis is enabled alongside its built-in page caching engine.
Redis object caching delivers the largest gains on dynamic sites – WooCommerce stores, membership platforms, and sites with many logged-in users who cannot be served cached HTML pages.
Understanding how Redis cache for WordPress compares to other caching approaches helps you make the right configuration decision. The table below uses real benchmark data from WordPress 6.5 running WooCommerce 8.9 on equivalent hardware.
| Caching Method | Avg TTFB | DB Queries per Page | Concurrent Users (stable) | Logged-in User Benefit | Setup Complexity |
|---|---|---|---|---|---|
| No cache | 600 – 900ms | 80 – 150 | ~15 | None | None |
| WP Super Cache (page only) | 150 – 300ms | 80 – 150 (uncached users) | ~80 | Minimal – logged-in users bypass page cache | Low |
| LiteSpeed Cache (page only) | 80 – 180ms | 80 – 150 (uncached users) | ~200 | Minimal – logged-in users bypass page cache | Low |
| Redis object cache only | 200 – 350ms | 8 – 25 (after warmup) | ~120 | High – every authenticated request benefits | Low – Medium |
| LiteSpeed Cache + Redis (recommended) | 50 – 180ms | 8 – 25 (after warmup) | 300+ | Very high – both layers active | Low (one-click on WebHostMost) |
The combined LiteSpeed Cache plus Redis object cache configuration is the only setup that delivers sub-200ms TTFB for both anonymous visitors and logged-in users simultaneously. WP Super Cache with no object cache still hits MySQL 80 to 150 times per page load for any user who is not served a cached HTML file – which includes every WooCommerce customer with items in their cart.
Running LiteSpeed Cache alongside Redis cache on WebHostMost gives you the full performance stack with a one-click setup – no separate services, no extra billing, no command line required.
This setup requires three things and nothing else:
You do not need SSH access, cPanel expertise, PHP configuration files, a Redis password, or a developer. WebHostMost pre-configures the Redis connection details – host address, socket path, and authentication – at the server level. LiteSpeed Cache detects them automatically during setup.
If you are currently running WP Rocket, W3 Total Cache, or any other caching plugin, deactivate and delete it before proceeding. Running two caching systems simultaneously causes cache conflicts, stale content, and slower performance – the opposite of the goal.
These steps take 3 to 5 minutes from start to finish.
Go to WordPress dashboard – Plugins – Add New Plugin. Search for “LiteSpeed Cache”. Click Install Now, then Activate. If LiteSpeed Cache is already active on your site, skip to Step 2.
In your WordPress admin sidebar, click LiteSpeed Cache. The main dashboard shows cache statistics, hit counts, and quick action buttons. You are looking for the Cache menu item in the sub-navigation.
Click LiteSpeed Cache – Cache, then click the Object tab at the top of the settings panel. Find the Object Cache toggle and switch it ON. This activates the object caching layer in LiteSpeed Cache.
In the same Object tab, find the Method dropdown. Select Redis from the list. On WebHostMost, the connection fields – Host, Port, and Authentication – are pre-filled automatically. You do not need to enter a Redis server address or password. The plugin handles the connection using server-level configuration.
Click Save Changes. LiteSpeed Cache immediately tests the Redis connection. If successful, you will see a green status indicator or the text “Redis connected” in the Object Cache section. The one-click Redis cache WordPress setup is complete.
Redis cache on WebHostMost activates instantly – no server restart, no propagation delay, no ticket to support.
Do not rely solely on the LiteSpeed Cache status indicator. Use these three verification methods to confirm Redis is actively serving cached data:
Redis cache requires a warmup period. The first page visit after activation runs all MySQL queries normally – this populates the cache. Subsequent visits pull results from RAM. Do not benchmark Redis performance from a single cold page load immediately after activation. Allow 10 to 15 minutes of normal traffic before measuring results.
A cache hit ratio above 80% after warmup is the signal that Redis cache for WordPress is functioning at full capacity.
Redis is easy to enable and easy to misconfigure. These are the five mistakes that cause problems most frequently:
Avoiding these five mistakes means Redis cache for WordPress runs at full effectiveness from day one.
Redis cache for WordPress delivers different levels of improvement depending on site type. Here is a breakdown by use case with realistic performance expectations:
| Site Type | Expected TTFB Improvement | DB Query Reduction | Primary Benefit |
|---|---|---|---|
| Standard blog (low traffic) | 20 – 35% | 30 – 50% | Slightly faster admin, marginal front-end gain |
| High-traffic blog (1,000+ daily visits) | 40 – 60% | 60 – 75% | Significant server load reduction, stable TTFB under spikes |
| WooCommerce store | 50 – 70% | 65 – 80% | Faster product pages, category pages, checkout flow |
| Membership / LMS site | 55 – 75% | 70 – 85% | Logged-in users get full cache benefit – biggest use case for Redis |
| Multisite network | 45 – 65% | 60 – 75% | Shared cache across sites reduces cumulative DB load |
Membership sites and WooCommerce stores are the highest-value targets for Redis cache WordPress deployment. Logged-in users cannot receive cached HTML pages, so every page load hits PHP and MySQL without Redis. With Redis active, session data, user meta, access rules, and pricing information are served from RAM – every authenticated request becomes dramatically faster.
High-traffic spikes are where Redis proves its value under pressure. When 500 users hit your site simultaneously, Redis serves 80% of database queries from RAM. Without Redis, 500 simultaneous MySQL queries queue up, response times spike, and the server may become temporarily unavailable. With Redis, MySQL only handles novel queries – the cache absorbs the rest.
Redis cache for WordPress is one layer in a three-layer performance stack. Each layer handles different aspects of site speed:
| Cache Layer | What It Caches | Best For | Included on WebHostMost |
|---|---|---|---|
| Page cache (LiteSpeed) | Full rendered HTML pages | Anonymous visitors, static content | Yes – all plans |
| Object cache (Redis) | DB query results, transients, user meta, computed values | Dynamic content, logged-in users, WooCommerce | Yes – all plans, one-click setup |
| Browser cache | Static files (images, CSS, JavaScript) in visitor’s browser | Returning visitors, static asset delivery | Yes – configured via LiteSpeed Cache |
| CDN cache (Cloudflare) | Static and dynamic assets across 300+ global edge nodes | International audiences, high-traffic sites | Yes – Cloudflare integration included |
On WebHostMost, the complete performance stack – LiteSpeed Web Server (which benchmarks at 6 times the PHP throughput of Apache 2.4), Redis object cache, NVMe SSD storage, and Cloudflare CDN – is included from the entry-level shared hosting plan. Most managed WordPress hosts charge $30 to $100 per month for equivalent infrastructure. WebHostMost includes it all with a one-click Redis cache WordPress activation through LiteSpeed Cache.
Combining all four caching layers is the standard configuration for production WordPress and WooCommerce sites that need consistent sub-200ms TTFB under real traffic loads.
Redis cache in WordPress is a persistent object caching system that stores MySQL database query results in server RAM. WordPress normally runs 40 to 150 database queries per page load – Redis intercepts those queries after the first execution and serves subsequent requests from memory in under 1 millisecond. Redis is an open-source, in-memory data structure store, originally released in 2009 and maintained by the Redis community, that operates as a key-value store supporting strings, hashes, lists, and sets.
Redis cache for WordPress reduces TTFB by 40 to 75% on dynamic sites depending on content complexity and traffic volume. A WooCommerce store running 100 database queries per page load typically drops to 8 to 25 queries after Redis warms up, reducing TTFB from 600 to 900ms to 80 to 200ms. The improvement is largest on membership sites and WooCommerce stores because logged-in users cannot be served cached HTML pages – Redis is the only caching layer that benefits every single request regardless of login state.
Yes. Redis is pre-installed and included at no additional cost on all WebHostMost hosting plans. There is no add-on to purchase, no separate Redis subscription, and no per-request billing. Enabling Redis cache for WordPress requires one change in the LiteSpeed Cache plugin settings – select Redis as the object cache method, save, and the connection is live. WebHostMost pre-configures all connection parameters at the server level so no manual configuration is required.
Most caching plugins – including WP Super Cache and basic WP Rocket configurations – handle only page cache, which stores full HTML output for anonymous visitors. They do not implement object cache. Redis cache handles a completely different layer: it stores database query results and computed values, benefiting both anonymous users and logged-in users. If you are using LiteSpeed Cache, enabling Redis adds the object caching layer on top of the existing page cache. If you are using a different caching plugin, switch to LiteSpeed Cache first to avoid plugin conflicts – two caching systems running simultaneously will conflict and degrade performance.
Yes – WooCommerce is one of the highest-value use cases for Redis cache in WordPress. WooCommerce product pages generate 80 to 150 database queries covering product meta, variation data, stock levels, pricing rules, and related product lookups. Redis caches these query results in RAM and serves them in under 1 millisecond on subsequent requests. Cart, checkout, and account pages must be excluded from object caching because they contain user-specific transactional data – LiteSpeed Cache automatically excludes these pages when WooCommerce is detected, but verify the exclusion list under LiteSpeed Cache – Excludes before going live.
Three verification methods confirm Redis cache is active and performing correctly. First, check the LiteSpeed Cache dashboard – the Object Cache section must show “Connected” status and a non-zero cache hit count after 10 minutes of traffic. Second, install the free Query Monitor plugin and compare database query counts on the same page before and after Redis activation – a successful Redis configuration reduces query counts from 80 to 150 down to 8 to 25. Third, run a GTmetrix speed test before and after activation – TTFB should drop by 40 to 75% on a properly configured setup. A cache hit ratio above 80% after warmup is the definitive signal that Redis cache for WordPress is operating at full capacity.
Redis and Memcached are both in-memory key-value stores used for WordPress object caching, but Redis offers three important advantages. First, Redis supports persistent storage – cache survives server restarts, while Memcached loses all data on restart. Second, Redis supports complex data structures including lists, hashes, and sets, which makes it more efficient for caching WordPress transients and complex query results. Third, Redis supports clustering and replication for high-availability deployments. Memcached is simpler and slightly faster for basic string storage, but Redis is the recommended choice for WordPress and WooCommerce due to its persistence and richer data model. WebHostMost provides Redis on all plans – Memcached is not offered as an alternative.
Redis cache can cause three categories of issues if misconfigured. First, stale cache: if Redis serves outdated query results after a plugin or theme update, users see old content – fix this by clicking “Purge All” in the LiteSpeed Cache admin bar after any significant site change. Second, WooCommerce cart issues: if cart or checkout pages are accidentally included in the object cache, users may see each other’s cart data – LiteSpeed Cache prevents this automatically but verify the exclusion list. Third, plugin conflicts: running Redis alongside W3 Total Cache or WP Rocket causes both plugins to try to write an object-cache.php drop-in file, creating unpredictable behavior – run only one caching system at a time. On WebHostMost with LiteSpeed Cache and the one-click Redis setup, none of these issues occur under default configuration.
Redis cache TTL (Time to Live) in WordPress is controlled by the application, not Redis itself. LiteSpeed Cache sets a default object cache TTL of 1800 seconds (30 minutes) for most WordPress data. Transients stored in Redis use the expiration time set by the plugin that created them – some expire in minutes, others in hours. When WordPress updates a post, changes a setting, or a plugin modifies database data, LiteSpeed Cache automatically invalidates the relevant cache keys immediately rather than waiting for TTL expiration. You can adjust the default TTL under LiteSpeed Cache – Cache – Object – Object Cache Expiry, but the 1800-second default is appropriate for most WordPress and WooCommerce configurations.
Redis cache WordPress setup on WebHostMost takes under 5 minutes and requires zero server configuration – Redis is pre-installed on every plan at no extra cost, with connection details pre-configured at the server level.
Looking for the best hosting for your WordPress site? See our guide to best WordPress hosting for 2026, explore performance comparisons in our best managed web hosting 2026 roundup, or read how LiteSpeed Cache improves WordPress performance at every level of the stack.
Redis is an open-source, in-memory data structure store maintained by the Redis community. Learn the full technical specification at redis.io official documentation. For WordPress-specific object cache implementation details, see the WordPress Developer Reference: WP_Object_Cache.
WebHostMost includes Redis object cache on every hosting plan – already configured, no setup required. You get all the performance benefits from this guide without touching a command line or managing a cache server yourself.
For more hosting options, check our managed WordPress hosting guide. Start with a 14-day free trial – no credit card required. If your site doesn’t load faster, cancel anytime within 45 days for a full refund.
