Un ecommerce che impiega quattro o cinque secondi a mostrare il prodotto principale non ha solo un problema tecnico: sta rendendo più costoso ogni visitatore acquisito. Chi arriva da Google, da una newsletter o da una campagna già pagata non aspetta che script, immagini e pop-up completino il caricamento. Capire come migliorare PageSpeed di un sito ecommerce significa intervenire sul punto in cui performance, SEO e conversione si incontrano.
Il problema è che il punteggio di PageSpeed viene spesso trattato come un obiettivo estetico: un numero verde da mostrare in report. In realtà, le metriche rilevanti descrivono comportamenti concreti. Quanto velocemente l’utente vede il contenuto utile, quanto resta stabile la pagina mentre carica e quanto presto può interagire con filtri, varianti e carrello. Per un catalogo con migliaia di prodotti, la velocità non dipende da un singolo plugin di cache: dipende dall’architettura complessiva.
Perché PageSpeed incide sulle vendite ecommerce
Una pagina prodotto lenta aumenta l’abbandono prima ancora che il cliente valuti prezzo, recensioni e condizioni di consegna. Lo stesso accade nelle categorie: se immagini, filtri e ordinamenti rispondono con ritardo, la navigazione diventa faticosa e l’utente restringe la ricerca o esce dal sito.
Google considera l’esperienza reale attraverso i Core Web Vitals. Il Largest Contentful Paint, o LCP, misura in quanto tempo appare l’elemento principale visibile, spesso l’immagine hero, il titolo o la foto prodotto. Per una buona esperienza dovrebbe rientrare entro 2,5 secondi. L’Interaction to Next Paint, INP, valuta la reattività alle interazioni e dovrebbe restare sotto 200 millisecondi. Il Cumulative Layout Shift, CLS, misura invece gli spostamenti inattesi degli elementi, con soglia consigliata inferiore a 0,1.
Questi valori non agiscono in isolamento. Un LCP elevato può ridurre la qualità percepita e penalizzare la capacità di una landing di trattenere traffico organico. Un INP alto fa sembrare difettosi il selettore della taglia o il pulsante “aggiungi al carrello”. Un CLS fuori soglia porta l’utente a cliccare nel punto sbagliato perché un banner o un’immagine ha spostato il layout.
Un punteggio alto in ambiente di test non è sufficiente se i dati degli utenti reali raccontano un’altra storia. Un ecommerce va quindi valutato su template rappresentativi – home page, categorie, prodotto, carrello e checkout – e su dispositivi mobili, dove rete e CPU sono più limitate.
Le cause tecniche più frequenti
Un server lento prima ancora del rendering
Il Time to First Byte, o TTFB, è il tempo necessario affinché il server inizi a rispondere. Se è elevato, ogni altra ottimizzazione parte in ritardo. In WordPress il problema può derivare da hosting sovraffollato, PHP non aggiornato, query lente, cache assente o configurata senza distinguere pagine pubbliche e sezioni personali.
L’ecommerce ha una complessità ulteriore: carrello, area riservata e checkout non possono essere messi in cache indiscriminatamente. Serve una configurazione che offra pagine pubbliche veloci senza compromettere sessioni, prezzi dinamici, disponibilità e dati dell’utente. Uno stack con LiteSpeed Enterprise, cache lato server e regole precise per i cookie può ridurre il lavoro richiesto al server, ma non corregge da solo un tema pesante o un database inefficiente.
Immagini prodotto trattate come semplici file decorativi
Le immagini sono spesso il maggiore contributo al peso di una pagina ecommerce. Caricare una foto da 2500 pixel per visualizzarla in una card da 400 pixel spreca banda e rallenta il rendering. La conversione in formati moderni come WebP o AVIF aiuta, ma la sola conversione non basta: occorrono dimensioni corrette, compressione calibrata e immagini responsive erogate in base al dispositivo.
L’immagine LCP merita un trattamento specifico. Se è la foto principale del prodotto o il visual della hero, non va caricata in lazy loading. Deve essere identificabile dal browser con priorità elevata e avere dimensioni dichiarate nel markup. Le immagini sotto la piega, invece, possono essere posticipate. È una distinzione semplice, ma applicata male produce il classico paradosso di un sito “ottimizzato” che mostra tardi il suo contenuto più importante.
Builder, plugin e JavaScript in eccesso
Molti siti accumulano funzioni per stratificazione: un plugin per i pop-up, uno per i filtri, uno per le recensioni, uno per il tracking, uno per una variazione grafica apparentemente minore. Il risultato è un front-end che scarica fogli di stile e script anche dove non servono.
I page builder generalisti possono amplificare il problema generando markup ridondante, CSS globale voluminoso e dipendenze JavaScript non necessarie. Non è una condanna assoluta dello strumento: un sito semplice può funzionare bene anche con una base esistente. Tuttavia, quando il catalogo cresce e le esigenze SEO aumentano, il margine di ottimizzazione si restringe.
Un approccio code-first e una struttura sviluppata su misura permettono di caricare solo i componenti necessari al singolo template. Una funzione di comparazione prodotti, ad esempio, non dovrebbe appesantire il checkout. Uno script per una mappa non dovrebbe comparire su tutte le pagine di categoria. Ridurre il JavaScript non usato migliora sia il tempo di caricamento sia l’INP.
Layout instabile e richieste esterne non governate
Banner promozionali, widget di recensioni, chat, tag di analisi e strumenti di consenso cookie sono cause comuni di CLS e ritardi nell’interazione. Non significa che vadano eliminati a priori. Significa che devono avere uno spazio riservato nel layout, una strategia di caricamento e un’utilità misurabile.
Ogni script di terze parti va valutato con una domanda concreta: contribuisce a vendite, assistenza o misurazione? Se la risposta non è dimostrabile, è un costo tecnico ricorrente. Sul checkout la prudenza deve essere ancora maggiore, perché pochi millisecondi e una cattiva reattività possono incidere nel passaggio più vicino alla conversione.
Come migliorare PageSpeed di un sito ecommerce con un processo corretto
L’ottimizzazione efficace non parte dall’installazione di un plugin, ma da una misurazione iniziale. Prima si raccolgono dati di laboratorio e dati sul campo, poi si individua il template che genera il danno maggiore. Una home page può essere lenta per il visual iniziale, mentre una pagina categoria può dipendere dalle query dei filtri e una pagina prodotto da gallerie, varianti e app esterne.
Il primo intervento riguarda l’infrastruttura: versione PHP, database, cache lato server, CDN quando necessaria, compressione e configurazione delle risorse statiche. Qui l’obiettivo è abbassare il TTFB e garantire tempi consistenti anche nei picchi di traffico. Non sempre una CDN è indispensabile per un pubblico concentrato in un solo Paese, ma diventa utile quando gli utenti sono distribuiti in aree geografiche diverse o i file multimediali sono numerosi.
Il secondo livello riguarda il rendering. Si ottimizzano l’elemento LCP, i font, il CSS critico e l’ordine di caricamento delle risorse. I font, per esempio, possono bloccare la visualizzazione del testo o generare spostamenti se caricati senza una strategia adeguata. Spesso bastano meno pesi tipografici, file locali ben configurati e fallback coerenti per migliorare stabilità e percezione della velocità.
Il terzo livello è l’igiene applicativa: rimozione degli asset inutili, revisione dei plugin, pulizia del database, correzione delle query lente e caricamento condizionale delle funzionalità. È qui che un audit tecnico separa una correzione temporanea da un miglioramento sostenibile. Minimizzare file senza capire cosa li genera può nascondere un problema, non risolverlo.
Infine, si verifica l’impatto sul business. Oltre ai Core Web Vitals, è utile monitorare la velocità delle pagine prodotto, il tasso di aggiunta al carrello, l’avvio del checkout e il completamento dell’ordine. Un tracking avanzato, idealmente con raccolta server-side dove appropriato, permette di collegare un intervento tecnico ai passaggi reali del funnel senza dipendere esclusivamente da segnali incompleti del browser.
Il compromesso da gestire: velocità, funzioni e qualità percepita
Un ecommerce non deve diventare spartano per essere rapido. Foto di qualità, recensioni, video dimostrativi e strumenti di assistenza possono aumentare la fiducia. La domanda corretta non è “possiamo aggiungerlo?”, ma “dove, quando e con quale costo di caricamento?”.
Un video in autoplay nella hero può essere giustificato per un brand che vende design o prodotto premium, ma richiede compressione, poster image efficace e una strategia mobile. Un filtro avanzato è utile per un catalogo ampio, meno per dieci prodotti. Le decisioni devono seguire priorità commerciali e dati d’uso, non checklist standard.
Nel mio approccio, l’analisi parte dai template e dalle metriche che incidono sul percorso di acquisto. L’obiettivo non è inseguire un 100/100 teorico in ogni condizione, ma costruire un sito con codice pulito, infrastruttura adeguata e tempi di risposta verificabili. Questo rende più semplice mantenere le prestazioni quando si aggiungono prodotti, automazioni e nuove funzionalità.
Se il tuo ecommerce registra punteggi instabili, LCP elevato o rallentamenti nelle pagine che vendono di più, un audit performance e SEO può individuare le priorità prima di investire in interventi casuali. La velocità utile non è quella dichiarata da un plugin: è quella che il cliente percepisce mentre decide di acquistare.