Audit dei moduli PrestaShop: verificare cosa carica ogni modulo su ogni pagina

Perché il bloat dei moduli è il killer silenzioso delle prestazioni di PrestaShop

Ogni negozio PrestaShop parte veloce. Poi installi cinque moduli, dieci moduli, trenta moduli, e improvvisamente la tua homepage impiega quattro secondi per caricarsi. Il colpevole raramente è un singolo modulo massiccio. Piuttosto, sono decine di piccoli moduli che aggiungono ciascuno il proprio file CSS, il proprio file JavaScript e le proprie query al database a ogni singolo caricamento di pagina. Questo peso cumulativo è ciò che chiamiamo bloat dei moduli, ed è la ragione numero uno per cui i negozi PrestaShop diventano lenti nel tempo.

Il problema è che la maggior parte dei proprietari di negozi non verifica mai cosa caricano effettivamente i loro moduli. Installano un modulo per le etichette dei prodotti, un altro per i pulsanti di condivisione social, un altro per un popup newsletter, un altro per l'analytics, e ciascuno si registra silenziosamente su hook come displayHeader e actionFrontControllerSetMedia. Anche se un modulo mostra contenuti solo sulle pagine prodotto, potrebbe comunque caricare i suoi file CSS e JavaScript sulla homepage, sulle pagine categoria, sulla pagina carrello e al checkout. Questo significa che i tuoi clienti scaricano risorse che non utilizzeranno mai su quella particolare pagina.

Un audit corretto dei moduli rivela esattamente cosa contribuisce ogni modulo al peso della tua pagina. Ti dice quali moduli sono i peggiori in termini di impatto, quali caricano risorse inutilmente e quali puoi ottimizzare o rimuovere completamente. Questo articolo ti guida attraverso il processo completo di audit dei tuoi moduli PrestaShop per le prestazioni, utilizzando i DevTools del browser, la modalità debug di PrestaShop e un'analisi sistematica.

Passaggio 1: Abilitare la modalità debug e il profiling delle prestazioni di PrestaShop

Prima di aprire gli strumenti del browser, devi abilitare le funzionalità di profiling integrate in PrestaShop. PrestaShop ha una modalità debug che rivela informazioni dettagliate sull'esecuzione degli hook, i tempi di caricamento dei moduli e le query al database. Per abilitarla, devi modificare due impostazioni.

Per prima cosa, vai su Parametri Avanzati, quindi Prestazioni nel tuo back office. Imposta la Modalità Debug su Sì. Questo abilita la segnalazione degli errori e il logging aggiuntivo che aiuta a identificare i moduli problematici. Tuttavia, la vera potenza viene dalla funzionalità di profiling.

Per abilitare il profiling completo, devi modificare il file defines.inc.php situato nella directory config di PrestaShop. Trova la riga che definisce _PS_DEBUG_PROFILING_ e impostala su true. In PrestaShop 1.7 e 8.x, questa costante controlla se la barra di profiling appare nella parte inferiore di ogni pagina del front office. Una volta abilitata, ricarica qualsiasi pagina del tuo negozio e vedrai un pannello di profiling dettagliato che mostra i tempi di esecuzione per ogni hook, ogni modulo e ogni query SQL.

Il pannello di profiling è diviso in diverse sezioni. La sezione hook mostra ogni hook che è stato eseguito sulla pagina corrente, quali moduli sono collegati a ogni hook e quanto tempo ha impiegato ogni modulo per l'esecuzione. La sezione SQL mostra ogni query al database, il suo tempo di esecuzione e quale modulo o funzione core l'ha generata. La sezione moduli fornisce un riepilogo del tempo di esecuzione totale per modulo su tutti gli hook.

Presta particolare attenzione alla colonna del tempo di esecuzione totale. Un modulo ben ottimizzato dovrebbe contribuire meno di 10 millisecondi al caricamento di una pagina. Se vedi un modulo che impiega 50, 100 o addirittura 500 millisecondi, si tratta di un serio problema di prestazioni che necessita di indagine.

Passaggio 2: Utilizzare i DevTools del browser per mappare le risorse dei moduli

Il profiling integrato di PrestaShop ti informa sulle prestazioni lato server, ma non ti mostra il quadro completo di ciò che accade nel browser. Per questo, hai bisogno degli Strumenti per sviluppatori del tuo browser. Apri Chrome o Firefox, premi F12 e vai alla scheda Network.

Ricarica la tua homepage con la scheda Network aperta. Vedrai ogni richiesta effettuata dal browser: HTML, file CSS, file JavaScript, immagini, font e chiamate AJAX. L'obiettivo è identificare quali di queste richieste provengono dai moduli.

In PrestaShop, le risorse dei moduli seguono un pattern URL prevedibile. I file CSS dei moduli sono generalmente serviti da percorsi come /modules/nomemodulo/views/css/nomefile.css o /modules/nomemodulo/css/nomefile.css. I file JavaScript seguono lo stesso pattern con js al posto di css. Usa la barra filtro nella scheda Network per filtrare per "modules/" e vedrai istantaneamente ogni risorsa caricata dai tuoi moduli installati.

Per ogni risorsa di modulo trovata, annota le seguenti informazioni: il nome del file, la sua dimensione (sia trasferita che non compressa) e se viene caricata sul tipo di pagina corrente. Vuoi costruire un foglio di calcolo o un semplice elenco che mappi ogni modulo alle sue risorse. Un audit tipico potrebbe rivelare qualcosa del genere: il modulo A carica due file CSS per un totale di 45 KB e un file JavaScript di 120 KB su ogni pagina, ma mostra contenuti solo sulle pagine prodotto. Questo significa che le pagine categoria, la homepage e il carrello stanno caricando 165 KB di risorse inutili.

La scheda Network mostra anche la vista waterfall, che rivela quando ogni risorsa inizia a caricarsi e quanto tempo impiega. Le risorse che bloccano il rendering (CSS render-blocking e JavaScript sincrono) sono particolarmente dannose perché impediscono al browser di visualizzare qualsiasi contenuto fino al completamento del loro caricamento. Cerca file JavaScript dei moduli che si caricano nell'head senza attributi async o defer, poiché sono i peggiori colpevoli per il tempo di caricamento percepito.

Passaggio 3: Analizzare il waterfall di rete per modulo

La vista waterfall nei DevTools merita una sezione dedicata perché rivela problemi di prestazioni che le dimensioni grezze dei file non mostrano. Quando osservi il waterfall, vuoi identificare tre tipi di problemi.

Primo, cerca risorse render-blocking provenienti dai moduli. Queste appaiono come barre che iniziano presto nel waterfall e ritardano l'evento first paint (la linea verticale verde o blu). In PrestaShop, i file CSS aggiunti tramite l'hook displayHeader o attraverso addCSS in setMedia sono generalmente render-blocking. Se un modulo aggiunge un file CSS grande che è necessario solo su pagine specifiche, blocca il rendering su ogni pagina senza motivo.

Secondo, cerca catene di caricamento sequenziale. Alcuni moduli caricano un file JavaScript che poi attiva il caricamento di risorse aggiuntive: altri file JavaScript, file CSS, web font o chiamate API esterne. Ogni anello di questa catena aggiunge latenza. Un modulo che carica jQuery UI, poi un tema CSS di jQuery UI, poi uno script widget personalizzato, poi il CSS del widget crea una catena di quattro richieste sequenziali che potrebbe richiedere da 200 a 400 millisecondi anche su una connessione veloce.

Terzo, cerca richieste esterne. Alcuni moduli effettuano chiamate a server esterni per analytics, tracking, caricamento font, widget di social media o dati API. Queste richieste sono particolarmente pericolose perché non hai alcun controllo sul tempo di risposta del server esterno. Un modulo di condivisione social che chiama le API di Facebook, Twitter e Pinterest a ogni caricamento di pagina può aggiungere 500 millisecondi o più di latenza, e se uno qualsiasi di quei server è lento o irraggiungibile, può bloccare l'intera pagina dal completamento del caricamento.

Per quantificare l'impatto per modulo, usa la funzionalità di blocco dei Chrome DevTools. Fai clic destro su una richiesta da un modulo specifico e scegli "Block request domain" o "Block request URL." Poi ricarica la pagina e confronta il tempo di caricamento. Questo ti dà una misura diretta di quanto le risorse di quel modulo contribuiscono al tuo tempo di caricamento totale della pagina. Ripeti per ogni modulo per costruire una classifica dal più pesante al più leggero.

Passaggio 4: Analisi dell'esecuzione degli hook

Capire quali hook utilizza ogni modulo è fondamentale per identificare il caricamento non necessario. Il sistema di hook di PrestaShop è il meccanismo attraverso cui i moduli iniettano contenuti, risorse e logica nelle pagine. Gli hook più rilevanti per le prestazioni delle pagine front office sono displayHeader, actionFrontControllerSetMedia, displayTop, displayHome, displayFooter, displayProductAdditionalInfo e displayProductListFunctionalButtons.

L'hook displayHeader è l'hook più comunemente abusato nell'ecosistema PrestaShop. I moduli si registrano su questo hook per aggiungere i propri CSS e JavaScript nell'head della pagina. Il problema è che displayHeader viene eseguito su ogni singola pagina del front office. Se un modulo si registra su displayHeader senza verificare quale pagina sta visualizzando il cliente, carica le sue risorse ovunque.

Per vedere quali moduli sono registrati su ogni hook, vai su Design, quindi Posizioni nel tuo back office. Questa pagina mostra ogni hook e ogni modulo collegato ad esso. Cerca specificamente displayHeader e actionFrontControllerSetMedia. Conta quanti moduli sono registrati lì. In un negozio tipico con 30 o più moduli installati, potresti trovare da 15 a 20 moduli solo su displayHeader. Ognuno di essi aggiunge almeno un file CSS o JavaScript a ogni pagina.

Ora incrocia questi dati con le tue scoperte nei DevTools. Per ogni modulo su displayHeader, verifica se quel modulo ha effettivamente bisogno di caricarsi sulla pagina corrente. Un modulo di recensioni prodotto ha bisogno delle sue risorse solo sulle pagine prodotto. Un modulo lista desideri ha bisogno delle sue risorse solo sulle pagine prodotto e account. Un modulo guida taglie ha bisogno delle sue risorse solo sulle pagine prodotto. Eppure tutti si caricano sulla tua homepage, sulle tue pagine categoria, sulle tue pagine CMS e al tuo checkout.

I dati di profiling dal Passaggio 1 aggiungono un'altra dimensione a questa analisi. Alcuni moduli non solo caricano risorse non necessarie ma eseguono anche codice PHP costoso a ogni chiamata hook. Un modulo che esegue query al database nel suo metodo hookDisplayHeader per controllare valori di configurazione o recuperare dati sta sprecando risorse del server su ogni pagina, anche quando il suo output non è necessario.

Passaggio 5: Identificare i moduli più pesanti

Con i dati dal profiling, dai DevTools e dall'analisi degli hook, puoi ora classificare i tuoi moduli per il loro impatto sulle prestazioni. Crea un elenco con le seguenti colonne: nome del modulo, numero di file CSS caricati, dimensione totale CSS, numero di file JavaScript caricati, dimensione totale JavaScript, tempo di esecuzione server dal profiling, numero di query al database e pagine dove il modulo visualizza effettivamente contenuti.

I moduli che ottengono il punteggio più alto su queste metriche sono i tuoi peggiori offensori. Nella nostra esperienza di audit di centinaia di negozi PrestaShop, le seguenti categorie di moduli sono costantemente le meno performanti.

I moduli page builder sono spesso i più pesanti. Caricano framework CSS di grandi dimensioni, multiple librerie JavaScript per il loro editor visuale e talvolta caricano persino le risorse dell'editor sul front office. Un page builder che carica 300 KB di CSS e 500 KB di JavaScript su ogni pagina non è insolito.

I moduli di social media che incorporano widget da Facebook, Instagram o Twitter caricano script esterni che sono sia grandi sia imprevedibili nei tempi di caricamento. Un singolo widget feed Instagram può aggiungere 1 MB o più di JavaScript alla tua pagina.

I moduli di analytics e tracking che utilizzano pixel di tracciamento multipli caricano script da domini esterni. Ogni pixel di tracciamento aggiunge tipicamente da 20 a 50 KB di JavaScript più richieste di rete aggiuntive per immagini pixel e chiamate API.

I moduli slider e carosello caricano librerie JavaScript di grandi dimensioni come Slick, Owl Carousel o Swiper insieme ai loro CSS. Anche se lo slider appare solo sulla homepage, le risorse spesso si caricano su ogni pagina.

I moduli di live chat caricano bundle JavaScript sostanziosi per l'interfaccia del widget chat, tipicamente da 100 a 300 KB, più stabiliscono connessioni WebSocket che consumano risorse per tutta la sessione di navigazione.

Passaggio 6: Misurare le prestazioni prima e dopo

Prima di iniziare a disabilitare hook o rimuovere moduli, stabilisci una misurazione di base. Usa molteplici strumenti per ottenere un quadro completo.

In Chrome DevTools, vai alla scheda Lighthouse ed esegui un audit delle prestazioni. Registra il Performance Score, First Contentful Paint (FCP), Largest Contentful Paint (LCP), Total Blocking Time (TBT) e Cumulative Layout Shift (CLS). Esegui l'audit tre volte e calcola la media dei risultati per tenere conto della variabilità.

Usa la scheda Performance nei DevTools per registrare una traccia di caricamento della pagina. Questo ti fornisce un flame chart che mostra esattamente cosa sta facendo il browser in ogni millisecondo. Cerca le long task (blocchi più lunghi di 50 millisecondi) e identifica quali script dei moduli le causano.

Misura anche il peso della tua pagina. Nella scheda Network, osserva il numero totale di richieste e la dimensione totale trasferita nella parte inferiore del pannello. Filtra per CSS e JS separatamente per ottenere i totali specifici dei moduli.

Registra tutti questi numeri prima di apportare qualsiasi modifica. Poi, man mano che ottimizzi i moduli scollegandoli dagli hook non necessari o disabilitandoli completamente, riesegui le stesse misurazioni. La differenza ti dice esattamente quante prestazioni hai guadagnato da ogni modifica.

Un audit dei moduli ben eseguito tipicamente riduce il peso della pagina dal 30 al 50 percento e migliora i tempi di caricamento da uno a due secondi. Nei negozi con molti moduli scarsamente ottimizzati, il miglioramento può essere ancora più significativo.

Passaggio 7: Disabilitare gli hook non necessari

Una volta identificato quali moduli caricano risorse su pagine dove non sono necessari, hai diverse opzioni per l'ottimizzazione. L'approccio più semplice è scollegare i moduli dagli hook dove non hanno bisogno di essere presenti.

Vai su Design, quindi Posizioni nel tuo back office. Trova il modulo sull'hook da cui vuoi rimuoverlo. Clicca sull'icona cestino o sul pulsante di sgancio per rimuovere il modulo da quello specifico hook. Questo impedisce al modulo di eseguirsi su quell'hook completamente.

Tuttavia, fai attenzione con questo approccio. Alcuni moduli usano displayHeader non solo per caricare CSS e JavaScript ma anche per eseguire attività di inizializzazione essenziali. Scollegare un tale modulo da displayHeader potrebbe comprometterne la funzionalità sulle pagine dove è effettivamente necessario. Testa sempre su un ambiente di staging o come minimo verifica le pagine specifiche dove il modulo dovrebbe ancora funzionare dopo lo sgancio.

Un approccio migliore a lungo termine è contattare lo sviluppatore del modulo e richiedere il caricamento condizionale delle risorse. Un modulo ben programmato dovrebbe verificare il controller corrente o il tipo di pagina prima di caricare le sue risorse. Ad esempio, un modulo di recensioni prodotto dovrebbe caricare i suoi CSS e JavaScript solo quando il controller corrente è ProductController. In questo modo, il modulo resta agganciato a displayHeader per compatibilità ma carica le risorse solo quando sono effettivamente necessarie.

Se ti senti a tuo agio a modificare il codice dei moduli, puoi aggiungere tu stesso i controlli condizionali. Nel metodo hookDisplayHeader o hookActionFrontControllerSetMedia del modulo, aggiungi un controllo per il nome del controller corrente. Se il controller non è uno di quelli dove il modulo visualizza contenuti, ritorna anticipatamente senza aggiungere alcuna risorsa. Questa è l'ottimizzazione più mirata ed efficace che puoi fare.

Checklist pratica per il tuo audit dei moduli

Per riassumere l'intero processo di audit, ecco una checklist pratica che puoi seguire. Inizia abilitando il profiling debug di PrestaShop. Apri la scheda Network dei DevTools e ricarica la tua homepage. Filtra le richieste per il percorso dei moduli ed elenca ogni risorsa dei moduli. Annota la dimensione e il tipo di ogni risorsa. Controlla Design, quindi Posizioni per i moduli su displayHeader. Incrocia le registrazioni degli hook con dove i moduli visualizzano effettivamente contenuti. Usa il blocco richieste dei DevTools per misurare l'impatto per modulo. Registra i punteggi Lighthouse di base. Scollega i moduli dagli hook dove non sono necessari. Aggiungi il caricamento condizionale ai moduli che si caricano globalmente. Rimisura i punteggi Lighthouse dopo ogni modifica. Documenta le tue scoperte e le modifiche per riferimento futuro.

Questo approccio sistematico garantisce di non perdere alcuna opportunità di ottimizzazione e ti fornisce dati concreti per giustificare ogni modifica apportata. Il bloat dei moduli non è un mistero. È un problema misurabile e risolvibile, e ogni negozio PrestaShop trae beneficio da un audit approfondito dei moduli almeno una volta all'anno.