Configure Redis Object Cache in WordPress on Hostinger

Database queries were choking my WooCommerce checkout on Hostinger, pushing response times past 1,400ms whenever logged-in shoppers hit the cart. Full-page caching is great for anonymous traffic reading blog posts, but it completely bails out the second a session cookie gets set or someone interacts with dynamic endpoints.

Once a user authenticates, WordPress bypasses page cache and hits MySQL for everything: autoloaded options, post metadata, user transients, and term relationships. If five people check out simultaneously, database CPU usage spikes to 100%. Moving those repetitive lookups into RAM with an in-memory key-value store dropped my response times down to double digits. Here is how to wire it up properly on Hostinger without wrecking your staging environment.

Why Page Caching Fails Dynamic Requests

Page caching writes pre-rendered HTML files to disk or keeps them in Nginx/LiteSpeed cache. When a visitor sends a session cookie, WordPress has to bypass that static file because shopping carts, account dashboards, and inventory counts are unique to each person.

Every single uncached page load fires anywhere from 40 to 180 SQL queries against tables like wp_options, wp_posts, and wp_postmeta. The database engine has to parse the query, read rows from the InnoDB buffer pool or disk, and return records to PHP on every hit.

The WordPress Object Cache API helps curb this by storing query results in memory during a request. But out of the box, that cache is non-persistent—the moment PHP finishes running the script, the cached objects evaporate. Redis gives WordPress a persistent memory backend, meaning expensive database lookups survive across requests and across different visitor sessions.

Prerequisites and Hostinger Plan Requirements

Before editing any configuration files, verify that your Hostinger plan actually includes Redis. It is available on Business Web Hosting, Cloud Startup, Cloud Professional, and VPS packages. Single and Premium shared hosting accounts do not have access to the Redis daemon.

You also need SSH enabled. Do not try to debug cache drops strictly through the admin dashboard—you will want terminal access to inspect sockets and run WP-CLI commands. You can enable SSH inside hPanel under Advanced > SSH Access. If you recently migrated from another host, make sure your tables are clean first; check my guide on how to migrate a large WordPress site to Hostinger using SSH and WP-CLI before layering an object cache over messy data.

Step 1: Enable Redis in hPanel and Activate the PHP Extension

Hostinger requires two toggles: the server-level daemon itself, and the PHP module that talks to it.

1. Log in to your Hostinger hPanel.
2. Select your site and go to WordPress > Security & Performance (or Advanced > Cache Manager on older panel versions).
3. Turn the Redis toggle to Enabled.

Now make sure the compiled PhpRedis extension is active in your PHP environment. If this module is missing, WordPress will either throw a fatal error or fall back to Predis, a pure-PHP socket implementation that is noticeably slower.

1. In hPanel, head to Advanced > PHP Configuration.
2. Select the PHP Extensions tab.
3. Scroll down to redis, tick the checkbox, and hit Save.

I never trust dashboard checkboxes completely. SSH into your server and confirm the extension is actually loaded in your CLI and web runtime:

php -m | grep -i redis

If that command outputs redis, the C-based extension is active and ready to communicate with the local service.

Step 2: Test Redis Socket and Port Connectivity

Hostinger usually binds Redis locally to 127.0.0.1:6379, though some infrastructure builds map to a Unix socket. Before touching WordPress, send a raw ping to confirm the daemon is responding.

Run this quick PHP snippet from your site root:

php -r "$r = new Redis(); $r->connect('127.0.0.1', 6379); echo $r->ping() ? 'Redis Connected: PONGn' : 'Failedn';"

If you see Redis Connected: PONG, your network path is clear. If you get a connection refused or timeout error, your Redis daemon has not fully initialized or is bound elsewhere. Double-check the host and port listed directly beside the Redis toggle in hPanel before moving forward.

Step 3: Install and Configure the Redis Object Cache Plugin

You can run object caching via LiteSpeed Cache, but using a dedicated drop-in keeps the stack lighter and avoids coupling object caching with asset minification. Till Krüss’s Redis Object Cache is rock-solid and the community standard.

Hop into your public_html directory and install it via WP-CLI:

wp plugin install redis-cache --activate

Stop right here. Do not hit “Enable Object Cache” in the WP admin yet. If you enable it before setting your keys and salts, you risk cache cross-talk or fatal timeouts if anything hangs.

Step 4: Hardcode Redis Constants in wp-config.php

Open wp-config.php using SSH (nano or vim) or the hPanel File Manager. Place your constants above the line that says /* That's all, stop editing! Happy publishing. */.

Add these configuration directives:

// Redis Object Cache Settings
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_TIMEOUT', 1.0);
define('WP_REDIS_READ_TIMEOUT', 1.0);
define('WP_REDIS_PREFIX', 'prod_site_');
define('WP_CACHE_KEY_SALT', 'c4b8e21a_');
define('WP_REDIS_MAXTTL', 86400);

Here is why these matter:

• WP_REDIS_TIMEOUT & WP_REDIS_READ_TIMEOUT: Limits socket connections to 1 second. If the Redis server ever hangs or runs out of memory, PHP won’t wait 60 seconds and cause your web server to spit 504 Gateway Timeouts at users.
• WP_REDIS_PREFIX & WP_CACHE_KEY_SALT: Isolates your cache keys. If you ever spin up a staging site or host a second domain on the same account, these salts guarantee Site A never reads or overwrites transients from Site B.
• WP_REDIS_MAXTTL: Sets a hard 24-hour expiration on keys, preventing abandoned transients from lingering in RAM forever.

While editing wp-config.php, make sure your PHP memory ceiling is set high enough to handle large object payloads. Read my guide on how to increase the PHP memory limit in WordPress on Hostinger if you run bloated plugins that generate heavy cache payloads.

Step 5: Activate the Object Cache Drop-in

With the environment variables locked in, drop the cache engine in place. This copies the plugin’s driver into wp-content/object-cache.php, which WordPress bootstraps before loading any active plugins or themes.

Activate the drop-in with WP-CLI:

wp redis enable

You should get this confirmation in your terminal:

Success: Object cache enabled.
Status: Connected
Client: PhpRedis (v5.3.7)
Drop-in: Valid

If you prefer the GUI, go to Settings > Redis in your WordPress dashboard and click Enable Object Cache. The status box should switch to a green Connected badge immediately.

Step 6: Handle Staging Environments and Multi-Tenancy

Here is where people usually shoot themselves in the foot. When you use hPanel’s one-click staging tool, Hostinger clones your files and database into a staging folder. By default, that cloned site retains the same Redis configuration on 127.0.0.1:6379.

If staging and production share the same Redis database and prefix, changing an order status or editing a draft on staging will instantly pollute or overwrite production cache keys. I once watched an entire client store display stale cart items because a staging sync wiped active production sessions.

Open the wp-config.php file inside your staging directory and change both the database index and key prefixes:

// Staging Redis Settings - Isolated
define('WP_REDIS_DATABASE', 2);
define('WP_REDIS_PREFIX', 'staging_site_');
define('WP_CACHE_KEY_SALT', 'stg_881f3c_');

Redis supports 16 logical databases by default (indexed 0 through 15). By moving staging to WP_REDIS_DATABASE = 2, executing wp redis flush on staging will never nuke the live production keys sitting in database 0.

Step 7: Verify Cache Hit Ratio and Eviction Policies

An object cache only helps if it actually serves data rather than constantly missing. Inspect your live hit metrics using WP-CLI:

wp redis info

Look for lines formatted like this in the terminal:

# Stats
keyspace_hits: 14280
keyspace_misses: 914
hit_ratio: 93.98%
used_memory_human: 18.42M
maxmemory_policy: volatile-lru

On a healthy site, the hit ratio should settle between 85% and 95% after a few minutes of real traffic. If yours hovers under 50%, audit your plugins. Poorly coded plugins often randomize their cache keys on every page load, generating infinite cache misses and chewing through memory.

To watch keys hit the server in real time, run this via SSH:

redis-cli monitor | grep "prod_site_"

Browse a few uncached pages in another tab. You should see a stream of GET, SET, and EXISTS calls flash across your console. Hit Ctrl + C once you verify it works—leaving the monitor command running adds noticeable CPU overhead.

Handling Hostinger Cron and Cache Purging

WordPress relies on wp-cron.php to clear expired transients and run routine maintenance. When Redis is active, transient records move out of the wp_options table and into RAM. If your cron only fires when someone visits the site, transients can sit in memory past their expiration, causing memory bloat.

To keep Redis tidy, take cron off visitor hits completely. Check out my guide to disable WP-Cron and set up a real cron job in Hostinger hPanel. Running system cron every 10 to 15 minutes ensures object cache garbage collection runs like clockwork.

If you route static files through a CDN, verify your static asset headers are working properly too. See my write-up on how to speed up WordPress with browser cache headers and StackPath CDN so uncached CSS and JS don’t undo your backend speed gains.

Troubleshooting Common Redis Errors

Error: No route to host or Connection Refused

If the drop-in reports that it cannot reach 127.0.0.1:6379, check your hPanel Redis toggle first. On Hostinger’s shared platforms, idle Redis instances sometimes spin down if a site sees prolonged silence. Toggle Redis off, wait 30 seconds, toggle it back on, and reload the status page.

Error: Class ‘Redis’ not found

This means your web server or CLI environment executed object-cache.php without the phpredis extension loaded. If you run multiple subdomains under different PHP versions, verify that the exact PHP version assigned to that site has the redis extension enabled in hPanel.

High Memory Usage and Evictions

Hostinger allocates a fixed slice of RAM to Redis (often 128MB to 256MB depending on your plan). If you have an enormous product catalog, your keys might hit that ceiling. Prevent volatile or bloated transient groups from filling the store by telling the drop-in to skip them in wp-config.php:

// Exclude non-critical transient groups from Redis
$wp_redis_ignored_groups = [ 'counts', 'plugins', 'themes', 'transient',
];
define('WP_REDIS_IGNORED_GROUPS', $wp_redis_ignored_groups);

Frequently Asked Questions

Does Redis replace the LiteSpeed Cache plugin on Hostinger?

No. LiteSpeed Cache handles HTML page caching, asset optimization, and browser cache headers. Redis handles backend database query caching. You can actually use LiteSpeed Cache as your Redis client: head to LiteSpeed Cache > Settings > Object, select Redis, set the host to 127.0.0.1 on port 6379, and turn it on.

Will enabling Redis break my WooCommerce cart updates?

Not if you use a well-maintained drop-in. The Redis Object Cache plugin automatically skips WooCommerce session tokens and cart hashes so carts remain dynamic. If you ever see cart contents persisting across different user sessions, update the plugin drop-in immediately.

How do I flush the Redis cache manually if my site breaks?

If a broken plugin update or corrupted transient causes a fatal error, flush the cache over SSH:

wp redis flush

If SSH is not an option, open the hPanel File Manager and delete wp-content/object-cache.php. WordPress will immediately drop back to its default, non-persistent memory cache without breaking your site.

Is Redis included on Hostinger Premium Shared plans?

No. Hostinger reserves native Redis instances for Business Web Hosting, Cloud hosting, and VPS plans. The Redis toggle simply won’t show up in hPanel on Single or Premium shared plans.

Next Steps

Now that your dynamic queries are served straight from memory, you’ll see a massive difference in checkout and admin dashboard speeds. The next bottleneck you’ll likely hit on Hostinger is background task execution. Check out my guide on disabling WP-Cron and setting up a real system cron in hPanel to stop background jobs from slowing down real visitor requests.