Un negozio PrestaShop appena installato è veloce. Poi arrivano i moduli: recensioni, chat, filtri, pixel di tracciamento, cookie, gestionali, marketplace, «ultimi prodotti visti». Ognuno aggiunge qualcosa, e un giorno il negozio non è più quello di prima. Spesso la colpa è di uno o due moduli soltanto: il difficile è scoprire quali. Ecco un metodo pratico.
Come un modulo rallenta il negozio
Un modulo può pesare in modi diversi, e capire quale ti aiuta a cercarlo:
- sul server: interroga il database a ogni pagina, magari con domande pesanti, o chiama servizi esterni lenti mentre la pagina si prepara;
- nel browser: aggiunge script, fogli di stile e caratteri a tutte le pagine, anche dove non serve;
- moltiplicando le richieste: dopo il caricamento la pagina chiede al server altri dati, a volte uno per ogni elemento mostrato;
- sul database nel tempo: accumula dati (statistiche, registri, carrelli abbandonati) in tabelle che crescono senza limite.
Passo 1: misura prima di toccare
Prima di disattivare qualunque cosa, annota come va il negozio oggi: apri le pagine principali (home, categoria, prodotto, carrello) con gli strumenti per sviluppatori del browser (tasto F12, scheda «Rete») e segna due numeri per ciascuna:
- il tempo di attesa della prima risposta del server;
- il numero di richieste e il peso totale della pagina.
Fai la prova da una finestra anonima e ripetila un paio di volte: la prima visita può essere più lenta delle successive. Senza un punto di partenza non saprai se una modifica ha migliorato qualcosa.
Passo 2: lavora su una copia
Disattivare moduli sul negozio aperto significa rischiare carrelli rotti e pagamenti che non funzionano mentre i clienti comprano. Molto meglio una copia di prova in un sottodominio: con Installatron puoi clonare l’installazione, e sulla copia puoi spegnere e riaccendere moduli in tranquillità.
Passo 3: la prova generale
PrestaShop offre, fra le opzioni delle prestazioni, la possibilità di disattivare in un colpo tutti i moduli non nativi e tutti gli override. Sulla copia di prova:
- disattiva i moduli non nativi e misura di nuovo;
- se il negozio diventa molto più veloce, il colpevole è fra i moduli di terze parti;
- se non cambia nulla, guarda altrove: tema, immagini, impostazioni, database.
Ricordati di riattivare tutto alla fine: è un’opzione di diagnosi, non da lasciare accesa.
Passo 4: uno alla volta
Se la prova generale indica i moduli, riattivali a gruppi (ad esempio metà alla volta) e misura dopo ogni gruppo: in pochi passaggi arrivi al modulo responsabile. Parti dai sospetti più probabili:
- moduli che mostrano dati «vivi» in ogni pagina (contatori, ultimi acquisti, prodotti visti);
- filtri e ricerche avanzate su cataloghi grandi;
- moduli che sincronizzano con servizi esterni (gestionali, marketplace, feed);
- moduli che aggiungono script di terze parti a tutte le pagine.
Il profiler di PrestaShop
Per chi ha un po’ di confidenza con i file di configurazione, PrestaShop ha anche uno strumento di profilazione per sviluppatori, che mostra in fondo alla pagina quanto tempo e quante interrogazioni al database ha richiesto ciascun modulo. Si attiva modificando un file di configurazione del negozio, come spiegato nella documentazione per sviluppatori: usalo solo sulla copia di prova, perché mostra informazioni tecniche a chiunque visiti il sito.
Non dimenticare il back office
Alcuni moduli lavorano solo nel back office, e lì possono fare danni sorprendenti. In un caso reale, un modulo che aggiungeva campi personalizzati agli ordini, aprendo la lista ordini, faceva partire una richiesta separata per ogni riga della tabella: decine di richieste nello stesso istante, ognuna impegnativa per il database. Il risultato era che, quando lo staff apriva la lista ordini, rallentava l’intero negozio, anche per i clienti.
Il segnale da cercare: aprendo una pagina del back office, la scheda «Rete» del browser mostra una cascata di richieste tutte uguali. Quando la vedi, hai trovato il modulo da segnalare al suo sviluppatore.
Il caso dei filtri e dei bot
A volte il modulo funziona bene, ma viene usato da qualcuno che non è un cliente. Il modulo dei filtri a faccette ne è l’esempio tipico: ogni combinazione di filtri è un indirizzo diverso che il server deve calcolare da zero, e i bot possono richiederne migliaia. Abbiamo visto negozi in cui gran parte del traffico era fatto di richieste automatiche sui filtri.
Qui disattivare il modulo non è la soluzione. Servono la cache delle pagine sulla rete iWebLab Edge, che con Sentinella (nella versione Pro) serve i bot dalla cache, e i filtri di Security Intelligence contro il traffico malevolo.
Scegliere i moduli in modo più sano
- Meno è meglio: disinstalla, non solo disattiva, i moduli che non usi.
- Fonti ufficiali: le copie «gratuite» di moduli a pagamento trovate in rete sono una via d’ingresso classica per il malware.
- Aggiornati: un modulo fermo da anni è spesso anche lento e insicuro.
- Uno nuovo alla volta: dopo ogni installazione, misura e fai un ordine di prova.
- Leggi dove si aggancia: un modulo che serve solo nel carrello non dovrebbe caricare script in tutto il negozio.
Quando chiederci una mano
Se hai trovato il modulo ma non sai come procedere, o se il negozio è lento e non riesci a capire perché, apri un ticket dall’area clienti. Dal server possiamo vedere quali pagine richiedono più tempo e in quali momenti, e spesso questo basta a indirizzare la ricerca. Ricorda anche che AIweblab Scan e Report analizza il sito e ti consegna un report scritto: un buon punto di partenza per capire dove intervenire.