PrestaShop con catalogo enorme: come lo tengo in piedi

In sintesi

Quando il catalogo PrestaShop cresce, la manutenzione ordinaria non basta più. Ti spiego come separo i processi pesanti dal negozio, pulisco il database, collego il gestionale senza rischi e ti lascio le chiavi in mano.

Immagina un ipermercato a tre piani. Sabato pomeriggio, pieno di gente. E qualcuno decide di spostare diecimila prodotti da un reparto all'altro proprio adesso.

Corsie bloccate. Code alle casse. Clienti che lasciano il carrello e se ne vanno.

Sul tuo PrestaShop succede la stessa cosa. Basta una sincronizzazione del catalogo lanciata nell'ora sbagliata. Oppure un import di listini, o una rigenerazione degli indici di ricerca a metà pomeriggio.

Con un negozio piccolo non te ne accorgi. Con un catalogo enorme, tante varianti e un gestionale collegato, te ne accorgi eccome. In questo articolo ti spiego come ragiono io quando un progetto PrestaShop diventa grosso.

Il problema quasi mai è l'hosting

Quando il sito rallenta, la reazione è sempre la stessa. «Cambiamo server.» Paghi di più. Per due settimane sembra meglio. Poi torna tutto come prima.

Il motivo è semplice. Se il codice e il database sono organizzati male, un server più grosso li fa girare male più in fretta. Stop.

Nei progetti grossi, i colli di bottiglia sono quasi sempre tre:

un database pieno di dati che non servono più;
un gestionale collegato in modo che il cliente aspetta la risposta dell'ERP;
moduli accumulati negli anni, uno per ogni problema del momento.

Li prendo uno alla volta.

1. Tieni i lavori pesanti lontano dai clienti

Import di listini, aggiornamento prezzi, allineamento delle giacenze. Sono tutte attività pesanti. E non devono mai girare mentre la gente sta comprando.

La regola è una sola. Il negozio serve i clienti. Il lavoro sporco si fa da un'altra parte e in un altro momento.

In pratica:

lancia gli import con script da riga di comando o con cron, non dal pannello mentre il sito è pieno di visitatori;
scegli le fasce orarie in cui hai meno ordini. Guarda i tuoi dati reali, non andare a intuito;
se puoi, separa il server che mostra le pagine da quello che fa i calcoli pesanti di logistica e fatturazione.

Non serve un'architettura da multinazionale. Serve non far litigare i due mondi.

2. Il database va tenuto in ordine

Il database è il cuore del negozio. E nei cataloghi grandi è anche il primo punto dove si strozza tutto.

PrestaShop, di suo, accumula un sacco di roba. Connessioni dei visitatori, statistiche interne, log, carrelli mai trasformati in ordini. Ogni riga pesa poco. Milioni di righe pesano tantissimo.

Mettiamo che il tuo negozio abbia anni di connessioni salvate nelle tabelle interne. Ogni volta che una query deve scorrere quelle tabelle, il sito aspetta. E il cliente aspetta con lui.

Cosa faccio io, di solito:

Svuoto le tabelle di log e statistiche native e sposto il tracciamento su strumenti esterni, come Google Analytics. Non devono pesare sul tuo server.
Controllo gli indici. Una query senza indice giusto scandisce tutta una tabella gigante. Basta un indice al posto giusto per cambiare le cose.
Archivio gli ordini vecchi in un database separato, tenendo in produzione solo quello che serve all'assistenza e alla gestione corrente. Quanti anni tenere lo decidi con il tuo commercialista, non io.
Metto una cache in memoria (Redis o Memcached) così le stesse query non vengono rifatte all'infinito.

Attenzione: prima di toccare qualsiasi cosa, fai una copia completa. Sempre. Poi provi su un ambiente di test, non sul negozio vivo.

3. Il gestionale non deve mai far aspettare il cliente

Questo è l'errore che vedo più spesso. Il cliente clicca «Acquista». Il negozio chiama subito l'ERP per registrare l'ordine. Solo dopo mostra la pagina di conferma.

E se il gestionale è lento? O offline? Il cliente vede una pagina bianca, o un errore. Non sa se ha pagato. Chiude tutto. Magari compra da un altro.

Fermati un attimo. Perché mai la conferma dovrebbe dipendere da un sistema che non controlli?

Il flusso giusto è un altro:

l'ordine viene salvato subito nel database di PrestaShop;
il cliente vede la pagina di conferma, immediata;
una coda prende l'ordine e lo passa all'ERP in background;
se il gestionale non risponde, la coda riprova dopo qualche minuto, senza che nessuno se ne accorga.

Il cliente ha comprato. Il resto è affare tuo e di chi ti segue.

Aggiungi una cosa: un avviso quando la coda si blocca. Un ordine che non arriva al gestionale e nessuno lo sa è peggio di un errore visibile.

4. Meno moduli, più ordine

Ogni modulo che installi porta con sé file JavaScript, fogli di stile e agganci nel codice (gli «hook»). Ognuno aggiunge un piccolo ritardo alla pagina.

Uno o due non li senti. Trenta, sì.

Nei negozi grossi vedo sempre la stessa storia. Un problema, un modulo. Un altro problema, un altro modulo. Dopo qualche anno nessuno sa più cosa fa cosa. E quando ne aggiorni uno, un altro smette di funzionare.

Il mio approccio:

elenco tutti i moduli installati e chiedo per ciascuno: serve ancora? Chi lo usa?
tolgo quelli fermi o doppi;
dove una funzione è importante, preferisco un modulo su misura, leggero, a un modulo generico pieno di cose che non usi;
uso override puliti, senza toccare i file del nucleo di PrestaShop.

Meno codice in giro significa meno conflitti. E meno brutte sorprese il giorno dell'aggiornamento.

5. Le chiavi devono essere tue

Nessun commerciante sano di mente darebbe le chiavi del magazzino e i contratti coi fornitori a un consulente, senza tenerne una copia.

Online, però, succede di continuo. Non hai accesso al server. Non hai il codice. Non sai nemmeno a chi è intestato l'hosting.

Ecco cosa deve essere tuo, sempre:

Il codice. Deve stare in un repository privato (GitHub, GitLab o simili) di cui sei tu l'amministratore. Chi lavora per te lavora su rami separati, e in produzione si va solo dopo un controllo.
Il server. Intestato alla tua azienda, non a chi ti segue. Se cambi fornitore, revochi gli accessi e finisce lì. Nessuna trattativa per riavere i tuoi stessi dati.
I dati. Ordini, clienti, storico degli acquisti. Devi poterli vedere quando vuoi, senza aspettare un PDF a fine mese.

Con me funziona così: accessi tuoi, codice tuo, WhatsApp diretto con me. Nessun ticket, nessun intermediario.

Da dove parti, in pratica

Non devi rifare tutto. Non devi nemmeno capire tutto.

Parti da tre domande secche:

Quando gira il tuo import più pesante? Durante gli orari in cui vendi?
Cosa succede al cliente se il gestionale va offline per dieci minuti?
Hai in mano accessi al server, al codice e ai dati? Tutti e tre?

Se a una di queste non sai rispondere, hai già trovato un punto debole. Ed è meglio trovarlo adesso, con calma, che il giorno del Black Friday.

Vuoi sapere dov'è il tuo collo di bottiglia?

Ogni negozio grosso ha il suo. A volte è il database. A volte è il gestionale. A volte sono i moduli. Indovinare costa tempo e soldi.

Io guardo il tuo PrestaShop, controllo database, moduli e collegamenti con l'ERP, e ti dico dove stai perdendo velocità e vendite. Con numeri tuoi, non con consigli generici.

Richiedi l'analisi del tuo negozio PrestaShop

Frank

Hai un e-commerce PrestaShop che non performa?

Richiedi un'analisi gratuita del tuo sito. Identifico i problemi tecnici e ti propongo un piano d'azione concreto.

Richiedi Analisi Gratuita

Ti sono state utili queste guide? Aggiungici come fonte preferita su Google:

Francesco Ingrosso

15 anni su PrestaShop, 300+ store seguiti. Ingegnere del software: lavoro ogni giorno su e-commerce reali, tra migrazioni, performance e recupero vendite.

Scopri chi sono → LinkedIn