# PrestaShop lento: da dove nasce il problema e come si risolve
Table of Contents
Un e-commerce lento perde vendite, ed è una perdita silenziosa: nessun cliente scrive per avvisare che la pagina ci metteva troppo, semplicemente chiude la scheda e compra altrove. Ogni secondo di attesa in più si paga in carrelli abbandonati, e il conto arriva proprio nei momenti peggiori, quando una promozione o una campagna porta più traffico del solito.
PrestaShop, di suo, non è una piattaforma lenta: lo diventa. Anni di moduli installati e mai rimossi, un tema comprato per l’estetica, un hosting scelto quando il negozio era piccolo, un database cresciuto senza manutenzione. La buona notizia è che la lentezza non è una condanna né un mistero: si diagnostica e si cura, a patto di procedere con metodo invece che a tentativi.
La lentezza ha sempre un indirizzo
“Il sito è lento” è un sintomo unico, ma le cause abitano in posti diversi: la rete e l’hosting, la versione di PHP e la sua configurazione, il database MySQL, il tema e i moduli, il front-end con i suoi script. Ogni livello ha rimedi propri, e un intervento sul livello sbagliato non produce nulla.
L’errore più comune è proprio questo: passare a un hosting più costoso senza sapere dove si perde tempo. Se il collo di bottiglia è un modulo che esegue centinaia di query per comporre la home, raddoppiare la RAM del server sposta poco: la spesa aumenta, l’attesa resta.
Misurare prima di toccare
La diagnosi separa due famiglie di tempo. C’è il tempo che il server impiega a generare la pagina, che si legge nel TTFB, il Time To First Byte, e c’è il tempo che il browser impiega a renderla usabile, misurato dai Core Web Vitals. Un TTFB alto punta a server, PHP, database o cache; un TTFB buono con una pagina comunque pigra punta a tema, immagini e script.
Gli strumenti ci sono già. PageSpeed Insights inquadra il front-end. Per il lato server, PrestaShop include un profiler integrato: attivandolo si vede, pagina per pagina, quanto tempo va in PHP, quante query vengono eseguite e quali sono le più costose. Sul database, lo slow query log di MySQL registra le interrogazioni oltre soglia. Un esempio concreto: se la home risponde in 1,8 secondi e il profiler mostra 900 query, il problema non è lo slider delle immagini, è chi compone quella pagina.
Lato server: PHP, OPcache e MySQL
PrestaShop è un’applicazione PHP, e la versione di PHP conta: ogni release recente esegue lo stesso codice più in fretta della precedente, e le versioni vecchie oltre a essere lente non ricevono più correzioni di sicurezza. Accanto alla versione serve OPcache, l’estensione che tiene in memoria il codice già compilato invece di ricompilarlo a ogni richiesta:
; /etc/php/8.3/fpm/conf.d/10-opcache.iniopcache.enable=1opcache.memory_consumption=256opcache.max_accelerated_files=40000; in produzione: niente ricontrolli dei file a ogni richiesta,; la cache si svuota al deployopcache.validate_timestamps=0Sul fronte database, la regola d’oro di MySQL è un InnoDB buffer pool dimensionato in modo che i dati caldi del negozio stiano in memoria: se il buffer è troppo piccolo, ogni pagina prodotto paga letture su disco che potrebbero essere evitate. Completano il quadro un pool PHP-FPM proporzionato a CPU e RAM disponibili e lo slow query log attivo, così le query problematiche si vedono invece di sospettarle.
Moduli e tema: i soliti sospetti
Ogni modulo installato aggiunge hook che scattano a ogni pagina, query in più, a volte chiamate a servizi esterni che tengono in ostaggio la risposta. Il marketplace è pieno di moduli scritti bene e di moduli scritti male, e uno solo di questi ultimi basta: il classico difetto è la query ripetuta per ogni prodotto in elenco invece di una sola per tutto l’elenco.
La cura è poco glamour ma efficace: inventario dei moduli, disattivazione di quelli inutilizzati o doppioni, e per i sospetti la prova del nove, disattivare e rimisurare. Lo stesso vale per il tema, dove gli override accumulati negli anni possono riscrivere pezzi di piattaforma in modo meno efficiente dell’originale.
La cache giusta al posto giusto
La cache in un PrestaShop lavora a strati: la cache dei template Smarty, la cache interna della piattaforma, una full page cache davanti a tutto per le pagine uguali per tutti i visitatori, servita idealmente da un reverse proxy, e una CDN per immagini e asset statici.
Due avvertenze. La prima: la cache nasconde il codice lento, non lo ripara, e carrello, checkout e aree utente restano dinamici per natura, quindi un backend sano serve comunque. La seconda: una cache configurata male fa danni peggiori della lentezza, dal prezzo vecchio mostrato al cliente al carrello di un altro utente. Va progettata, non semplicemente accesa.
L’hosting conta, ma non è sempre colpa sua
Sull’hosting condiviso le risorse si dividono con i vicini: CPU, disco e database possono rallentare per colpe altrui, e i limiti si sentono appena il negozio cresce. Il passaggio a un VPS o al cloud dimensionato sul traffico reale è spesso il momento di svolta, e la scelta del provider merita gli stessi criteri di qualunque infrastruttura seria.
Resta però l’ordine giusto delle cose: l’hardware più potente applicato a un negozio con 900 query in home è un modo elegante di pagare di più lo stesso problema. Prima la diagnosi, poi il dimensionamento.
In sintesi
Un PrestaShop lento si affronta in sequenza: misurare TTFB e front-end per capire il lato del problema, leggere profiler e slow query log, sistemare le fondamenta del server (PHP recente, OPcache, MySQL con memoria adeguata), fare pulizia di moduli e override, stratificare la cache dove serve e, solo a quel punto, dimensionare l’hosting sul traffico vero. Ogni passo si verifica rimisurando: se un intervento non cambia i numeri, non era il collo di bottiglia.
