Cache della pagina completa in PrestaShop: quando serve e cosa lasciare fuori

Ogni volta che qualcuno apre una scheda prodotto, PrestaShop si avvia, interroga il database decine o centinaia di volte, compone il template e restituisce l'HTML. Per il visitatore successivo che apre la stessa scheda, ripete esattamente lo stesso lavoro. La cache della pagina completa salva quell'HTML la prima volta e lo serve direttamente le volte successive, senza eseguire PrestaShop.

La differenza nel tempo di risposta del server può essere enorme. Ma un negozio non è un blog: ha carrello, sessione, prezzi per cliente e un banner dei cookie. Mettere in cache ciò che non si deve è il modo più rapido per mostrare a un cliente il carrello di un altro.

Le cache che PrestaShop ha già (e in cosa si differenzia)

• Cache dei template Smarty: salva i template compilati. Accelera la composizione, ma PrestaShop continua a essere eseguito a ogni visita.
• Cache di oggetti o query (Memcached, Redis, APCu): salva i risultati delle query. Meno carico sul database, ma PHP continua a essere eseguito.
• OPcache: salva il PHP compilato. Indispensabile, e non ha nulla a che vedere con l'HTML.
• Cache della pagina completa: salva il risultato finale. È l'unica che evita di eseguire PrestaShop.

Non sono in competizione: si sommano. Un negozio ben configurato ha sempre OPcache, e cache delle query e della pagina a seconda del traffico e del catalogo.

Quali pagine si possono mettere in cache

La regola pratica: si mette in cache per il visitatore anonimo e senza carrello. Appena c'è una sessione cliente o ci sono prodotti nel carrello, la pagina viene generata normalmente.

Cosa risolvere prima di attivarla

Parti dinamiche dentro una pagina memorizzabile

La scheda prodotto è uguale per tutti, ma il contatore del carrello nell'intestazione no. E nemmeno il «Ciao, Marta» o i prezzi, se hai gruppi di clienti con listini diversi. Ci sono due modi per risolverlo: non usare la cache per chi ha una sessione o un carrello, oppure caricare quelle parti dopo via AJAX. Il primo è il più sicuro.

Prezzi per gruppo, paese o valuta

Se un cliente B2B vede altri prezzi, non deve mai ricevere la versione in cache dell'anonimo, né il contrario. Lo stesso vale per valute e paesi che cambiano le imposte: o si salva una versione per ogni combinazione, o quelle visite non vanno in cache.

Mobile e desktop

Se il tuo tema genera un HTML diverso per il mobile, servono versioni separate per dispositivo. Se è un tema responsive puro, basta una sola versione.

Cookie e consenso

È il punto più trascurato. Se il tuo banner dei cookie decide lato server quali script stampare, la prima pagina in cache «congela» la decisione di chi l'ha generata. Un visitatore che ha accettato tutto genera la pagina con i pixel attivi, e il successivo, che non ha ancora deciso, li riceve comunque.

Le soluzioni abituali: far applicare il blocco al banner nel browser, su una pagina uguale per tutti, oppure far salvare alla cache versioni separate in base allo stato del consenso.

Invalidare: il vero problema

Mettere in cache è facile. Il difficile è sapere quando una pagina salvata non è più vera. In un negozio succede di continuo:

• Cambi un prezzo o una descrizione.
• Attivi una regola carrello o un prezzo specifico.
• Un prodotto si esaurisce con un ordine.
• Modifichi una categoria, un produttore o una pagina CMS.

Se la cache non se ne accorge, i clienti vedono il prezzo vecchio o un prodotto «disponibile» che non lo è più. Le strategie sono due: scadenza a tempo (la pagina vale un'ora e poi si rigenera) e svuotamento per evento (salvando un prodotto si svuota ciò che lo riguarda). La cosa giusta è combinarle: svuotamento quando cambi qualcosa e scadenza come rete di sicurezza.

E una cosa da sapere: le modifiche che non passano dal back office, come un'importazione con SQL diretto o un ERP che scrive nel database senza usare l'API, non attivano alcun evento. Se il tuo stock entra così, devi svuotare la cache alla fine di ogni sincronizzazione.

Quando non conviene

• Negozi con quasi tutto il traffico autenticato, come un B2B in cui tutti effettuano l'accesso: la percentuale di hit sarà bassa.
• Cataloghi che cambiano ogni pochi minuti per la sincronizzazione con i fornitori: la cache viene svuotata prima di servire qualcosa.
• Un server lento per un'altra causa: una query senza indici adeguati o un modulo che chiama un'API esterna in ogni pagina. La cache lo nasconde per l'anonimo, ma il cliente che compra continua a subirlo nel checkout, che è dove conta.

Prima, una base aggiornata

Una cache della pagina su PHP 7.x e PrestaShop 1.6 continua a servire velocemente gli anonimi, ma carrello e pagamento, che non vanno mai in cache, restano lenti come prima. Con PHP 8, OPcache ben configurato e PrestaShop aggiornato, la parte che non si può mettere in cache è già molto più veloce. Per questo, in un negozio molto indietro, aggiornare è di solito il primo passo per le prestazioni e la cache il secondo.

Checklist prima di attivarla

• OPcache attivo e con memoria sufficiente.
• Carrello, ordine, pagamento, account e controller dei moduli esclusi.
• Nessuna cache per visitatori con sessione o carrello, oppure parti dinamiche via AJAX.
• Prova del consenso in due finestre private.
• Prova del prezzo: cambiane uno e verifica che la scheda lo rifletta.
• Prova dello stock: ordina l'ultimo pezzo rimasto e guarda la scheda.
• Svuotamento alla fine di ogni sincronizzazione esterna.

Come risolverlo in PrestaShop

All In One Cache gestisce tre cache da un unico pannello: pagina completa su disco, query SQL in Redis (PrestaShop 8 o superiore, con le tabelle di ordini, carrelli, sessioni e stock bloccate di serie) e OPcache. Nella cache della pagina decidi cosa resta fuori, anche URL tramite espressione regolare, puoi separare le versioni per dispositivo e lo svuotamento è agganciato a PrestaShop: salvando un prodotto, una categoria, un prezzo specifico, una regola carrello o una pagina CMS la cache si svuota, e convalidando un ordine o cambiando lo stock si svuota quella dello stock. Puoi anche svuotare un URL specifico o tutto dal pannello, e vedi hit e miss. Se preferisci che te la lasciamo configurata e collaudata nel tuo negozio, c'è il servizio di All In One Cache.