PrestaShop Cache: Moduli Full Page Cache spiegati — pro, contro e cosa fanno davvero

Se il tuo negozio PrestaShop impiega più di 3 secondi a caricarsi, un modulo full page cache può ridurre quel tempo a meno di 200ms. Sembra una soluzione miracolosa — e onestamente, per molti negozi è esattamente la mossa giusta. Ma capire cosa fanno realmente questi moduli ti aiuterà a decidere se l'FPC è una soluzione a lungo termine, un trampolino verso un'ottimizzazione più profonda, o entrambi.

Cos'è il Full Page Cache?

Per impostazione predefinita, ogni visita al tuo negozio attiva l'intero stack: PHP si avvia, carica il framework, interroga il database decine o centinaia di volte, renderizza i template Smarty e infine restituisce l'HTML. Questo richiede dai 200ms su un server ben ottimizzato fino a 3–5 secondi su un hosting condiviso.

Un modulo full page cache (FPC) salta tutto questo. Salva l'HTML finale la prima volta che una pagina viene renderizzata, poi serve quella copia direttamente a ogni visitatore successivo. Niente PHP, niente database, niente rendering di template — solo HTML grezzo dal disco o dalla memoria.

Il risultato? I tempi di risposta crollano da secondi a millisecondi. Per un negozio che arrancava con 4 secondi di TTFB, è un miglioramento drastico e immediato.

Come funzionano i moduli FPC per PrestaShop

La maggior parte dei moduli full page cache segue uno schema simile:

1. Prima visita — La pagina si genera normalmente attraverso PrestaShop. Il modulo cattura l'HTML finale e lo salva (di solito su disco, a volte in Redis o Memcached).
2. Visite successive — Prima ancora che PrestaShop si avvii, il modulo controlla se esiste una versione in cache. Se sì, serve l'HTML immediatamente. PrestaShop non si carica mai.
3. Rendering senza sessione — La pagina in cache è generica: nessun contenuto del carrello, nessun nome cliente, nessun "Bentornato, Giovanni" — perché è stata catturata senza alcun contesto di sessione.
4. Idratazione JavaScript — Dopo il caricamento dell'HTML statico, JavaScript effettua chiamate AJAX per recuperare i dati di sessione: conteggio carrello, nome cliente, prodotti visti di recente, stato di login. La pagina si aggiorna nel browser.

Questo è il compromesso fondamentale del full page cache: il server risponde velocemente, ma il browser ha lavoro extra da fare dopo.

I vantaggi — e sono reali

TTFB quasi istantaneo

Il TTFB scende da 1–5 secondi a 20–100ms. È il singolo miglioramento di performance più grande che puoi ottenere, e influisce direttamente sui punteggi Core Web Vitals. Per i negozi dove il server è il collo di bottiglia (hosting lento, database non ottimizzato, moduli pesanti), è un cambiamento radicale.

Un vero salvagente per i negozi in difficoltà

Siamo onesti: non tutti i proprietari di negozi hanno tempo, budget o risorse tecniche per un audit completo delle performance. Se il tuo negozio è lento e la disponibilità di sviluppatori è limitata, l'FPC ti riporta a tempi di caricamento competitivi oggi stesso. Non è un compromesso — è una decisione commerciale intelligente. Un negozio veloce con cache batte un negozio lento senza cache, ogni volta.

L'FPC essenzialmente maschera tutto ciò che è lento sotto. E per un negozio che non può investire in ottimizzazione profonda adesso, quel mascheramento è esattamente ciò che serve. Prima spedisci, poi ottimizzi.

Riduzione del carico server

Su hosting condiviso con CPU e memoria limitati, l'FPC fa sì che la maggior parte delle richieste non tocchi mai PHP. Il tuo server può gestire molti più visitatori simultanei senza rallentare o raggiungere i limiti delle risorse.

Migliori posizionamenti su Google

La velocità della pagina è un fattore di ranking confermato da Google. Un negozio che si carica in 200ms si posizionerà meglio di uno che impiega 4 secondi — specialmente su mobile. L'FPC offre questo miglioramento con sforzo minimo.

Gli svantaggi — cosa tenere presente

Il problema dell'idratazione di sessione

Questo è il compromesso più visibile del full page cache. Quando la pagina in cache si carica, mostra una versione senza sessione del negozio. L'icona del carrello mostra 0 articoli. L'header dice "Accedi" anche se sei loggato. I prodotti visti di recente sono assenti.

Poi, una frazione di secondo dopo, JavaScript interviene e aggiorna tutti questi elementi. Il contatore del carrello appare. "Accedi" diventa "Bentornato, Giovanni". La valuta cambia. Questo crea salti visivi evidenti — elementi che si spostano, testo che cambia, numeri che appaiono.

Problemi di CLS (Cumulative Layout Shift)

Quei salti visivi penalizzano il punteggio CLS, uno dei tre Core Web Vitals. Potresti ottenere un punteggio LCP perfetto grazie alla consegna rapida, ma perdere punti sul CLS a causa degli aggiornamenti di idratazione. Il guadagno netto sui Core Web Vitals può essere inferiore al previsto.

Rischio di contenuti obsoleti

La pagina in cache è un'istantanea congelata. Quando aggiorni il prezzo di un prodotto, cambi la descrizione di una categoria, attivi una promozione o esaurisci le scorte — la versione in cache mostra ancora i vecchi dati finché la cache non viene invalidata.

I buoni moduli FPC hanno hook di invalidazione, ma non è mai perfetto: regole di prezzo su più prodotti, importazioni ERP che aggirano gli hook, promozioni a tempo e modifiche di moduli terzi possono tutti portare a contenuti brevemente obsoleti.

Complessità del debugging

Quando qualcosa va storto su un negozio con cache, la prima domanda è sempre: "È la cache?" Si finisce per svuotare la cache come primo passo diagnostico per quasi ogni problema.

Andare più a fondo: correggere le cause alla radice

Il full page cache è una soluzione perfettamente valida — ma vale la pena capire che la lentezza che maschera di solito deriva da problemi specifici e risolvibili. Se e quando avrai tempo e risorse, affrontare queste cause ti darà il meglio di entrambi i mondi: pagine veloci senza salti di idratazione, rischi di contenuti obsoleti o grattacapi di debugging.

Non è qualcosa da fare tutto in una volta. Consideralo una roadmap — correggi le cose una alla volta man mano che budget e disponibilità lo permettono. Ogni miglioramento si somma.

Importante: non fare il passo più lungo della gamba. Se non hai le risorse per un progetto di ottimizzazione completo, un modulo FPC ben configurato è la scelta più intelligente rispetto a un'ottimizzazione a metà che lascia il negozio in uno stato peggiore. Fatto è meglio di perfetto.

1. Identificare i moduli lenti

Questa è quasi sempre la causa numero uno dei negozi PrestaShop lenti. Ogni modulo attivo può agganciarsi a decine di eventi, e ogni esecuzione di hook si aggiunge al tempo totale di rendering.

Un singolo modulo che esegue query non indicizzate in displayHeader può aggiungere 500ms a ogni caricamento. Un modulo di statistiche che logga ogni visualizzazione in modo sincrono può aggiungerne altri 200ms. Impila tre o quattro di questi e il tuo negozio impiega 3 secondi solo per l'esecuzione degli hook.

2. Correggere la compilazione Smarty

PrestaShop usa Smarty come motore di template, che compila i file .tpl in PHP. In produzione, questo dovrebbe avvenire una sola volta e venire messo in cache.

• force_compile deve essere disattivato in produzione — se attivo, ogni template viene ricompilato a ogni caricamento (200–500ms extra)
• caching deve essere attivo
• Dopo il deploy, svuota la cache di compilazione una volta — non lasciare force_compile attivo come workaround

3. Configurazione MySQL

La configurazione MySQL predefinita è pensata per uso generico, non per PrestaShop. Parametri chiave: innodb_buffer_pool_size (50–70% della RAM disponibile), innodb_log_file_size (minimo 256MB), abilitazione del slow_query_log, pulizia delle tabelle gonfiate (ps_connections, ps_log, ps_mail).

4. Redis per cache e sessioni

PrestaShop usa il caching su file per impostazione predefinita. Sotto carico, il file locking crea contesa. Redis sposta tutto in memoria: cache Smarty, cache Symfony, sessioni PHP. Una singola istanza Redis con 256MB gestisce questi carichi per un negozio tipico.

5. PHP e OPcache

• PHP 8.1+ — 20–40% più veloce di PHP 7.4. Il guadagno più facile.
• OPcache — mette in cache il bytecode PHP compilato. Indispensabile in produzione.
• Realpath cache — aumenta realpath_cache_size a 4096K. PrestaShop include centinaia di file per richiesta.

6. Ottimizzazione front-end

• CCC — combina CSS/JS in file singoli, riduce le richieste HTTP
• CSS critico — stili above-the-fold inline nell'HTML, il resto differito. Il nostro modulo Performance Revolution automatizza l'intera pipeline.
• JavaScript differito — script non critici (analytics, chat) caricano dopo il contenuto principale
• Ottimizzazione immagini — formati WebP/AVIF, srcset responsive, dimensioni esplicite
• CDN — mette in cache le risorse statiche su server edge in tutto il mondo

L'effetto combinato

Queste ottimizzazioni si sommano. Correggere i moduli lenti risparmia 500ms–2s. MySQL 100–300ms. Redis 50–200ms. PHP 8 + OPcache 100–300ms. Il CSS critico migliora la percezione di 500ms–1s. Un negozio che partiva da 4 secondi può realisticamente raggiungere sotto i 200ms — con pagine fresche e zero compromessi.

Ma ribadisco: ci vuole tempo e competenza. Se non sei ancora lì, un buon modulo FPC è la scelta giusta.

In conclusione

I moduli full page cache per PrestaShop sono una soluzione legittima ed efficace per rendere veloci i negozi lenti. Funzionano servendo copie HTML statiche e idratando i dati di sessione via JavaScript — con compromessi su salti dell'interfaccia, contenuti obsoleti e complessità del debugging.

Per i negozi che hanno bisogno di velocità adesso e non possono investire in ottimizzazione profonda, l'FPC è la scelta pragmatica. Per quelli che hanno le risorse per scavare più a fondo, correggere le cause alla radice — moduli lenti, template mal configurati, database non ottimizzati — offre la stessa velocità senza compromessi.

Il percorso migliore? Usa l'FPC se ne hai bisogno. Ma tieni l'ottimizzazione approfondita nella tua roadmap. Quando ci arriverai, il tuo negozio sarà veloce di per sé — e potrai ritirare il full page cache sapendo che tutto sotto è in salute.