Strategia di cache PrestaShop 2026: Redis, Memcached, Varnish — quale stack per quale negozio

Su un negozio PrestaShop 8 o 9 non ottimizzato, il TTFB (Time To First Byte) supera comunemente gli 800 ms su hosting condiviso e resta intorno ai 400 ms su un VPS di fascia media. Effetto diretto sull’LCP (cattivo punteggio Core Web Vitals), sul budget di crawl di Googlebot e sul tasso di rimbalzo. Il tutto nel 2026, mentre il benchmark Google è passato a 200 ms di TTFB e 2,5 s di LCP.

La cache non è né un tema di nicchia né riservata ai grossi volumi. È l’ottimizzazione a maggior ROI su PrestaShop, e quella fatta peggio: confusione tra cache PHP, cache oggetto, cache HTTP e reverse proxy; configurazioni di default poco efficaci; pile di moduli che si pestano i piedi. Questo articolo fa il punto sui quattro strati di uno stack pulito e fornisce la regola decisionale Redis / Memcached / Varnish a seconda del profilo del negozio.

I quattro strati di cache di un negozio PrestaShop

Un negozio serve ogni pagina impilando più strati di cache. Conoscere gli strati significa evitare di impilarne più del necessario — ogni strato aggiunge complessità e punti di invalidazione da padroneggiare.

1. Cache opcode PHP

OPcache mette in cache il bytecode dei file .php interpretati. Indispensabile: senza OPcache, ogni richiesta PrestaShop re-interpreta migliaia di file. Guadagno tipico: 30-50% di TTFB. È gratuito, nativo PHP, ed è il primo riflesso da validare via php -i | grep opcache in produzione. Da dimensionare: 256 MB minimo per PrestaShop 8/9, opcache.validate_timestamps=0 in produzione con riciclo manuale a ogni deploy.

2. Cache oggetto (in-memory key-value)

PrestaShop mette in cache alcuni risultati applicativi: sessioni utente, metadati Smarty (percorsi dei template, configurazione degli hook), risultati di query ripetitive. Di default, queste cache passano per il filesystem, lento. In produzione seria, le si sposta verso una base in-memory: Redis o Memcached.

3. Cache HTTP e reverse proxy

Sopra a PrestaShop, un reverse proxy (Varnish, NGINX cache, o edge cache CDN) intercetta le richieste HTTP e serve risposte pre-renderizzate senza chiamare PHP. È l’ottimizzazione a maggior leva — guadagno tipico del 90% del tempo server sulle pagine anonime in hit cache.

4. Cache browser e CDN

Le risorse statiche (immagini, CSS, JS, font) devono portare header Cache-Control: public, max-age=31536000, immutable ed essere servite da un CDN. Ovvietà nel 2026, ma fatta male sul 40% dei negozi auditati: max-age troppo breve, risorse non versionate, varianti di cache mal configurate.

Redis vs Memcached: la decisione in pratica

Sulla cache oggetto, due scelte dominano: Redis e Memcached. Il dibattito “quale è più veloce” è superato — entrambi saturano ampiamente i bisogni di un negozio PrestaShop. La vera differenza è altrove.

Memcached

• Più semplice, meno funzionalità, meno superficie di attacco e meno insidie di configurazione.
• Eccellente per cache effimera key-value pura.
• Nessuna persistenza su disco: un riavvio svuota tutto, il che produce un thundering herd transitorio su PHP-FPM.
• Nessuna struttura avanzata (liste, sorted set, pub-sub) — utilizzo limitato alla cache stretta.

Redis

• Più ricco: strutture di dati (list, set, sorted set), pub-sub, scripting Lua.
• Persistenza opzionale (RDB o AOF): sopravvive ai riavvii.
• Usato ben oltre la cache PrestaShop: sessioni multi-server, queue Symfony Messenger, rate limiting.
• Configurazione di memoria da sorvegliare (maxmemory, eviction policy) — altrimenti consuma più del previsto.

Regola pratica 2026: Redis è la scelta di default. Memcached resta pertinente se il negozio è volontariamente minimalista e gli unici bisogni sono cache oggetto pura. Ogni negozio che prevede a termine una queue di job, rate limiting API o sessioni condivise multi-server guadagna a partire direttamente con Redis.

Quando Varnish ha senso (e quando no)

Varnish (o NGINX cache full-page) è l’ottimizzazione a maggior leva su PrestaShop: serve le pagine anonime in pochi millisecondi invece di 400-800 ms. Ma Varnish non è un game-changer in tutte le configurazioni.

Casi in cui Varnish cambia tutto

• Traffico maggioritariamente anonimo: visitatori non loggati, niente prezzi personalizzati per cliente, niente A/B test a chiave server. Catalogo B2C grande pubblico.
• Volume elevato concentrato su pochi URL: una homepage, 50 categorie, 500 schede prodotto rappresentano l’80% del traffico. La cache fa l’essenziale del lavoro.
• Picco stagionale prevedibile: Black Friday, saldi. Varnish assorbe il traffico senza saturare PHP-FPM.

Casi in cui Varnish è una trappola

• Negozio B2B con login obbligatorio: ogni pagina è personalizzata (prezzo gruppo cliente, multi-utente, preventivi in corso). Varnish serve solo le pagine pubbliche (rare) e la complessità supera il guadagno.
• Personalizzazione lato server: raccomandazioni AI per utente, A/B testing server, prezzi dinamici. La cache full-page rende caduca tutta la personalizzazione.
• Traffico anonimo disperso su migliaia di long-tail: se ogni URL è visitato 1 volta al giorno, l’hit ratio resta basso e Varnish non porta nulla.

L’alternativa edge cache CDN

Nel 2026, Cloudflare Cache Rules, BunnyCDN Permacache, Fastly e altri edge cache fanno il lavoro di Varnish a livello di CDN, senza server aggiuntivo. Vantaggio: nessuno strato da mantenere, distribuzione geografica, integrazione WAF nativa. Svantaggio: la purga fine è meno flessibile di Varnish, e il costo può salire sui grandi volumi. Per l’80% dei negozi mid-market, l’edge cache CDN è diventato un’alternativa superiore a un Varnish self-hosted.

Costo reale e ROI di uno stack di cache pulito

Costo

• OPcache: 0 €. Attivare e dimensionare bene.
• Redis: 0 € in locale (stesso server di PHP-FPM) a 15-30 €/mese su un VPS dedicato (Hetzner CX11) o Redis gestito (Upstash, Redis Cloud) a partire da 10 €/mese.
• Varnish: 0 € open source, ma 1-3 giorni di installazione e tuning da parte di un sysadmin competente. Da budgetare in tempo, non in licenza.
• Edge cache CDN: Cloudflare Pro 25 $/mese, BunnyCDN circa 1 $/GB trasferito, Fastly da 50 $/mese usage-based.
• Implementazione iniziale: 2-5 giorni di sviluppo per un negozio standard (configurazione, test, purga automatica su webhook PrestaShop).

ROI misurato

Su audit di negozi PrestaShop 8 mid-market post-deploy di uno stack di cache pulito:

• TTFB passa da 600-800 ms a 80-150 ms in hit cache.
• LCP scende da 3,2 s a 1,4 s su scheda prodotto anonima.
• Tasso di rimbalzo mobile cala del 12-18% in media.
• Conversione mobile aumenta del 6-12%.
• Budget di crawl Google raddoppia, il che si traduce in 4-8 settimane in +15% di URL indicizzati.

Il costo opportunità del non implementare una cache pulita supera spesso l’1% del fatturato annuo. Un negozio da 1 M€/anno perde tipicamente 10-20 K€/anno in performance degradata.

Le trappole da evitare

1. Impilare moduli di cache senza coerenza

Molti negozi accumulano: modulo ufficiale PrestaShop cache, modulo Redis di terze parti, modulo Varnish separato, plugin CDN. Senza gerarchia chiara, le cache si invalidano male tra loro e alcuni hit annullano gli altri. Serve una e una sola politica di cache documentata, con uno schema chiaro di purga a cascata.

2. Gestire male la purga su evento

Quando un prezzo cambia, uno stock si aggiorna, un attributo prodotto viene modificato, la pagina interessata deve essere purgata. PrestaShop non ha un hook unificato — bisogna cablare actionProductUpdate, actionObjectStockMvtAddAfter, actionObjectCategoryUpdateAfter e attivare la purga corretta (Varnish PURGE, Redis DEL, CDN API). Senza, il visitatore vede un prezzo obsoleto, il che può ricadere sotto la direttiva Omnibus.

3. Mettere in cache pagine personalizzate

Il carrello, l’account cliente, il checkout e ogni pagina contenente dati utente non devono mai entrare in cache full-page. La regola Varnish o CDN deve escludere esplicitamente queste route (/cart, /mio-account, /ordine, /identita). Errore frequente: un negozio che mette in cache tutto di default mostra il carrello di un altro cliente. Incidente grave e difficile da diagnosticare a posteriori.

4. Non testare sotto carico

Una cache pulita si valida sotto carico. Uno strumento come k6 o Locust permette di simulare 500-1000 visitatori simultanei e di misurare l’hit ratio, il TTFB sotto carico, la stabilità di PHP-FPM. Senza questo test, si scoprono i problemi in produzione in un giorno di picco — il momento peggiore per correggere.

5. Dimenticare il multi-shop e la multi-currency

Una cache troppo aggressiva su un negozio multi-shop può servire la stessa pagina HTML a tutti i negozi, o servire il prezzo EUR a un visitatore in GBP. La chiave di cache deve includere id_shop, id_lang, id_currency al minimo. Verificare esplicitamente la chiave di cache generata — è l’errore silenzioso più costoso in perdita di conversione.

Lo stack consigliato di default nel 2026

Per l’80% dei negozi PrestaShop 8/9 mid-market (fatturato 200 K€ – 5 M€/anno):

1. OPcache attivato con 256 MB e opcache.validate_timestamps=0 in produzione.
2. Redis come backend di cache oggetto PrestaShop (sessioni, Smarty, metadati). Un’istanza basta nella maggior parte dei casi.
3. Edge cache CDN (Cloudflare o BunnyCDN) sulle pagine catalogo e CMS pubbliche, con esclusione esplicita delle route utente.
4. Cache browser aggressiva sulle risorse statiche (1 anno), versionate per hash tramite il sistema di asset di PrestaShop.
5. Niente Varnish salvo caso specifico di grosso traffico omogeneo dove il tuning e la manutenzione si giustificano.

Questo stack si distribuisce in 2-5 giorni, costa 10-30 € al mese in spese ricorrenti, e apporta un guadagno di performance ben superiore a quello che si può ottenere ottimizzando il codice applicativo. Prima di qualsiasi ottimizzazione back-end (refactoring di moduli, query SQL), passare in rassegna questi cinque punti resta il primo passo redditizio.