Catalogo X5 pesante: limite? 
Auteur : Dario B.Buongiorno,
apro questa discussione perché sto lavorando al mio ecommerce (www.blancatogp.com) e il catalogo è arrivato a circa 1.300 prodotti.
Il sito funziona, ma analizzando i file generati online ho notato alcuni dati che mi fanno riflettere sulla scalabilità futura del motore ecommerce, soprattutto se il catalogo dovesse crescere verso 3.000 / 5.000 prodotti.
Nel mio caso rilevo indicativamente:
- /cart/x5cart.js: circa 7,5 MB
- /cart/x5cart.php: oltre 36 MB
- /res/x5settings.php: oltre 36 MB
Il problema non sembra essere il singolo warning relativo a Lit, che nel mio caso riguarda un file molto piccolo, ma il modo in cui vengono gestiti e caricati i dati ecommerce.
Analizzando x5cart.js, sembra che venga generato un grande oggetto x5CartData contenente molti dati del catalogo: prodotti, prezzi, descrizioni, immagini, link, dati galleria/showbox, dati strutturati e varie informazioni ripetute.
Il problema non è il peso nominale del singolo asset, ma l’accoppiamento strutturale tra business logic, presentation template e dataset catalogo dentro un unico payload monolitico, che impedisce code splitting, lazy hydration, cache invalidation granulare e caricamento contestuale dei dati.
Con cataloghi piccoli questo approccio può essere accettabile, ma con cataloghi medio-grandi temo possa diventare un limite importante, sia lato browser sia lato server.
Il punto, secondo me, è ancora più delicato perché le schede prodotto non sono normali pagine HTML modificabili liberamente, ma vengono generate dal motore ecommerce di WebSite X5 tramite URL del tipo:
/product/?nome-prodotto
Quindi l’utente non può realmente alleggerire la singola scheda prodotto come farebbe con una pagina standard. È il motore ecommerce che dovrebbe caricare o generare solo i dati necessari al prodotto corrente.
A mio avviso sarebbe utile valutare una revisione graduale dell’export ecommerce, senza dover riscrivere tutto il software.
Per esempio:
- separare la logica del carrello dai dati del catalogo;
- alleggerire x5cart.js lasciando nel file principale solo i dati essenziali;
- evitare nella build online dati non necessari alla pubblicazione;
- spostare template HTML/JS ripetuti in funzioni comuni;
- introdurre un piccolo manifest del catalogo;
- suddividere i dati prodotto per categoria o blocchi;
- caricare nella scheda prodotto solo i dati del prodotto corrente;
- caricare nella categoria solo i dati della categoria corrente;
- caricare nel carrello solo i prodotti effettivamente presenti;
- modularizzare anche i file PHP oggi molto grandi;
- caricare script esterni pesanti, come reCAPTCHA, solo dove servono realmente.
Non lo scrivo come critica sterile, ma perché uso WebSite X5 da anni e vorrei continuare a far crescere il mio ecommerce con questo software.
Secondo me il tema è importante: un catalogo da 1.300 prodotti è già una realtà concreta, non un caso estremo. E se il sistema cresce in modo quasi lineare, un catalogo da 5.000 prodotti potrebbe diventare molto difficile da gestire.
Chiedo quindi a Incomedia e agli altri utenti:
- avete esperienze con cataloghi ecommerce da 1.000 prodotti in su?
- sono previsti interventi per rendere il motore ecommerce più modulare e scalabile?
Posso fornire ulteriori dati e misurazioni se utili al team di sviluppo.
Buongiorno,
grazie per le osservazioni e i feedback.
Il sistema di e-commerce di WebSite X5 è in effetti più ottimale per cataloghi di dimensioni non elevatissime, a seconda anche della densità di contenuti dei prodotti e della loro suddivisione in categorie, e cercheremo di lavorare per migliorare i suoi meccanismi e snellirlo.
Lo scorporamento di HTML e JS in template è già avvenuto con le modifiche avvenute per le card nella versione 2024.4, e abbiamo in progetto di lavorare alla modularizzazione del PHP, prenderemo in considerazione anche gli altri punti esposti per valutarne la futura implementazione.
È una problematica già evidenziata tempo fa, ma che ad oggi sembra ancora priva di un effettivo rimedio.
Ritengo vi siano limiti strutturali che, con ogni probabilità, difficilmente verranno superati, al di là di dichiarazioni d’intenti che, nella pratica, finiscono per ricordare la celebre canzone di Mina e Alberto Lupo.
Auteur
Grazie Eric per il riscontro.
La modularizzazione del PHP è sicuramente positiva. Mi permetto però di evidenziare che, nel mio caso, il problema riguarda anche il frontend: /cart/x5cart.js viene caricato anche in homepage e contiene comunque l’intero dataset ecommerce, arrivando a circa 7,5 MB decoded.
Attualmente sono in fase di ottimizzazione del sito e sto portando avanti anche altri progetti imprenditoriali, ma a breve dovrò tornare a espandere l’ecommerce. Ho già in programma di superare i 2.000 prodotti, quindi devo iniziare a ragionare ora sulla scalabilità futura.
Sarebbe utile capire se, oltre alla modularizzazione PHP, è prevista anche una futura separazione tra core del carrello e dati catalogo, con caricamento solo dei dati necessari alla pagina corrente.
Buongiorno Dario,
al momento non ci sono previsioni sull'integrazione degli altri aspetti menzionati, ma sono in corso valutazioni su questi miglioramenti.