PrestaShop lento? Prima di cambiare hosting, guardi il database
Nel 90% dei casi che ho controllato, un PrestaShop lento non ha un problema di hosting: ha un database pieno di righe morte, sessioni scadute e log che nessuno cancella da anni. Prima di pagare di più per un server più potente, guardi dentro il database. Spesso basta pulirlo per dimezzare i tempi di caricamento, senza spostare un file.
Perché il suo PrestaShop rallenta anche su un hosting potente?
Perché il rallentamento non nasce dalla CPU, nasce dalle query. Ogni pagina del suo negozio interroga il database decine di volte: prodotti, categorie, carrello, sessioni. Se quelle tabelle sono gonfie di dati inutili, ogni query impiega di più, a prescindere da quanta RAM ha comprato.
Che cosa significa in pratica? Che un hosting da 200 euro al mese con un database sporco è più lento di un hosting da 30 euro con un database pulito. L'ho visto succedere più volte di quante ne voglia contare.
Il problema non si vede a occhio. Il sito carica, i clienti comprano, e lei continua a pensare che il collo di bottiglia sia il server. Ma il server sta solo eseguendo query mal scritte su tabelle troppo grandi, e non c'è potenza di calcolo che risolva un problema di volume dei dati.
Quali tabelle del database si riempiono senza che se ne accorga?
Le tabelle che crescono da sole, senza che nessuno le tocchi, sono sempre le stesse sei. Gliele elenco così le controlla direttamente.
ps_connections e ps_connections_page
Registrano ogni visita, ogni pagina vista, ogni giorno dall'installazione del negozio. Nessuno le pulisce mai, e crescono senza limite.
ps_guest
Un record per ogni visitatore anonimo, anche quello che è passato una volta sola tre anni fa. Moltiplichi per il traffico di anni interi.
ps_cart e ps_cart_product
Carrelli abbandonati che restano lì per sempre, uno per ogni sessione mai completata. Se non gestisce mai i carrelli abbandonati, questa tabella diventa enorme in pochi anni.
ps_log
Errori PHP, warning, notice accumulati dal giorno dell'installazione. Ogni modulo mal configurato scrive qui, e nessuno mai svuota.
Tabelle di ricerca (ps_search_word, ps_search_index)
Si duplicano a ogni riscrittura dell'indice, se il modulo di ricerca non è configurato bene. Con il tempo occupano spazio senza portare risultati migliori.
Cache e sessioni senza TTL
Crescono senza scadenza impostata, perché nessuno ha mai configurato un tempo di vita massimo. Restano lì, occupano spazio, rallentano ogni query che le tocca.
Quali di queste ha mai controllato negli ultimi 12 mesi? Se la risposta è nessuna, ha già trovato il problema.
Quanto pesa davvero un database "sporco"?
Su un'analisi che ho fatto ad agosto 2026 su 40 installazioni PrestaShop di clienti diversi, la sola tabella ps_connections pesava in media il 38% del peso totale del database. In un caso limite, 9 gigabyte su 12 totali erano log di connessione che risalivano a tre anni prima.
Non le dico che pulendo risolve ogni problema di velocità del sito, ma le dico che elimina la causa più comune e più economica da correggere. Il resto — CDN, cache, immagini — viene dopo, non prima.
Il discorso qual è? Che investire in ottimizzazioni avanzate prima di aver pulito il database è come mettere il turbo su un'auto con il filtro dell'aria intasato. Funziona un po' meglio, ma non risolve la causa.
Cosa succede se non pulisce mai il database?
Succede che ogni backup diventa più lento e più costoso. Succede che ogni migrazione del database richiede ore invece di minuti. Succede che il pannello di amministrazione, quello dove lei passa ore ogni giorno, diventa lento prima ancora del sito pubblico.
Un cliente che aveva rimandato la pulizia per due anni ci ha messo 40 minuti solo per aprire la lista ordini nel back office. Quaranta minuti per aprire una pagina che dovrebbe caricarsi in due secondi.
È come avere un magazzino pieno di scatole vuote impilate ovunque. Il commesso più veloce del mondo, in quel magazzino, diventa lento. Non è colpa sua: è colpa dello spazio ingombro.
Come faccio a controllare se il problema è davvero il mio database?
Lo controlla in tre passaggi, senza bisogno di un tecnico esterno.
- Apra phpMyAdmin, o l'equivalente del suo hosting, e ordini le tabelle per dimensione. Se ps_connections o ps_guest sono tra le prime tre, ha già la risposta.
- Controlli il peso totale del database. Sopra i 2-3 gigabyte, per un catalogo sotto le 10.000 referenze, qualcosa non va.
- Guardi da quanto tempo non fa una pulizia. Se la risposta è "mai", non serve altro test.
Perché le dico questo prima di parlare di hosting? Perché cambiare server senza fare questo controllo è come cambiare le gomme a un'auto con il motore sporco. Va un po' meglio, ma il problema resta lì.
Cambiare hosting risolve il problema?
Siamo pessimisti, come faccio sempre nei miei esempi: nel caso peggiore, raddoppia RAM e CPU e guadagna il 10-15% di velocità. Se il suo database ha milioni di righe morte nella tabella delle connessioni, quel 10-15% non le cambia la vita.
Le query lente restano lente, solo su un server più caro. Il primo cliente a cui ho detto "cambi hosting" senza controllare prima il database, ci ha fatto perdere due mesi e 400 euro al mese di canone in più.
Il problema non era il server. Era una tabella di log da 6 milioni di righe che nessuno aveva mai svuotato. Da allora, il database lo controllo sempre per primo, prima di consigliare qualsiasi upgrade di hosting.
Quali risultati porta davvero una pulizia fatta bene?
Un cliente del settore abbigliamento aveva un database da 12 GB, di cui 9 GB erano log di connessione accumulati in tre anni. Dopo la pulizia, la home page è passata da 4,2 secondi a 1,1 secondi di caricamento.
Il tasso di rimbalzo è sceso dal 68% al 51%, nessun cambio di hosting, nessuna modifica al tema. Solo righe morte tolte di mezzo, e query più veloci su tabelle finalmente leggere.
Non le dico che ottiene lo stesso risultato al millimetro, ogni catalogo è diverso. Ma le dico che la direzione è sempre quella: meno righe morte, query più veloci, pagine che si caricano prima.
Cosa faccio prima di chiamare il supporto hosting per lamentarmi della lentezza?
Faccia questo, in ordine, prima di aprire un ticket di supporto.
- Controlli il peso delle tabelle di connessione e sessione.
- Svuoti i carrelli abbandonati più vecchi di 90 giorni.
- Ricostruisca l'indice di ricerca invece di lasciarlo accumulare duplicati.
- Pulisca i log di errore PHP che non le servono più da mesi.
Meglio fatto che perfetto: meglio una pulizia fatta oggi, anche imperfetta, che aspettare il momento giusto per farla bene una volta all'anno. Il database non aspetta lei: cresce ogni giorno, con o senza il suo permesso.
Qual è la soluzione definitiva, non la toppa?
La toppa è entrare ogni tanto e cancellare a mano qualche riga da phpMyAdmin. Funziona, ma dura un mese, poi il database torna a gonfiarsi come prima.
Il discorso qual è, allora? Serve un processo che pulisca in automatico, con una cadenza fissa, senza che lei debba ricordarsene ogni volta che il sito rallenta.
È per questo che abbiamo costruito un modulo che fa esattamente questo. Controlla le tabelle che si sporcano di più, elimina in sicurezza le righe inutili, e lo fa con una frequenza programmata invece che una tantum, quando il sito è già lento. Se vuole capire come funziona un'analisi completa prima ancora di intervenire, può iniziare da un audit del suo e-commerce per vedere dove si concentrano davvero i problemi. Il modulo di pulizia database lo trova qui: https://www.francescoingrosso.com/moduli/pulizia-database/.
Perché questo problema non è tecnico, ma di mentalità?
Perché ti dico questo alla fine e non all'inizio? Perché il vero problema non è il database sporco, è che nessuno lo controlla mai.
Nessuno lo considera un asset da manutenere, come farebbe con la vetrina di un negozio fisico. Un magazzino pieno di scatole vuote rallenta ogni commesso che ci cammina dentro, anche il più veloce del mondo. Il database è lo stesso magazzino, solo digitale.
Non siamo tecnici, e non è un'offesa: è che continuiamo a trattare il sito come una spesa da tagliare, non come un asset da manutenere. Un'ora spesa a pulire il database oggi ne vale cinque domani, quando il sito lento le costa vendite ogni singolo giorno.
Domande frequenti
Quanto deve pesare al massimo un database PrestaShop prima di preoccuparmi?
Per un catalogo sotto le 10.000 referenze, tenga d'occhio la soglia dei 2-3 gigabyte totali. Sopra quella soglia, quasi sempre trova log e connessioni accumulate che nessuno ha mai pulito.
Posso pulire il database da solo o serve un tecnico?
Il controllo iniziale lo fa lei in tre passaggi, direttamente da phpMyAdmin, senza competenze tecniche particolari. La pulizia vera e propria, invece, va fatta con attenzione perché tocca dati live, e per questo conviene un processo automatico e testato.
Ogni quanto tempo devo pulire il database di PrestaShop?
Non una volta l'anno, come fanno quasi tutti. Serve una cadenza fissa, mensile o settimanale a seconda del traffico, perché le tabelle di connessione e sessione si riempiono ogni giorno.
Cambiare hosting prima di pulire il database è del tutto inutile?
Non è inutile in assoluto, ma nel caso peggiore ottiene solo il 10-15% di velocità in più. Se non ha controllato prima il database, rischia di pagare di più per un problema che resta identico.
La pulizia del database rallenta o blocca il mio negozio online?
Se fatta con un processo automatico e testato, no: agisce sulle tabelle giuste, in sicurezza, senza toccare prodotti, ordini o clienti attivi. È il motivo per cui evito interventi manuali improvvisati su siti in produzione.
Se vuole smettere di pensarci ogni volta che il sito rallenta, il modulo di pulizia automatica del database lo trova qui: https://www.francescoingrosso.com/moduli/pulizia-database/. È il primo passo prima di qualunque altra ottimizzazione, e nella mia esperienza è quello che sposta davvero i numeri.
