Redis cache for PrestaShop: setup and performance gains

Most PrestaShop performance advice stops at "use Redis" and leaves you staring at a back-office dropdown wondering what to type in the four boxes underneath it. This guide is the other half: the actual setup. Where Redis plugs into PrestaShop, what each field in Advanced Parameters → Performance expects, how to point your sessions at Redis (which the back office can't do for you), how to confirm it's genuinely caching instead of silently falling back to files, and how to read the numbers afterward so you know whether it helped. If you're still deciding whether Redis is worth it for your store, start with the case for it in Redis for PrestaShop: the speed upgrade your store probably needs, this post assumes you've decided and want it running correctly.

Reviewed June 2026 for PrestaShop 1.7.8, 8.x and 9.x. We use Redis on mypresta.rocks ourselves. The trade-offs below reflect that experience; Redis alone does not determine a PageSpeed score, so compare the whole storefront before and after a change under the same test conditions.

What Redis caches in PrestaShop, and what it doesn't

The single biggest source of disappointment with Redis on PrestaShop is expecting it to do something it doesn't. First, a caveat that shapes everything below: native PrestaShop 1.7/8 does not expose Redis as a built-in object-cache backend on the Performance page. The stock caching system choices are filesystem and Memcached-style backends (APC/APCu, XCache and Memcache/Memcached, depending on your PHP version and loaded extensions). Redis becomes an option here only when a module or custom cache backend adds it. Once it's available, that setting governs exactly one thing: PrestaShop's internal object cache. That's the Cache class layer which stores things PrestaShop would otherwise rebuild on every request: serialized configuration, the category tree, results of repeated ObjectModel lookups, module hook registrations, and similar internal data structures. On a request-heavy page these reads happen dozens of times, and moving them from disk to RAM is where the gain comes from.

It does not turn on full-page caching, and it does not move your customer sessions to Redis. Those are two separate jobs:

• Full-page cache is a different mechanism entirely, it stores whole rendered HTML pages so PHP barely runs. PrestaShop has no native full-page cache; you add it with a module or a reverse proxy. That's its own topic, covered in PrestaShop cache: full-page cache modules explained. Redis can be the storage backend some of those FPC modules write to, but selecting a Redis object-cache backend on the Performance page does not give you full-page caching.
• Session storage in Redis is configured in PHP, not in PrestaShop's back office (covered below). The Performance-page Redis setting leaves sessions exactly where they were, on the filesystem.

So what? Knowing this up front saves you the most common Redis mistake: flipping the back-office toggle, seeing a modest improvement, and concluding "Redis doesn't do much." You enabled one of three possible jobs. Decide deliberately which ones you want, because each is configured in a different place.

Prerequisites: the server side, briefly

This is a PrestaShop setup guide, not a Redis sysadmin course, so the server steps are deliberately short, and on managed PrestaShop hosting they're often already done for you. You need two things present before PrestaShop can use Redis:

• The Redis server itself, reachable from the web server (typically on 127.0.0.1:6379 when it runs on the same machine). Confirm with redis-cli ping, a healthy install answers PONG.
• The PHP redis extension, loaded into the same PHP that runs your store. This is the step people miss: a CLI php -m | grep redis can show the extension while your PHP-FPM pool doesn't have it, because they load different php.ini files. Check the one that matters by looking at your store's own Advanced Parameters → Information page (which reports the live PHP config) or a temporary phpinfo(), if there's no Redis section there, a Redis cache backend will not work no matter what the CLI says, and remember the backend itself has to be added by a module before it even shows up.

If your host doesn't provide Redis at all and won't, that's genuinely a hosting decision, not a caching decision, covered honestly in choosing hosting for PrestaShop: what matters and what is marketing. Caching cannot rescue a host that won't give you the tools.

Step 1, Enable the object cache from the back office

In your store, open Advanced Parameters → Performance and find the Caching section, its exact position on the page varies by version. Then:

• Set Use cache to Yes.
• In Caching system, choose the Redis backend. Remember it only appears here if a module or custom cache backend has added it (and the PHP redis extension is loaded), stock PrestaShop lists filesystem and Memcached-style options only. If there's no Redis choice, install/enable the module that provides it and confirm the redis extension is loaded; see Prerequisites.
• Fill in the connection fields that appear:
  • Server (IP/hostname): 127.0.0.1 for same-machine Redis, or the container/service hostname (e.g. redis) in a Docker or orchestrated setup.
  • Port: 6379 unless you deliberately changed it.
  • Database: 0 for a single store. If several PrestaShop installs share one Redis server, give each a different database number so they don't read each other's keys, Redis offers databases 0, 15 by default.
• Click Add server, then Save.

The native server list here is a Memcached-style multi-server configuration; some Redis adapters/modules let you add several cache servers, but multi-server Redis redundancy isn't a guaranteed PrestaShop feature, verify your Redis module actually supports it before relying on it. For one store on one box, a single entry is the norm anyway. After saving, the object cache is live immediately, there's no separate "warm up" step; the cache fills as pages are visited.

Step 2, Verify it's actually using Redis (don't assume)

The Redis configuration screen holds the connection fields: host, port, password, database index and key prefix.

A saved setting is not proof. PrestaShop can accept a Redis configuration and still serve pages while the cache stays empty. For example if the connection silently fails under load. Confirm it's working before you trust it:

• Browse a few front-office pages (home, a category, a product) to generate cache writes.
• On the server run redis-cli and then DBSIZE against the database number you chose. Treat this as a quick sanity check, not proof: on a working store the count should move off 0 and grow as you browse, but the exact figure isn't a reliable signal, cache prefixes, the selected database, TTL and flush behaviour, the adapter's implementation, and simply having a small catalog all make raw DBSIZE misleading.
• For real confirmation use redis-cli INFO (watch keyspace_hits/keyspace_misses climbing) and redis-cli MONITOR for a few seconds while you reload a page (then Ctrl-C. Never leave MONITOR running on a busy store, it's a performance drain itself). You should see a stream of GET and SET commands carrying your cache backend's key prefixes; checking for those adapter-specific prefixes confirms it's really your store talking to this instance. Silence means PrestaShop isn't talking to this Redis instance.

So what? This thirty-second check is the difference between "I enabled Redis" and "Redis is caching my store." Plenty of stores run for months with a configured-but-dead cache because nobody verified the key count ever moved off zero.

The shell version of that verification is short enough to keep in your deployment notes:

redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h 127.0.0.1 -p 6379 DBSIZE
redis-cli -h 127.0.0.1 -p 6379 INFO stats | egrep 'keyspace_hits|keyspace_misses'

Step 3, Move sessions to Redis (optional, PHP-level)

For PHP sessions, this belongs in PHP configuration, not in a PrestaShop back-office field. A typical Redis session handler looks like this:

session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?database=1&prefix=pssess:"

Session storage is a separate decision and a separate file. By default PrestaShop writes one session file per visitor to disk; under real concurrency that filesystem churn becomes a bottleneck on exactly the hosting where you most need help. Moving sessions to Redis is configured in PHP, in your php.ini or, better, the PHP-FPM pool for this site:

session.save_handler = redis

session.save_path = "tcp://127.0.0.1:6379?database=1"

Note the deliberately different database number (1) from the object cache (0). Keeping them apart means you can flush the object cache, something you'll do routinely after template or module changes, without logging out every customer who's mid-checkout. Mixing them into one database turns a harmless cache clear into a wave of dropped baskets. Restart PHP-FPM after the change, then confirm with redis-cli -n 1 DBSIZE climbing as visitors arrive.

One durability note specific to sessions: Redis is in-memory, so a Redis restart can drop sessions saved since its last disk snapshot, logging active customers out. If you store sessions in Redis on a production store, enable AOF (append-only-file) persistence so a restart loses seconds of session data rather than minutes. RDB snapshots alone are fine for a disposable object cache but too coarse for live carts.

Step 4. Set a memory ceiling and eviction policy

An object cache that's allowed to grow without limit will eventually consume the RAM your PHP workers and database need, and the cure (a slow, swapping server) is worse than the disease. Give Redis a budget in its config (redis.conf):

• maxmemory, a hard ceiling. The right figure depends on catalog size and traffic; many single-store setups sit comfortably in the low hundreds of MB for object cache, more if you also hold sessions. Watch real usage (next section) rather than guessing high.
• maxmemory-policy allkeys-lru, when the ceiling is hit, evict the least-recently-used keys. For a pure cache this is the safe default: stale, rarely-touched entries get dropped first and PrestaShop simply rebuilds them on the next request. (If the same Redis instance also holds sessions, prefer a volatile-lru policy with TTLs so eviction can't silently discard a logged-in session, or, cleaner, keep sessions on a separate Redis instance.)

Step 5, Measure the gain honestly

The reason to do all this is speed, so measure speed, but measure it correctly, because Redis improves server response time, not the parts of a page that depend on images and front-end assets. The metric that moves is Time To First Byte (TTFB): how long the server takes to start sending the page. Object caching cuts the repeated disk reads that inflate TTFB, so that's where you'll see it.

• Before you change anything, record a baseline. Hit a representative product and category page several times (so you're measuring a warm cache, not a cold one) and note server response time, browser DevTools' Network tab shows TTFB per request, and tools like PageSpeed Insights or WebPageTest report it too. For an apples-to-apples server number, a logged-out request with browser cache disabled is cleanest.
• Enable Redis, verify it (Step 2), warm the cache by browsing, then re-measure the same pages the same way.
• Compare TTFB, not the full "page load" headline. A 5 MB unoptimized hero image will dominate full-load time and mask a real backend improvement, leading you to wrongly conclude Redis "did nothing."

How much faster? Honestly, it depends entirely on your starting point. A store on slow shared hosting with heavy disk I/O can see a large TTFB reduction because that's exactly the bottleneck Redis removes; a store already on a fast NVMe VPS with light load may see a modest one, because disk reads weren't hurting it much to begin with. Anyone quoting you a single universal percentage is guessing. The only number that matters is the one you measure on your own store, before and after, on the same pages. For a structured way to diagnose where your time actually goes first, see is your store slow? how to check and what to do about it.

Monitoring Redis once it's live

After setup, a handful of values from redis-cli INFO tell you whether the cache is healthy or quietly failing:

Troubleshooting the setup problems you'll actually hit

The Redis backend isn't in the dropdown

Two causes: either the module/custom backend that adds Redis as a caching system isn't installed (stock PrestaShop won't list it), or the PHP redis extension isn't loaded into your store's PHP runtime. Confirm the providing module is active, re-check the extension via the store's own Information page or phpinfo() (not the CLI), and confirm you restarted PHP-FPM after installing the extension.

Cache configured, but DBSIZE stays at 0

PrestaShop can't reach Redis. Usual suspects: Redis bound only to 127.0.0.1 while PrestaShop connects from another host/container (common in Docker, point the Server field at the service name, not localhost); a firewall blocking port 6379; or Redis simply not running.

Stale data after editing a product or category

If edits don't show until you clear cache, the object cache isn't being invalidated as expected. Clearing the PrestaShop cache from Advanced Parameters → Performance (the Clear cache button) is the clean fix; redis-cli -n 0 FLUSHDB wipes just the object-cache database without touching sessions in database 1. If it recurs, a misbehaving module that doesn't clear its own cache on save is the likely culprit.

Customers logged out after a deploy or restart

Sessions in Redis without AOF persistence, or sessions sharing a database with the object cache and getting flushed. Separate the databases (Step 3) and enable AOF.

Redis is one layer. Get the order right

Redis pays off most when the layers underneath it are already sound, and it can't compensate for a problem it doesn't address. Before or alongside Redis:

• OPcache caches compiled PHP bytecode so the engine stops re-parsing your files every request. It's near-free and complementary, OPcache speeds up the code, Redis speeds up the data. Run both.
• A bloated or unindexed database still produces slow first-request queries that Redis only masks until the cache expires. The underlying fixes, query tuning and cleanup, are covered in performance tuning your PrestaShop store and database cleanup: why your store gets slower over time.
• The real root causes of a slow store, too many modules, heavy hooks, weak hosting, are diagnosed in what actually makes PrestaShop slow. Cache the result of a bad query and the first uncached request is still slow; fix the query and the cache makes a fast thing instant.

For a worked example of all these layers stacked together on a real, heavily-extended store, see how it reads on a scorecard in PageSpeed 99/100 on a real PrestaShop store with 130 modules.

Setup questions that come up after the dropdown

Do I need to keep CacheFs files after switching to Redis? No. Once the object cache backend is Redis and you've verified it (Step 2), the old filesystem cache under var/cache/ is just stale data. Clearing it from Advanced Parameters → Performance is harmless and tidy. Don't delete var/cache/ by hand on a PrestaShop 9 store, though: the admin Symfony container lives there and a raw wipe can 500 the back office. Use the back-office Clear cache button.

Should the object cache and sessions share one Redis instance? They can, but keep them in different databases, object cache in 0, sessions in 1 (Step 3). That separation is what lets you flush the object cache after a template or module change without logging out every customer mid-checkout. If you can run a second instance, sessions on their own Redis with AOF persistence is cleaner still, because sessions want durability that a disposable cache doesn't.

Is it safe to run FLUSHALL to clear the cache? No, FLUSHALL wipes every database on the instance, including sessions and any other shop sharing it, dropping live carts. Clear the object cache from the back office, or use redis-cli -n 0 FLUSHDB to wipe only the object-cache database while leaving sessions in database 1 untouched. Never reach for FLUSHALL on a production instance.

Why did my hit rate drop after I went live? Usually one of three things: maxmemory set too low so Redis is evicting keys (watch evicted_keys. It should be near zero for a pure cache), a too-aggressive flush schedule regenerating the cache constantly, or a misbehaving module clearing cache on every save. Raise maxmemory first, then audit what's flushing. A healthy warm cache sits comfortably above 90% hits.

Does Redis replace OPcache? No. They cache different things and you run both. OPcache caches compiled PHP bytecode so the engine stops re-parsing your files every request; Redis caches the data PrestaShop rebuilds. On PHP 8 the JIT is part of OPcache and is the larger free server-side win. Turn OPcache on regardless of whether you adopt Redis.

If you'd rather not touch the server

Everything above is doable from a back office and a shell, but it assumes you can edit a PHP-FPM pool, set a maxmemory policy, and read redis-cli INFO, comfortable territory for an agency, less so for a store owner who just wants the speed without the sysadmin. That's the gap our mprinstantredis module is built to close: it wires PrestaShop's object cache to Redis, keeps the session and cache databases separated so a cache clear never drops live carts, and surfaces the hit-rate and memory figures inside the back office instead of a terminal. So what does that buy you? The same correctly-separated, monitored setup described here, configured from the admin rather than from server config files, useful when you want the result without owning the server plumbing. The manual route in this guide remains entirely valid; the module simply removes the steps that send most merchants looking for a developer.

The pattern to remember: Redis on PrestaShop is three separate jobs, object cache (back office), sessions (PHP), and as an optional backend for full-page caching (a module). Enable the ones you want deliberately, verify each is genuinely live rather than assuming, keep sessions and cache in different databases, and judge the result by TTFB measured on your own store. Do that and Redis stops being a checkbox you hope helped and becomes a layer you can prove is working.