PrestaShop Cache Strategy 2026: Redis, Memcached, Varnish — Which Stack for Which Store

On an unoptimized PrestaShop 8 or 9 store, TTFB (Time To First Byte) routinely exceeds 800 ms on shared hosting and stays around 400 ms on a mid-tier VPS. Direct impact: poor LCP (failing Core Web Vitals), reduced Googlebot crawl budget, and higher bounce rates. All in 2026, when Google’s benchmark has moved to 200 ms TTFB and 2.5 s LCP.

Cache isn’t a niche topic or one reserved for high-volume stores. It’s the highest-ROI optimization on PrestaShop, and the one most poorly done: confusion between PHP cache, object cache, HTTP cache, and reverse proxy; ineffective default configurations; stacks of modules stepping on each other. This article breaks down the four layers of a clean cache stack and gives the Redis/Memcached/Varnish decision rule based on store profile.

The four cache layers of a PrestaShop store

A store serves each page by stacking multiple cache layers. Knowing the layers means avoiding stacking more than necessary — each layer adds complexity and purge points to manage.

1. PHP opcode cache

OPcache caches the bytecode of interpreted .php files. Essential: without OPcache, every PrestaShop request re-interprets thousands of files. Typical gain: 30 to 50% of TTFB. Free, native to PHP, and the first thing to validate via php -i | grep opcache on a production environment. Dimension: 256 MB minimum for PrestaShop 8/9, opcache.validate_timestamps=0 in production with manual recycling on deployment.

2. Object cache (in-memory key-value)

PrestaShop caches some application-level results: user sessions, Smarty metadata (template paths, hook configuration), repetitive query results. By default, these caches go through the filesystem — slow. In serious production, they move to an in-memory store: Redis or Memcached.

3. HTTP cache and reverse proxy

Above PrestaShop, a reverse proxy (Varnish, NGINX cache, or CDN edge cache) intercepts HTTP requests and serves pre-rendered responses without ever calling PHP. The highest-leverage optimization — typical gain of 90% of server time on anonymous pages in cache hit.

4. Browser cache and CDN

Static assets (images, CSS, JS, fonts) should carry Cache-Control: public, max-age=31536000, immutable headers and be served by a CDN. Obvious in 2026, but done poorly on 40% of audited stores: max-age too short, unversioned assets, misconfigured cache variations.

Redis vs Memcached: the decision in practice

For object cache, two choices dominate: Redis and Memcached. The « which is faster » debate is settled — both vastly exceed a PrestaShop store’s needs. The real difference is elsewhere.

Memcached

• Simpler, fewer features, therefore less attack surface and fewer configuration pitfalls.
• Excellent for ephemeral pure key-value caching.
• No disk persistence: a restart wipes everything, producing a transient thundering herd on PHP-FPM.
• No advanced structures (lists, sorted sets, pub-sub) — usage limited to strict caching.

Redis

• Richer: data structures (lists, sets, sorted sets), pub-sub, Lua scripting.
• Optional persistence (RDB or AOF): survives restarts.
• Used well beyond PrestaShop caching: multi-server sessions, Symfony Messenger queue, rate limiting.
• Memory configuration to monitor (maxmemory, eviction policy) — otherwise consumes more than expected.

Practical 2026 rule: Redis is the default choice. Memcached remains relevant only if the store is deliberately minimalist on its stack and the only needs are pure object cache. Any store that may eventually need a job queue, API rate limiting, or multi-server shared sessions benefits from starting directly with Redis.

When Varnish makes sense (and when it doesn’t)

Varnish (or NGINX full-page cache) is the highest-leverage optimization on PrestaShop: it serves anonymous pages in milliseconds instead of 400-800 ms. But Varnish isn’t a game-changer in every configuration.

Cases where Varnish changes everything

• Majority anonymous traffic: non-logged-in visitors, no customer-specific pricing, no server-side A/B testing. General-public B2C catalog.
• High volume concentrated on few URLs: one homepage, 50 categories, 500 product pages account for 80% of traffic. Cache does most of the work.
• Predictable seasonal peak: Black Friday, sales. Varnish absorbs traffic without saturating PHP-FPM.

Cases where Varnish is a trap

• B2B store with mandatory login: every page is personalized (customer group pricing, multi-user, ongoing quotes). Varnish only serves the few public pages, and configuration complexity outweighs the gain.
• Server-side personalization: per-user AI product recommendations, server-side A/B testing, dynamic pricing. Full-page cache invalidates all personalization.
• Anonymous traffic spread over thousands of long-tail URLs: if each URL is visited once a day, the hit ratio stays low and Varnish adds nothing.

The CDN edge cache alternative

In 2026, Cloudflare Cache Rules, BunnyCDN Permacache, Fastly, and other edge caches do Varnish’s job at the CDN level, without an additional server. Advantage: no layer to maintain, geographic distribution, native WAF integration. Drawback: fine-grained purge is less flexible than Varnish, and cost can climb on high volumes. For 80% of mid-market stores, CDN edge cache has become a superior alternative to a self-hosted Varnish.

Real cost and ROI of a clean cache stack

Cost

• OPcache: €0. Activate and dimension properly.
• Redis: €0 locally (same server as PHP-FPM) to €15-30/month on a dedicated VPS (Hetzner CX11) or managed Redis (Upstash, Redis Cloud) starting at €10/month.
• Varnish: €0 open source, but 1 to 3 days of installation and tuning by a competent sysadmin. Budget in time, not license.
• CDN edge cache: Cloudflare Pro $25/month, BunnyCDN around $1/GB transferred, Fastly from $50/month usage-based.
• Initial implementation: 2 to 5 days of dev for a standard store (configuration, testing, automatic purge on PrestaShop webhook).

Measured ROI

From audits of PrestaShop 8 mid-market stores post-deployment of a clean cache stack:

• TTFB drops from 600-800 ms to 80-150 ms on cache hit.
• LCP falls from 3.2 s to 1.4 s on anonymous product pages.
• Mobile bounce rate decreases by 12 to 18% on average.
• Mobile conversion rises by 6 to 12%.
• Google crawl budget doubles, translating in 4-8 weeks to +15% indexed URLs.

The opportunity cost of not deploying clean caching often exceeds 1% of annual revenue. A €1M/year store typically loses €10-20K/year to degraded performance.

Pitfalls to avoid

1. Stacking cache modules without coherence

Many stores accumulate: official PrestaShop cache module, third-party Redis module, separate Varnish module, CDN plugin. Without a clear hierarchy, caches fail to invalidate each other and some hits override others. You need a single documented cache policy with a clear cascade purge scheme.

2. Mismanaging event-driven purge

When a price changes, stock updates, or a product attribute is modified, the affected page must be purged. PrestaShop has no unified hook — you have to wire up actionProductUpdate, actionObjectStockMvtAddAfter, actionObjectCategoryUpdateAfter and trigger the correct purge (Varnish PURGE, Redis DEL, CDN API). Without this, visitors see stale prices, which can fall foul of the Omnibus directive.

3. Caching personalized pages

The cart, customer account, checkout, and any page with user data should never enter full-page cache. The Varnish or CDN rule must explicitly exclude these routes (/cart, /my-account, /order, /identity). Common error: a store that caches everything by default shows one customer’s cart to another. Serious incident, hard to diagnose after the fact.

4. Not load testing

A clean cache validates under load. A tool like k6 or Locust simulates 500-1000 concurrent visitors and measures hit ratio, TTFB under load, PHP-FPM stability. Without this test, problems are discovered in production on a peak day — the worst time to fix them.

5. Forgetting multishop and multi-currency

Too-aggressive cache on a multishop store can serve the same HTML to all shops, or serve EUR pricing to a GBP visitor. The cache key must include id_shop, id_lang, id_currency at minimum. Explicitly verify the generated cache key — it’s the most expensive silent error in conversion loss.

The 2026 default recommended stack

For 80% of mid-market PrestaShop 8/9 stores (revenue €200K to €5M/year):

1. OPcache enabled with 256 MB and opcache.validate_timestamps=0 in production.
2. Redis as PrestaShop object cache backend (sessions, Smarty, metadata). A single instance suffices in most cases.
3. CDN edge cache (Cloudflare or BunnyCDN) on public catalog and CMS pages, with explicit exclusion of user routes.
4. Browser cache aggressive on static assets (1 year), hash-versioned via the PrestaShop asset system.
5. No Varnish unless specific case of high homogeneous traffic where the tuning and maintenance are justified.

This stack deploys in 2 to 5 days, costs €10-30/month in recurring fees, and brings a performance gain well above what can be achieved by optimizing application code. Before any backend optimization (refactoring modules, SQL queries), reviewing these five points remains the first profitable step.