PrestaShop lento? Come recuperare i Core Web Vitals

Un PrestaShop lento non perde “qualche secondo”: perde ordini, e i Core Web Vitals lo certificano nero su bianco. La lentezza raramente ha una causa sola, ed è per questo che gli interventi a caso (installa un modulo cache e prega) di solito spostano poco. Conviene partire da cosa misura davvero Google e risalire alla causa.

Cosa sono i Core Web Vitals (e cosa misura Google)

I tre indicatori che contano sono LCP (quando compare il contenuto principale, soglia buona sotto 2,5 s), INP (quanto risponde all’interazione, sotto 200 ms) e CLS (quanto “salta” il layout, sotto 0,1). Da marzo 2024 INP ha ufficialmente sostituito il vecchio FID come metrica di reattività: conta ogni interazione, non solo la prima.

Sono dati di campo, non da laboratorio: Google li raccoglie dai browser reali (dataset CrUX) su una finestra di 28 giorni e valuta il 75° percentile. Tradotto: se un 100 su Lighthouse in locale ti tranquillizza ma i tuoi utenti navigano da mobile su rete 4G media, quello che vede Google è tutt’altro numero. Il riferimento ufficiale sono le soglie dei Core Web Vitals su web.dev.

PrestaShop lento: le cause più comuni

• TTFB alto: hosting condiviso o sottodimensionato (un hosting PrestaShop dedicato parte da circa 20-30€/mese), assenza di cache full-page, query non indicizzate. Google considera problematico un TTFB oltre 600 ms; su un catalogo serio punto a stare sotto i 200 ms a pagina cachata.
• LCP lento: immagini prodotto non in formato moderno o senza dimensioni dichiarate. Convertire in WebP taglia il 25-35% del peso rispetto a JPEG, l’AVIF arriva a dimezzarlo.
• CLS: banner cookie, font che caricano tardi, slider che spingono giù il contenuto mentre l’utente sta già leggendo.
• Moduli di troppo: ogni modulo aggiunge CSS e JS, spesso caricati su ogni pagina anche dove non servono. Su PrestaShop 1.7/8 il problema si vede subito nel numero di file aggregati.

Come velocizzare PrestaShop, nell’ordine giusto

L’ordine conta. Per velocizzare PrestaShop parto sempre dal server e dalla cache, perché è lì che si guadagnano i millisecondi che l’utente sente davvero:

1. TTFB   -> cache full-page (LiteSpeed/Varnish) + OPcache + query lente
2. LCP    -> immagini WebP responsive, preload del hero, CDN
3. CLS/INP-> font-display, dimensioni esplicite, JS dei moduli solo dove serve

Sul server, i tre interventi che pagano di più: attivare una cache full-page (LiteSpeed Cache o Varnish davanti a PHP), dimensionare bene OPcache (che da solo può tagliare il tempo di esecuzione PHP del 50-70%), e attivare in produzione CCC (Combine-Compress-Cache) di PrestaShop per aggregare CSS e JS. Solo dopo ha senso lavorare di fino sul tema: preload dell’immagine hero, font-display: swap, width/height espliciti su ogni immagine per azzerare il CLS.

Misuro prima e dopo ogni intervento: senza baseline non sai se hai velocizzato lo shop o solo il grafico.

Quando non basta la cache

Se lo shop resta lento con la cache attiva, il collo di bottiglia è quasi sempre nel database o in un modulo che gira a ogni richiesta. Lì non serve aggiungere layer, serve profilare: attivo il Debug mode di PrestaShop per vedere il numero di query e le più lente, e controllo le tabelle che si gonfiano in silenzio - ps_connections, ps_guest, ps_statssearch, ps_logs. Su cataloghi grandi mancano spesso gli indici giusti e una singola pagina categoria può sparare decine di query non necessarie. La documentazione performance di PrestaShop copre bene la parte di cache e debug.

Gli sprechi che trovo più spesso

Prima di ottimizzare, di solito c’è da togliere. Le zavorre ricorrenti su uno shop lento:

• Moduli morti: installati, mai disinstallati, caricano CSS e JS su ogni pagina.
• Immagini originali a piena risoluzione: 2 MB per una foto che ne mostra 400 px.
• Cache mal configurata o assente: ogni richiesta ricostruisce la pagina da zero.
• Slider e widget di terze parti che bloccano il rendering above-the-fold.
• Query non indicizzate che esplodono quando il catalogo cresce.

Quasi sempre il 20% degli interventi porta l’80% del risultato: si parte da lì.

Con quali strumenti misuro

Non mi fido del punteggio singolo di Lighthouse in locale. Incrocio tre fonti: PageSpeed Insights per il colpo d’occhio field + lab, la sezione Core Web Vitals di Search Console per il trend a livello di sito, e WebPageTest quando serve la cascata richiesta per richiesta. La regola resta una: una modifica alla volta, poi ri-misuro. Così so cosa ha pagato - e tu vedi il prima/dopo in numeri, non in promesse.

Un caso reale: score mobile a 9, e non era il server

Su un e-commerce PrestaShop B2B ho trovato uno score mobile tra 9 e 56, con il server che rispondeva in 70-300ms a cache calda: il problema era interamente front-end. La causa numero uno era un reCAPTCHA caricato in eager su ogni pagina, anche dove non c’era un form, che da solo teneva occupato il main thread per secondi. A ruota: immagini servite a piena risoluzione e ridimensionate via CSS (circa 2MB recuperabili nella sola home), senza width/height dichiarati, con un CLS fino a 0.89; e centinaia di KB tra JavaScript e CSS del tema mai usati.

Il fix ad alto impatto e rischio zero è partito dal togliere il reCAPTCHA di troppo dal tag manager (solo configurazione, nessun deploy), poi lazy-load dei caroselli, immagini in WebP con dimensioni esplicite e spazio riservato ai blocchi che riflowano dopo il caricamento. Il grosso del guadagno arriva da qui: meno JavaScript, non più hardware.

Hai uno shop che arranca?

Se il tuo PrestaShop è lento e non sai da dove partire, lo analizzo e ti dico cosa pesa davvero sui Core Web Vitals e come velocizzarlo - anche senza accessi SSH. Fa parte del mio servizio di assistenza PrestaShop. Hai un caso simile? Scrivimi dai contatti.