Il tuo negozio sembra lento dal lato visitatore, ma non sai da dove iniziare. La homepage può sembrare corretta, mentre categorie, schede prodotto o carrello si caricano male. In questi casi cambiare impostazioni a caso fa spesso perdere tempo.
La reazione corretta è diagnosticare nell'ordine giusto. Misura prima, poi isola il collo di bottiglia: hosting, moduli, database, immagini, cache o tema. Questo articolo è incentrato sul front-office. Un back-office lento è un altro argomento.
Alla fine saprai cosa controllare, su quali pagine e quando conviene passare dall'osservazione a un intervento tecnico.
Inizia misurando la lentezza, non cambiando impostazioni a caso
Il primo tranello è semplice: attivare una cache, comprimere file o incolpare il tema senza un punto di partenza affidabile. Il 13 ottobre 2026 la documentazione sviluppatori di PrestaShop raccomanda di effettuare benchmark prima di qualsiasi modifica, per avere un riferimento e verificare se i cambiamenti migliorano davvero il negozio: documentazione sviluppatori PrestaShop sull'ottimizzazione.
Questo punto di riferimento deve riguardare il front-office. Se il problema è la velocità lato visitatore, non confondere con problemi di amministrazione o back-office.
Distinguere il punteggio di laboratorio dai dati reali dei visitatori
Un singolo punteggio non indica la causa di un sito lento. Il 13 ottobre 2026 Google spiega il funzionamento di PageSpeed Insights: lo strumento combina dati di laboratorio e dati reali degli utenti. I dati di campo provengono dal Chrome User Experience Report e coprono un periodo mobile di 28 giorni.
Praticamente, i dati di laboratorio servono a riprodurre un problema in un contesto standardizzato. I dati reali mostrano cosa hanno effettivamente vissuto i visitatori nel tempo. Le soglie “Good” ricordate da Google includono LCP ≤ 2,5 s, INP ≤ 200 ms e CLS ≤ 0,1. Se un punteggio è basso, bisogna capire su quale pagina e su quale risorsa il problema si concentra.
Scegliere le pagine da testare: home, categoria, scheda prodotto, carrello
Non testare una sola URL. Prendi almeno una homepage, una pagina categoria, una scheda prodotto e il carrello. Questa scelta evita un falso positivo del tipo “il sito va bene” mentre solo le pagine più redditizie sono lente.
Mantieni la stessa selezione prima e dopo ogni modifica. Annota le metriche che peggiorano davvero e individua se la lentezza colpisce tutto il negozio o solo alcune pagine. Questo ti dirà se guardare prima al server, a un modulo, al database o al tema.
L'hosting e lo stack PHP sono spesso il primo collo di bottiglia
Quando diversi tipi di pagine sono lenti contemporaneamente, il server e lo stack PHP sono spesso da verificare prima di tutto. L'obiettivo non è consigliare un cambio di hosting per principio. Prima isola il collo di bottiglia, poi conferma con una misura.
Se non sai se il problema è server, configurazione PHP o sovraccarico applicativo, mantieni lo stesso metodo: una modifica, poi un benchmark. Senza questa disciplina cambi molte cose senza sapere quale ha migliorato davvero il negozio.
I segnali che indicano un problema di server
Il segnale più utile è una lentezza abbastanza trasversale: homepage, categorie, schede prodotto e carrello si degradano insieme. In questo caso incolpare subito immagini o tema è spesso prematuro.
Altro consiglio pratico: esegui un benchmark prima di modificare l'ambiente. La raccomandazione di PrestaShop vale anche qui. Senza misure prima/dopo puoi adeguare hosting o PHP e poi non riuscire a dire se il problema reale è stato risolto.
Le impostazioni tecniche da verificare su PHP e file
Il 13 ottobre 2026 la documentazione sviluppatori PrestaShop cita due leve precise su PHP e file system: realpath_cache, che evita di ripetere controlli sui file, e OPCache, che memorizza il bytecode PHP compilato in memoria condivisa. Sono punti concreti da verificare prima di concludere che il negozio sia “naturalmente pesante”.
Un errore comune è modificare più parametri contemporaneamente. Fai il contrario: una modifica, un benchmark, poi la validazione. È l'unico modo per sapere se la lentezza dipende dall'ambiente o da un altro livello.
I moduli non sono un problema per il solo numero, ma per ciò che caricano sulle tue pagine
Dire che un sito è lento “perché ci sono troppi moduli” è spesso troppo vago per essere utile. PrestaShop indica che alcuni moduli rallentano il negozio, specialmente se agganciati a pagine critiche del front-office. La vera questione non è solo il numero, ma cosa eseguono, dove lo eseguono e con quale cache.
Gli hook del front-office che costano caro
Inizia dalle pagine che contano di più per i tuoi visitatori: categorie, schede prodotto, carrello. Un modulo collegato a queste aree può pesare molto se carica codice, query o risorse dove non è necessario.
La documentazione utente di PrestaShop 8 ricorda anche che alcune funzionalità possono essere disattivate se non usate, perché possono rallentare il negozio. È un buon criterio di selezione: tutto ciò che resta attivo deve avere un'utilità chiara sulla pagina interessata.
I segnali che un modulo sta davvero rallentando il negozio
Il 13 ottobre 2026 PrestaShop cita diversi segnali utili: consumo eccessivo di risorse, assenza di cache, sovra-cache e modulo attivo su troppe pagine. Questi indizi sono più affidabili del semplice conteggio dei moduli installati.
Se sospetti un modulo specifico, verifica prima il suo perimetro di attivazione e la qualità dell'integrazione. Puoi anche confrontarti con i segnali che aiutano a individuare un modulo PrestaShop mal codificato. L'errore comune è disattivare a caso senza metodo e perdere traccia del vero colpevole.
Il database può rallentare soprattutto le schede prodotto e le categorie
Il database non è il colpevole automatico di un sito PrestaShop lento. Tuttavia diventa una pista credibile quando alcune pagine di business soffrono più di altre. Un caso frequente: la homepage resta accettabile, ma categorie e schede prodotto rallentano.
Quando sospettare il database
Se la lentezza si concentra sulle pagine che interrogano di più il catalogo, le combinazioni, i prezzi o le liste prodotti, il database merita un controllo. Al contrario, se tutte le pagine sono lente allo stesso livello, spesso bisogna guardare più in alto, verso server o moduli.
La buona metodologia resta la stessa: misurare prima, poi isolare. Affermare che il database è per forza in causa perché è “grosso” porta spesso a cattive priorità.
Cosa raccomanda la documentazione PrestaShop prima di un benchmark
Il 13 ottobre 2026 la documentazione sviluppatori PrestaShop raccomanda, se possibile, un innodb_buffer_pool_size maggiore della dimensione del database. Consiglia anche di eseguire un ANALYZE TABLE dopo l'import e prima del benchmark. Questi due punti servono a evitare un test falsato da un ambiente non preparato.
Se il database contiene molti dati inutili, una pulizia controllata può semplificare l'analisi. Il modulo gratuito di pulizia del database PrestaShop può essere un punto di partenza, ma non sostituisce la misurazione prima/dopo.
Le immagini penalizzano soprattutto il LCP quando sono servite male, non solo quando sono pesanti
Ridurre le immagini alla sola compressione è insufficiente. Un'immagine già ottimizzata può comunque rallentare una pagina se viene caricata al momento sbagliato o con priorità errata. Questo è particolarmente vero per la risorsa che impatta il LCP.
Non lazy-loadare l'immagine hero o l'immagine LCP
La raccomandazione di web.dev è chiara: le immagini sotto la piega possono essere lazy-loadate, ma non l'immagine hero o l'immagine LCP sopra la piega. Questa immagine critica deve restare in caricamento eager: guida web.dev su immagini responsive e priorità di caricamento.
È un errore comune nei temi e-commerce: tutto viene messo in lazy loading “per sicurezza”, compresa l'immagine che dovrebbe arrivare prima. Ne risulta che il visitatore aspetta l'elemento principale della pagina quando non dovrebbe mai essere ritardato.
Cosa caricare in differita e cosa lasciare prioritario
Per le immagini veramente secondarie, il lazy loading nativo è un buon punto di partenza nella maggior parte dei casi, anche perché evita di aggiungere una dipendenza JavaScript dedicata: spiegazioni web.dev sul lazy loading nativo delle immagini.
Al contrario, un'immagine realmente critica può ricevere fetchpriority="high", con parsimonia. La parola chiave è parsimonia: se assegni alta priorità a troppe risorse sposti il problema invece di risolverlo.
Cache, tema e piano d'azione: cosa conferma la diagnosi
In PrestaShop, cache e compressione degli asset aiutano, ma non risolvono da sole un'architettura lenta. Il centro assistenza PrestaShop indica che la cache Smarty accelera i tempi servendo una pagina dalla cache nelle visite successive. Ricorda anche che la compressione CSS e JS si imposta nella pagina Performance del negozio.
Il 13 ottobre 2026 la documentazione sviluppatori PrestaShop raccomanda di usare il tipo di cache “File System” e di attivare la cache Smarty. Specifica anche di non attivare la sezione “Cache” se MySQL (<8) o MariaDB gira sulla stessa macchina, perché il query cache di MySQL è ritenuto più efficiente. In altre parole, non tutte le cache vanno attivate ovunque senza test.
Cosa un tema può rompere nel front-office senza essere “brutto” visivamente
Un tema può sembrare corretto dal punto di vista visivo e tuttavia concentrare più cause di lentezza: asset troppo pesanti, JavaScript invasivo, dipendenze inutili, gestione approssimativa delle immagini, compressione mal configurata. Il problema non viene solo dal design, ma da tutto ciò che il tema incorpora e attiva.
Quando analizzi un tema, consideralo come un punto d'incontro tra server, moduli, immagini e cache. Spesso è lì che problemi separati diventano visibili nel front-office.
L'ordine di verifica per decidere se correggere internamente o far intervenire
Ecco l'ordine più utile per mantenere il diagnostic leggibile:
- misurare su più tipi di pagine;
- verificare se la lentezza è globale o concentrata;
- controllare l'ambiente server e PHP;
- isolare i moduli presenti sulle pagine critiche;
- esaminare il database se categorie e schede prodotto soffrono di più;
- correggere la priorità di caricamento delle immagini;
- validare le opzioni di cache e compressione;
- ritestare dopo ogni modifica.
Se le misure restano confuse o se più cause si sommano, fermati al solo diagnostic prima di modificare la produzione. Una serie di piccoli aggiustamenti mal coordinati confonde velocemente l'analisi.
Se vuoi che qualcuno ordini queste cause nell'ordine giusto, KLN-WEB offre un diagnostic per sito PrestaShop lento, focalizzato sul front-office. Ricevi un diagnostic gratuito, una risposta entro 24 h e una tariffa oraria comunicata in anticipo.
Domande frequenti
Come capire se la lentezza dipende dall'hosting o da un modulo PrestaShop?
Comincia misurando più pagine: homepage, categoria, scheda prodotto e carrello. Se tutto è lento in modo uniforme, server o configurazione PHP sono spesso da verificare per primi. Se la lentezza è concentrata su alcune pagine, guarda i moduli attivi su quelle zone, il loro cache e il loro perimetro di esecuzione.
Devo fidarmi del punteggio PageSpeed o dei dati reali dei visitatori?
Devi usare entrambi senza confonderli. Il punteggio di laboratorio aiuta a riprodurre un problema in un contesto standardizzato. I dati reali mostrano cosa hanno sperimentato i visitatori in un periodo mobile di 28 giorni. Un punteggio basso non basta a indicare la causa: serve identificare la pagina colpita e il collo di bottiglia.
Un numero eccessivo di moduli rallenta necessariamente un sito PrestaShop?
No. Il numero da solo non spiega la lentezza. Ciò che pesa davvero è ciò che i moduli caricano sulle pagine critiche del front-office, la qualità del codice, l'uso del cache e la loro presenza su troppe pagine. Pochi moduli mal integrati possono causare più danni di molti moduli ben gestiti.
Un database troppo grande può rallentare il front-office?
Sì, ma non automaticamente. Il database diventa una pista seria quando categorie e schede prodotto sono nettamente più lente della homepage. Bisogna confermare con misure, preparare correttamente il benchmark ed evitare di incolpare il database di default finché server, moduli e tema non sono esclusi.
Perché le mie immagini rallentano ancora il sito anche se sono compresse?
Perché il problema non è sempre il peso. Un'immagine critica può peggiorare il LCP se è lazy-loadata quando invece dovrebbe caricarsi subito, o se la sua priorità di caricamento è gestita male. Al contrario, le immagini sotto la piega possono essere caricate in differita per evitare di ritardare l'essenziale.