Che cosa rende davvero lento PrestaShop: database, moduli e hosting

PrestaShop non è lento per natura. Un'installazione pulita di 1.7, 8.x o 9.x, con un catalogo sensato e una lista di moduli gestita con disciplina, risponde ben sotto il secondo. Quindi, quando un negozio si trascina, "PrestaShop è pesante" non è quasi mai la diagnosi reale: c'è qualcosa di specifico che rende lento questo negozio, e si trova in uno di tre punti: il database, i moduli o l'hosting. La trappola in cui cadono molti commercianti è affrontare tutti e tre insieme: comprare Redis, cambiare hosting e disattivare metà dei moduli in preda al panico, senza capire quale elemento stesse davvero costando quei secondi. Questa guida parla di attribuzione: come osservare un negozio PrestaShop lento e capire quale livello è il responsabile, così da investire energie dove il tempo viene perso davvero.

Le soluzioni vere e proprie hanno ciascuna la propria guida in questo gruppo di articoli: le colleghiamo man mano. Qui troverai la parte che quasi nessuno mette per iscritto: come capire, sul tuo negozio, quale dei tre elementi ti sta rallentando.

Rivisto per PrestaShop 1.7, 8.x e 9.x. Una nota onesta per le versioni più recenti: JIT e OPcache di PHP 8 sono la fonte principale della sensazione che "PrestaShop nuovo sia più veloce", e il passaggio di PS9 a Symfony 6.4 alleggerisce la compilazione del container; ma questi miglioramenti agiscono sul livello hosting/PHP, non su un database gonfio o su un modulo che esegue query in ciclo. Aggiornare la piattaforma non sostituisce mai l'attribuzione della vera causa descritta qui sotto.

Perché "è lento" significa tre problemi completamente diversi

La lentezza è un sintomo, e lo stesso sintomo può avere tre cause non correlate, che si risolvono in tre modi diversi. Intervenire su quella sbagliata significa sprecare denaro. Ecco come ogni livello fallisce, come si manifesta e dove finisce davvero il tempo:

E quindi? Se il problema è il database, un server più veloce sposta appena l'ago della bilancia: eseguirai le stesse query lente su hardware solo un po' più rapido. Se il problema è la contesa dell'hosting, ripulire il database non ti salverà dal vicino che lancia un backup alle 17. Abbinare la soluzione alla causa è l'intera partita.

Primo passo: separare la linea temporale tra "server" e "browser"

Prima di poter incolpare un livello, devi sapere se il tempo si perde sul server (PrestaShop che costruisce la pagina) o nel browser (download e rendering). Questa singola distinzione ti manda su due strade diverse.

Il numero che le separa è il TTFB, Time to First Byte: quanto tempo impiega il server a iniziare a rispondere. In un negozio PrestaShop sano, il TTFB resta sotto circa 300 ms; oltre un secondo significa che il lato server è in difficoltà. Tutto ciò che viene dopo il primo byte, cioè immagini, CSS, JavaScript e font, riguarda il browser/front-end.

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
  https://www.example.com/category-url

• TTFB alto, rendering rapido una volta arrivata la risposta → la causa è lato server: database o hosting (continua a leggere per distinguerli).
• TTFB basso, ma la pagina sembra comunque comparire lentamente → la causa è front-end: di solito moduli che accumulano richieste, più immagini e risorse.

Non ripeteremo qui la meccanica della misurazione: testare il TTFB su diversi tipi di pagina, leggere i Core Web Vitals (LCP, INP, CLS) e capire che aspetto ha un numero "buono" sono temi trattati in modo completo in il tuo negozio è lento? come verificarlo e cosa fare. Fallo prima; poi torna con un valore TTFB e con il tipo di pagina peggiore. Il resto di questa guida interpreta questi due dati.

È il database? La causa più comune e più nascosta

Per la nostra esperienza nella gestione e correzione di negozi PrestaShop, il database è la fonte più comune di lentezza lato server ed è anche quella meno sospettata, perché non lascia tracce evidenti nel browser. I segnali rivelatori:

• Il TTFB aumenta con l'età del negozio: al lancio andava bene, poi è peggiorato senza cambiamenti evidenti. È il gonfiarsi delle tabelle: ps_connections, ps_connections_source, ps_guest, ps_statssearch, ps_pagenotfound e ps_log crescono all'infinito e vengono interrogate per le statistiche. Le vecchie righe dei carrelli abbandonati in ps_cart non spariscono da sole.
• Anche il back office è lento, non solo il front office. Un problema puramente di hosting o front-end di solito risparmia l'amministrazione; un problema di database colpisce entrambi, perché entrambi eseguono le stesse query sulle stesse tabelle appesantite.
• La stessa tabella compare continuamente nel log delle query lente (imposta long_query_time basso e osserva). I recidivi senza un indice sulle colonne usate in WHERE/JOIN sono la prova più chiara: una query istantanea su 1.000 righe diventa dolorosa su 1.000.000.

La soluzione si divide in modo netto. Ridurre il gonfiore è la metà più semplice e con il rendimento più alto, e merita una guida a parte: vedi pulizia del database: perché il tuo negozio rallenta nel tempo per sapere che cosa è sicuro eliminare e che cosa no. La metà più profonda, cioè ottimizzazione delle query, indici e combinazione di pulizia e cache, è in ottimizzare le prestazioni del negozio: dalle query del database alla cache full page.

Se preferisci non eseguire istruzioni DELETE a mano o configurare da solo il cron, il nostro modulo Database Cleanup applica dal back office la versione sicura per impostazione predefinita: carrelli scaduti, vecchie statistiche di ricerca, record di ospiti e connessioni, log obsoleti, tutto su pianificazione, così le tabelle non hanno più occasione di gonfiarsi. E quindi? Il TTFB che cresceva mese dopo mese smette di salire, senza toccare SQL e senza dovertelo ricordare.

La scheda di configurazione mostra l'area di pulizia abilitata e il modulo contrassegnato come installato e pronto.

SELECT table_name, table_rows, ROUND((data_length + index_length) / 1024 / 1024, 1) AS mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name IN ('ps_connections', 'ps_connections_page', 'ps_guest', 'ps_cart', 'ps_log', 'ps_search_index')
ORDER BY (data_length + index_length) DESC;

Sono i moduli? Mille hook che sommandosi uccidono le prestazioni

La differenza tra un negozio PrestaShop veloce e uno lento è, più spesso di qualsiasi altro singolo fattore, nei moduli: in particolare quanti vengono eseguiti su ogni pagina e che cosa fanno mentre sono lì. Qui i segnali sono diversi da quelli del database:

• Un tipo di pagina è drasticamente più lento degli altri: per esempio, le pagine prodotto si trascinano mentre la pagina iniziale va bene. Questo indica un modulo agganciato a quella pagina (un controllo scorte in tempo reale, una vendita incrociata che calcola relazioni, un widget recensioni), più che un problema uniforme del server.
• Molte richieste front-end e JavaScript pesante nel pannello rete, spesso da domini di terze parti. È la firma front-end della proliferazione dei moduli.
• È diventato più lento subito dopo aver installato qualcosa. Il test più pulito di tutta questa guida: disattiva il modulo sospetto, misura di nuovo, riattivalo. Abilita il Profiler (imposta _PS_DEBUG_PROFILING_ su true in config/defines.inc.php su una copia di staging), poi leggi l'output per controllare il tempo di esecuzione degli hook e il numero di query SQL per modulo: è così che trovi quello che aggiunge 200 ms a ogni caricamento. La pagina Parametri avanzati → Prestazioni serve invece per cache e impostazioni legate al debug, non per i risultati di profiling.

A cosa fare attenzione nello specifico:

• Troppi hook. Ogni modulo su displayHeader, displayTop, displayFooter o actionFrontControllerSetMedia viene eseguito su ogni singola pagina. Trenta moduli lì significano trenta funzioni prima che venga renderizzato un solo pixel.
• Chiamate API esterne al caricamento della pagina. Una tariffa di corriere recuperata in tempo reale, un tasso di cambio richiesto a ogni visualizzazione, un flusso social che chiama casa in tempo reale: ciascuno aggiunge 200-500 ms di latenza di rete e, se quel servizio è inattivo, la tua pagina aspetta con lui. La soluzione è sempre la stessa: memorizzare il risultato localmente e aggiornarlo tramite cron, mai sulla richiesta del visitatore.
• Moduli ridondanti. Due moduli SEO, tre strumenti di tracciamento analytics, una coppia di banner cookie: ognuno tassa ogni pagina. Un modulo scelto bene batte tre moduli che litigano per lo stesso compito; fai audit e rimuovi i duplicati.

Per un esempio concreto di quanto ci si possa spingere nella direzione giusta, cioè un vero negozio PrestaShop 9 con oltre 130 moduli e ancora un punteggio di 99/100, vedi PageSpeed 99/100 su un vero negozio con oltre 130 moduli. La lezione è quella incoraggiante: il numero di moduli non è il nemico, lo è la disciplina con cui vengono gestiti.

È l'hosting? La tassa fissa che non puoi eliminare con la cache

L'hosting è il livello che i commercianti accusano per primo e diagnosticano per ultimo, di solito perché correggerlo costa. I segnali onesti che sia davvero il tuo problema, e non un capro espiatorio:

• Le prestazioni variano a seconda dell'ora. Veloce alle 3 di notte, fiacco alle 18 senza cambiamenti nel tuo traffico. È la classica contesa CPU/RAM dell'hosting condiviso: il carico dei vicini entra nel tuo negozio.
• Il TTFB è alto anche su una pagina pulita, con cache già calda e database già alleggerito. Se hai escluso gli altri due elementi e il server risponde ancora lentamente, il limite è l'hardware sottostante.
• OPcache è disattivato. È la singola impostazione di hosting con l'impatto più alto per PrestaShop: mantiene in memoria il bytecode PHP compilato, così i file non vengono rianalizzati a ogni richiesta, e vale una grossa fetta del tuo TTFB. Verifica opcache.enable=1, con opcache.memory_consumption=256 e opcache.max_accelerated_files=20000. Imposta opcache.validate_timestamps=0 solo se i tuoi deployment azzerano in modo affidabile PHP-FPM/OPcache subito dopo; altrimenti mantieni la validazione dei timestamp con un opcache.revalidate_freq sensato, o rischi di servire PHP obsoleto dopo un aggiornamento di modulo, core o tema.

Un negozio PrestaShop serio richiede, come minimo, un VPS o un server dedicato (non hosting condiviso affollato), storage SSD, PHP 8.1+ con OPcache e MySQL 8.0 / MariaDB 10.6+ con innodb_buffer_pool_size calibrato sulla RAM. Ma "compra un server più grande" è la versione pigra di questo consiglio, e molto di ciò che gli hosting vendono è marketing. Quali specifiche spostano davvero l'ago per PrestaShop, e quali servono solo a venderti di più, è una decisione a sé, spiegata in scegliere l'hosting per PrestaShop: cosa conta e cosa è marketing. Ridimensiona il server dopo aver risolto gli altri due livelli, non prima, altrimenti pagherai ogni mese per eseguire più velocemente le stesse query lente.

Dove entra in gioco la cache, e dove no

La cache è la risposta istintiva alla lentezza, ed è una buona risposta per la causa giusta; ma maschera i problemi tanto spesso quanto li risolve, quindi appartiene alla fine di questa guida, non all'inizio. Una cache nasconde un database lento ai visitatori anonimi; non fa nulla per il cliente connesso, il carrello, la procedura di pagamento o il back office, che continuano tutti a eseguire la query reale.

Contano due tipi, e corrispondono a due dei livelli sopra:

• Cache oggetti (Redis / Memcached) attacca il livello database: dove core e moduli usano le API di cache di PrestaShop, può velocizzare ricerche ripetute e memorizzabili in cache e ridurre il costo della cache su filesystem. Però non è una cache SQL universale: memorizza solo valori salvati esplicitamente tramite quelle API, quindi molte query continuano comunque ad arrivare a MySQL. È il cambiamento con il maggiore impatto che puoi fare se la diagnosi sopra indicava il database. Configurazione e guadagni realistici sono in cache Redis per PrestaShop: configurazione e miglioramenti di prestazioni, con il ragionamento sul perché aiuta in Redis: l'upgrade di velocità di cui il tuo negozio probabilmente ha bisogno. Il nostro modulo Redis Cache Manager & Monitor configura e monitora dal back office le impostazioni Redis richieste, se preferisci non modificare la configurazione a mano.
• Cache a pagina intera serve ai visitatori anonimi una pagina HTML già costruita, così PrestaShop non deve costruire nulla: è il singolo guadagno più grande per il TTFB del front office sul traffico idoneo alla cache. Non è nel core; le opzioni dei moduli e i compromessi reali sull'invalidazione della cache sono confrontati in cache PrestaShop: spiegazione dei moduli di cache a pagina intera.

E le funzioni integrate che dovresti già avere attive in ogni caso: cache Smarty abilitata con Forza compilazione: No, e CCC (Combina, Comprimi, Cache) per CSS/JS, entrambe sotto Parametri avanzati → Prestazioni. Sono gratuite, incluse nella piattaforma, e sorprende quanti negozi le lascino disattivate.

Se preferisci non assemblare Redis, cache a frammenti, ottimizzazione delle risorse e monitoraggio pezzo per pezzo, il nostro modulo MPR Performance Revolution li riunisce dietro un unico pannello nel back office. Che cosa ci guadagni, in pratica? I livelli di cache ad alto impatto vengono attivati insieme, con monitoraggio per confermare che stiano davvero servendo risultati dalla cache: così non devi indovinare se la cache è calda.

La checklist che parte dalla diagnosi

Mettendo tutto insieme, l'ordine che ti evita più lavoro sprecato è: misura, attribuisci, poi correggi il livello che hai effettivamente individuato, non tutti e tre per fiducia.

• 1. Misura. Registra TTFB e caricamento completo della pagina su pagina iniziale, una categoria ricca e una pagina prodotto. (Meccanica: il tuo negozio è lento?)
• 2. Separa server e browser. TTFB alto → server (database/hosting). TTFB basso, rendering lento → front-end (moduli/risorse).
• 3. Se è lato server, separa database e hosting. Back office lento + tabelle che crescono nel tempo + recidivi nel log lento = database. Prestazioni incostanti per ora del giorno + OPcache disattivato + pulito ma ancora lento = hosting.
• 4. Se è front-end, isola il modulo. Un tipo di pagina molto più lento → usa il Profiler sugli hook, disattiva il sospetto e misura di nuovo.
• 5. Correggi il livello che hai trovato usando la guida collegata per quel caso, non una raffica indistinta su tutti e tre.
• 6. Aggiungi la cache per ultima, abbinata alla causa: cache oggetti per un collo di bottiglia del database, cache a pagina intera per il TTFB del front office.
• 7. Misura di nuovo rispetto al riferimento iniziale. Se il numero non si è mosso, hai trattato il livello sbagliato: torna al passaggio 3.

Le prestazioni non si sistemano una volta per tutte. Un negozio veloce con 500 prodotti va ricontrollato a 5.000; una lista di moduli snella l'anno scorso può essere cresciuta in silenzio. Ma la disciplina che mantiene veloce un negozio PrestaShop non è esotica: consiste nel rifiutarsi di tirare a indovinare. Scopri quale dei tre livelli ti sta davvero costando secondi, correggi quello, misura e ripeti. "PrestaShop è lento" non è quasi mai vero. "Il database di questo negozio si gonfia da tre anni", oppure "questi quattro moduli chiamano ciascuno un'API sulla pagina prodotto", oppure "questo hosting condiviso è sovravenduto": una di queste cose è vera, e si può trovare in un pomeriggio.

Domande frequenti

Anche il back office è lento. Questo restringe il campo?

Sì: è uno dei segnali più utili che hai. Un collo di bottiglia puramente di hosting o un problema front-end/moduli di solito risparmia l'amministrazione, perché il back office carica pagine diverse e meno script del front office. Quando anche l'amministrazione è lenta, entrambi i lati stanno eseguendo le stesse query sulle stesse tabelle appesantite, il che punta con forza al database. Conferma con il log delle query lente: la stessa tabella che ricompare più volte senza un indice è la prova più chiara.

Una pagina prodotto è lenta ma la pagina iniziale va bene. Dove guardo?

Questa asimmetria indica quasi sempre un modulo agganciato a quella pagina specifica: un controllo scorte in tempo reale, una vendita incrociata che calcola relazioni, un widget recensioni che lancia una query per ogni elemento. Un problema uniforme del server o dell'hosting rallenta tutto in modo omogeneo; una singola pagina lenta è la firma di un modulo. Abilita il profiler, leggi i tempi per hook e disattiva il sospetto per misurare di nuovo. La differenza prima/dopo è esattamente quanto quel modulo ti costa.

Redis risolverà un collo di bottiglia del database?

In parte, e solo se la diagnosi punta davvero al database. La cache oggetti (Redis/Memcached) velocizza ricerche ripetute e memorizzabili in cache e rimuove il costo della cache su filesystem, ma non è una cache SQL universale: memorizza solo valori salvati esplicitamente tramite le API di cache di PrestaShop, quindi molte query continuano comunque ad arrivare a MySQL. Prima pota le tabelle gonfie e aggiungi gli indici mancanti; poi aggiungi Redis sopra un database sano, dove ripaga invece di coprire una scansione.

È sicuro superare tutto questo con la cache?

Una cache a pagina intera è il singolo guadagno più grande per il TTFB del front office, ma serve solo i visitatori anonimi. Non fa nulla per il cliente connesso, il carrello, la procedura di pagamento o il back office, che continuano tutti a eseguire la query reale. E non devi mai mettere in cache le pagine di carrello/pagamento/login: un pagamento in cache può mostrare a un cliente il carrello di un altro. Metti in cache l'involucro del front office, lascia vive le rotte dinamiche e considera la cache l'ultimo passo, non il primo.

Ho aggiornato a PrestaShop 9 / PHP 8 ed è ancora lento. Perché?

Perché gli aggiornamenti di versione migliorano il livello PHP e piattaforma: JIT, OPcache, compilazione più economica del container Symfony 6.4, non il database. Se la causa reale sono tre anni di gonfiore di ps_connections o quattro moduli che chiamano ciascuno un'API sulla pagina prodotto, la piattaforma più nuova esegue esattamente quei problemi su hardware più veloce. Attribuisci prima il livello; l'aggiornamento aiuta la parte che non era mai il tuo collo di bottiglia.