Ultimo aggiornamento: giugno 2026.
Quando un negozio PrestaShop sembra lento, la reazione più comune è anche quella più costosa: installare un modulo di cache o ottimizzazione, attivare ogni opzione e sperare. A volte aiuta. Spesso non cambia nulla — e in qualche caso peggiora le cose, perché il vero collo di bottiglia non era mai nel punto in cui il modulo interviene. I problemi di velocità sono prima di tutto problemi di diagnosi. Il consiglio onesto di chi fa questo lavoro per professione è sempre lo stesso: misura prima di ottimizzare. Trova la causa reale, poi investi nella soluzione che la affronta — il che a volte significa non spendere nulla.
Perché andare a tentativi costa così tanto
"Il mio negozio è lento" è un sintomo, non una diagnosi. La causa può trovarsi in diversi punti molto differenti tra loro, e uno strumento che ne risolve uno non fa nulla per gli altri:
- Un singolo modulo che esegue una query N+1 su ogni pagina prodotto — una query extra per ogni elemento in un ciclo, moltiplicata per il tuo catalogo.
- Un tema pesante che carica centinaia di kilobyte di CSS e JavaScript bloccanti per il rendering prima che venga visualizzato qualcosa.
- TTFB (time to first byte) lento da un hosting condiviso sovraccarico o da un server database già al limite di CPU o IO.
- Immagini non ottimizzate — file caricati a piena risoluzione serviti su mobile, nessun formato moderno, dimensioni non corrette.
- Nessuna cache a pagina intera, quindi PrestaShop ricostruisce ogni pagina da zero per ogni visitatore.
- Un’istanza MySQL con poca memoria, che esegue scansioni di tabelle dove dovrebbe esserci un indice.
Ecco la trappola. Se il problema è un tema che blocca il rendering e un TTFB lento, un modulo di cache della pagina può limare qualcosa sulle visite ripetute lasciando intatta la prima impressione — quella che Google misura. Se il problema è un database sovraccarico, nessuna ottimizzazione degli asset front-end sposterà davvero l’ago della bilancia. Puoi continuare a spendere sul livello sbagliato all’infinito senza mai percepire un sito più veloce. Per questo trattiamo un audit delle prestazioni come primo passo: ti dice quale livello ti sta davvero costando tempo, così il prossimo acquisto (se serve) è mirato nel modo giusto.
Cosa misura davvero un audit delle prestazioni
Un audit fatto bene non è un singolo punteggio in un test di velocità. Scompone la pagina nei suoi componenti reali e individua dove va a finire il tempo:
Tempo del server e tempo del browser
La prima distinzione è tra TTFB e rendering front-end. Il TTFB comprende tutto ciò che accade prima che il server invii il primo byte — esecuzione PHP, query al database, letture dalla cache. Il rendering front-end è tutto ciò che il browser fa dopo con la risposta. Una pagina da 3 secondi con 2,4 s di TTFB è un problema back-end; la stessa pagina da 3 secondi con 0,2 s di TTFB e 2,8 s di rendering è un problema front-end. Richiedono soluzioni opposte, e solo la misurazione ti dice quale caso hai davanti.
Query per pagina e principali responsabili
Le pagine PrestaShop possono eseguire da poche decine a diverse centinaia di query SQL. L’audit le conta per tipo di pagina e classifica i peggiori responsabili — spesso un singolo modulo che dovrebbe mettere in cache una lettura, ma rilancia la query a ogni hook. Trovare quella query vale spesso più di qualsiasi quantità di cache aggiunta sopra.
Sovraccarico dei moduli
Ogni modulo agganciato a una pagina aggiunge lavoro, e alcuni si agganciano a ogni pagina anche quando lì non servono. L’audit profila quali moduli contribuiscono in modo significativo al tempo di esecuzione e quali partono inutilmente, così puoi disattivare o sostituire i veri colpevoli invece di tirare a indovinare.
Peso degli asset e cache
Misura il peso totale della pagina, il numero di richieste e quanto bene sono configurati CCC (combine-compress-cache), critical-CSS e il JavaScript differito — oppure se non lo sono affatto. Controlla anche l’intero stack di cache: percentuale di hit della cache a pagina intera, OPcache per il PHP compilato e Redis per la cache di oggetti/query. Una cache che esiste ma fa raramente hit vale quasi nulla, e solo la percentuale di hit lo rivela.
Limiti dell’hosting, mobile e Core Web Vitals
Infine guarda la realtà dell’hardware — margine di CPU, IO e memoria sotto carico — e testa il mobile separatamente dal desktop, perché la maggior parte del traffico e gran parte delle misurazioni di Google sono su mobile. Questo si collega direttamente ai Core Web Vitals: LCP, CLS e INP. Non sono metriche di vanità; sono un vero segnale di ranking, ed è per questo che velocità e ricerca si sovrappongono e un audit SEO tecnico e un audit delle prestazioni fanno emergere così spesso gli stessi problemi.
Un controllo che puoi eseguire in dieci minuti
Non devi ordinare nulla per avere una prima lettura del tuo negozio. Apri la homepage e una pagina prodotto trafficata in Chrome e prova così:
- Esegui una waterfall. Apri DevTools, vai alla scheda Network, fai una ricarica forzata e guarda la primissima richiesta. Il suo tempo "Waiting (TTFB)" ti dice quanta parte è lato server. Oltre ~600 ms su cache calda indica il back-end.
- Conta richieste e peso. Il piè di pagina della scheda Network mostra richieste totali e dimensione trasferita. Centinaia di richieste o diversi megabyte per pagina sono un forte segnale legato ad asset/CCC.
- Leggi il profiler di PrestaShop. Abilita la modalità debug su una copia di staging e attiva il profiler — stampa il conteggio delle query e le query più lente per pagina. Una pagina prodotto con oltre 250 query merita attenzione.
- Applica il throttling mobile. In DevTools, imposta il dispositivo su un profilo mobile di fascia media con throttling "Slow 4G" e ricarica. Se l’esperienza crolla qui, è ciò che prova davvero la maggior parte dei tuoi visitatori.
Questi numeri sono soglie indicative, non garanzie — ogni negozio è diverso. Ma di solito ti porteranno nella zona giusta prima che qualcuno spenda un euro.
Misura il TTFB dalla riga di comando
Se preferisci ottenere un numero preciso sul tempo del server senza aprire DevTools, curl riporta direttamente il dettaglio dei tempi. È in sola lettura — si limita a recuperare la pagina e a stampare quanto è durata ogni fase:
# Print connection, TLS, TTFB and total time for one page load
curl -s -o /dev/null \
-w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\ntotal: %{time_total}s\n" \
https://yourdomain.com/your-product-pageIl numero che conta di più qui è TTFB (time_starttransfer): tutto ciò che accade fino al primo byte della risposta. Eseguilo alcune volte, così una cache fredda non falsifica il risultato. Se quel valore resta alto — ben oltre mezzo secondo su cache calda — il collo di bottiglia è lato server (PHP, query, hosting), e nessuna ottimizzazione degli asset front-end lo risolverà. Se il TTFB è basso ma la pagina sembra comunque lenta nel browser, il costo è invece nel rendering e negli asset. Questa singola distinzione è tutto il motivo per misurare prima di acquistare.
La svolta onesta: cosa ti dice di fare l’audit
Il punto centrale del misurare prima è che il verdetto spesso non è "compra un modulo di ottimizzazione". Un buon audit si conclude con una di queste indicazioni chiare:
- È l’hosting. Se il TTFB è alto anche con cache hit e il server è al limite di CPU/IO, nessun modulo lo risolve — serve un hosting migliore o uno stack ottimizzato, esattamente ciò che un audit dell’hosting definisce.
- È la configurazione. Spesso le cache esistono ma sono configurate male: CCC attivo a metà, OPcache troppo piccola, Redis non davvero collegato. È una modifica di impostazioni, non un acquisto.
- È un modulo o un tema specifico. A volte un singolo modulo pesante o un tema inefficiente è l’intero problema, e la soluzione è sostituirlo o rimuoverlo.
- Hai davvero bisogno di uno strumento. Se il collo di bottiglia sono gli asset front-end e manca la cache a pagina intera, un modulo mirato e a codice aperto come Performance Revolution è l’acquisto giusto — una volta che sai che quello è il livello che ti sta costando, non prima.
- È già tutto a posto. A volte l’audit mostra che il negozio è sano e che la lentezza percepita dipende da un singolo script di terze parti lento o da un problema di rete regionale. Saperlo ti evita di "ottimizzare" qualcosa che non è rotto.
Comprare alla cieca è il modo in cui i negozi finiscono con tre moduli di cache sovrapposti e un sito più lento di quello da cui erano partiti. Diagnosticare prima costa meno, anche quando la diagnosi ha un prezzo, perché ti impedisce di spendere sul livello sbagliato.
Come iniziare
Se vuoi una lettura strutturata invece di un pomeriggio fai-da-te, il nostro audit delle prestazioni è pensato proprio per questo. Inserisci l’URL del tuo negozio, prima viene eseguito un rapido controllo di idoneità in sola lettura — senza consegnare credenziali di amministrazione, consulta le nostre note sulla preparazione all’audit del negozio per vedere come gestiamo l’accesso — e solo dopo l’audit viene ordinato. Si affianca al resto dei nostri servizi specialistici per i casi in cui la soluzione si rivela essere hosting, configurazione o sviluppo invece di un prodotto. Qualunque sia l’esito, saprai perché il negozio è lento prima di spendere per renderlo veloce — ed è questa la parte che fa davvero risparmiare.
Domande frequenti
Ho già installato un modulo di cache. Perché il mio negozio è ancora lento?
Perché la cache aiuta solo il livello su cui opera. Una cache a pagina intera non fa nulla per un primo byte lento su un database sovraccarico, e un ottimizzatore front-end non può correggere un server già al limite della CPU. È anche comune che una cache sia installata ma faccia pochissimi hit — CCC configurato a metà, OPcache troppo piccola, Redis non davvero collegato. La distinzione del TTFB sopra ti dice se il collo di bottiglia si trova persino in un livello su cui la cache può intervenire. Spesso non è così, ed è per questo che il modulo "non ha fatto nulla".
Qual è un TTFB "buono" per PrestaShop?
Come guida approssimativa, sotto ~200 ms è sano, ~200-600 ms è accettabile, e restare costantemente oltre ~600 ms su cache calda indica un problema lato server da approfondire. Sono zone indicative, non linee nette — una pagina prodotto pesante fa legittimamente più lavoro della homepage. Il confronto utile è tra il tuo negozio a freddo e a caldo, e tra il tuo TTFB e il tempo di rendering che il browser aggiunge dopo. È quel rapporto, non un singolo numero, a dirti dove conviene spendere.
Un audit delle prestazioni può garantire che il mio negozio sarà più veloce?
No, e diffida di chiunque lo prometta. Un audit ti dice perché il negozio è lento e quale soluzione affronta il problema — non esegue la correzione né garantisce un numero. Se la causa è l’hosting, l’aumento di velocità dipende dal nuovo stack; se è un modulo pesante, dal fatto che tu possa sostituirlo; se è già tutto a posto, il risultato onesto è "non spendere nulla". Il valore sta nel mirare correttamente la spesa, non in una promessa di millisecondi.
L’audit rallenterà o metterà a rischio il mio negozio in produzione?
No. Il controllo di idoneità e le misurazioni sono in sola lettura — caricano le pagine come farebbe un visitatore e registrano i tempi; nulla viene scritto o modificato. Il passaggio del profiler nel controllo fai-da-te è l’unica cosa che dovresti eseguire su una copia di staging invece che sul sito in produzione, perché la modalità debug espone dettagli interni e aggiunge carico. L’audit vero e proprio non ha bisogno della modalità debug sul tuo sito di produzione.
In cosa è diverso dal semplice uso di PageSpeed Insights?
PageSpeed misura il rendering front-end di un URL e lo valuta rispetto ai Core Web Vitals — è davvero utile, e vale la pena eseguirlo. Quello che non può vedere è il tuo server: numero di query, quale modulo parte a ogni hook, percentuali di hit della cache o se il database è il vero limite. Una pagina può ottenere un buon punteggio su PageSpeed ed essere comunque lenta sotto il carico reale del catalogo, oppure ottenere un punteggio basso per un motivo che un modulo non può correggere. L’audit copre la metà back-end che PageSpeed non vede.
Commenti
Ancora nessun commento. Sii il primo!
Sii il primo a fare una domanda o a condividere un feedback utile.
Lascia un commento
Condividi una domanda, un dettaglio di installazione o un feedback utile per un altro lettore.