La velocità di un ecommerce non è una metrica tecnica da guardare ogni tanto: è una variabile che incide direttamente su conversioni, posizionamento SEO e costo per acquisizione cliente. Google considera i Core Web Vitals fattori di ranking dal 2021, con INP che ha sostituito FID nel 2024; nel 2026 restano criteri attivi. Misurare la velocità con strumenti e metriche corrette, e intervenire su ciò che effettivamente la rallenta, è uno dei modi più redditizi per migliorare un ecommerce esistente — molto più di un redesign o di una nuova campagna.
Le metriche che contano davvero
I Core Web Vitals sono il riferimento standard nel 2026. Tre metriche principali:
LCP (Largest Contentful Paint) misura il tempo necessario perché l’elemento più grande visibile nella prima schermata sia completamente caricato. Target: sotto 2,5 secondi (buono); tra 2,5 e 4 secondi (da migliorare); oltre 4 secondi (scarso). È la metrica che misura “quando il sito sembra pronto” per l’utente.
INP (Interaction to Next Paint) misura quanto rapidamente il sito risponde alle interazioni dell’utente (click, tocchi, input). Ha sostituito FID nel 2024. Target: sotto 200 ms (buono); tra 200 e 500 ms (da migliorare); oltre 500 ms (scarso). Misura la reattività del sito.
CLS (Cumulative Layout Shift) misura quanto la pagina “salta” durante il caricamento (elementi che si spostano, pulsanti che cambiano posizione). Target: sotto 0,1 (buono); tra 0,1 e 0,25 (da migliorare); oltre 0,25 (scarso). Una pagina con CLS alto frustra l’utente che cerca di cliccare e ne perde il filo.
A queste si aggiungono metriche complementari: TTFB (Time To First Byte), che misura il tempo di risposta del server prima che inizi il caricamento; FCP (First Contentful Paint), che misura il primo contenuto visibile; TBT (Total Blocking Time), che approssima INP nei test lab. Per il quadro generale dei requisiti di hosting che influiscono su queste metriche, il riferimento è il pillar su hosting per ecommerce: la guida completa alla scelta.
Strumenti per misurare
Esistono due categorie di strumenti che vanno usate insieme.
I field data tools misurano la velocità reale percepita dagli utenti del sito. Google Search Console, nella sezione “Esperienza sulla pagina”, mostra i Core Web Vitals aggregati su tutto il traffico reale dell’ecommerce, distinguendo desktop e mobile. CrUX (Chrome User Experience Report) è la fonte dati di Google, accessibile anche tramite PageSpeed Insights che ne mostra i dati per la pagina specifica. Sono i dati che Google usa effettivamente per il ranking: i più importanti.
I lab data tools misurano la velocità in condizioni controllate, eseguendo un test simulato. Google PageSpeed Insights combina lab data e field data per ogni URL. GTmetrix offre analisi dettagliate con punteggi e raccomandazioni. WebPageTest è lo strumento più avanzato per analisi tecniche approfondite, con la possibilità di testare da location e dispositivi specifici. Lighthouse (integrato in Chrome DevTools) permette audit completi anche di sviluppo locale.
La buona prassi: si usano Search Console e PageSpeed Insights per monitorare la situazione reale, e si usano GTmetrix e WebPageTest per diagnosi puntuali quando emergono problemi. Test ripetuti in orari diversi e da location diverse danno risultati più affidabili di una singola misurazione.
Cosa rallenta davvero un ecommerce
Cinque fronti pesano in modo sproporzionato su prestazioni complessive.
Il primo fronte è l’hosting. Un TTFB sopra i 600 ms è un segnale di server inadeguato. Le ottimizzazioni lato applicazione non possono compensare un server lento: meglio cambiare hosting che cercare di “salvare” un’infrastruttura non adeguata. Per il confronto tra tipologie di hosting in funzione di prestazioni e traffico, c’è l’approfondimento su hosting condiviso, VPS o server dedicato.
Il secondo fronte sono le immagini. Immagini non ottimizzate (formati pesanti come PNG dove andrebbe bene JPG, risoluzioni eccessive per il display effettivo, mancanza di lazy loading) sono la causa più frequente di LCP alto. Le ottimizzazioni: conversione a formato moderni (WebP, AVIF), dimensionamento corretto per il display, lazy loading per immagini sotto la fold, attributi srcset per servire dimensioni diverse a dispositivi diversi. Su un ecommerce con catalogo visivamente pesante, le sole ottimizzazioni immagini possono ridurre il tempo di caricamento del 30-50%.
Il terzo fronte sono script JS e plugin/app. Ogni script caricato sulla pagina aggiunge tempo di download, parsing ed esecuzione. Plugin di marketing (chatbot, popup, pixel di tracking), app di terze parti (recensioni, recommendation engines, live chat), strumenti di analytics si sommano e producono un peso che frena INP e TBT. Le ottimizzazioni: caricamento differito (defer/async) degli script non critici, audit periodico degli script attivi, rimozione di quelli non più usati.
Il quarto fronte è il caching. Caching applicativo (pagine generate dinamicamente vengono salvate come statiche), object caching (Redis/Memcached per le query del database), browser caching (asset statici cached lato utente per visite successive), CDN caching (asset distribuiti su nodi vicini all’utente). Su WooCommerce, plugin come WP Rocket, LiteSpeed Cache o Cache Enabler fanno la differenza. Su PrestaShop, la cache nativa va configurata bene.
Il quinto fronte sono i font web. Font caricati da Google Fonts o da altre fonti esterne possono aggiungere centinaia di millisecondi. Le ottimizzazioni: self-hosting dei font, preload dei font critici, font-display: swap per evitare blocchi di rendering.
Le ottimizzazioni che producono più valore
Per chi ha un ecommerce esistente e vuole intervenire in modo prioritario, cinque interventi producono i miglioramenti più significativi.
Ottimizzazione delle immagini (formato WebP/AVIF, lazy loading, dimensionamento corretto). Riduzione tipica del LCP: 30-50%. Costo di implementazione: basso, alcune ore di lavoro o un plugin dedicato.
Caching applicativo aggressivo (full page caching per le pagine non dinamiche, object cache per le query). Riduzione tipica del TTFB: 40-70%. Costo: configurazione di un plugin o servizio dedicato.
CDN (Content Delivery Network) per servire asset statici da nodi vicini all’utente. Riduzione del LCP e del TTFB su utenti distanti dal server: 20-40%. Quando ha senso e quando no è trattato nell’approfondimento su CDN per ecommerce: quando serve davvero.
Pulizia degli script JS (audit dei plugin/app, rimozione di quelli non usati, defer di quelli non critici). Riduzione di INP e TBT: variabile, spesso 30-50% nei casi di siti carichi di app non ottimizzate.
Upgrade dell’hosting se il TTFB resta alto dopo le ottimizzazioni precedenti. Riduzione del TTFB: spesso il 50% o più, con effetto su tutti i Core Web Vitals.
A questi interventi si aggiunge la manutenzione periodica: aggiornamenti di piattaforma, plugin, tema; pulizia del database (ottimizzazione tabelle, rimozione dati obsoleti); revisione periodica delle metriche per intercettare regressioni.
Domande frequenti
Qual è un valore “buono” di LCP per un ecommerce mobile?
Sotto i 2,5 secondi è considerato buono da Google. Realisticamente, ecommerce ben ottimizzati misurano LCP tra 1,8 e 2,3 secondi su mobile in condizioni reali (Search Console, dati field). Sotto 2 secondi è eccellente, sopra 3 secondi è problematico. Su mobile l’asticella è più alta che su desktop perché la connessione e la potenza del dispositivo sono mediamente inferiori.
Le ottimizzazioni di velocità incidono davvero sulle vendite?
Sì, in modo misurabile. Studi pubblici (Deloitte, Google, Cloudflare) mostrano riduzioni del tasso di conversione tra il 4% e il 10% per ogni secondo aggiuntivo di caricamento sulla mobile experience. Su un ecommerce che fattura 50.000 euro al mese, ridurre LCP da 3,5 a 2,5 secondi può tradursi in 2.000-5.000 euro al mese di fatturato aggiuntivo, senza modifiche al prodotto o al marketing.
Cambiare hosting può davvero risolvere problemi di velocità?
Sì, ma solo se l’hosting era effettivamente il collo di bottiglia (TTFB alto, server lento, mancanza di cache lato server). Se il problema è invece il front-end (immagini non ottimizzate, troppi script), cambiare hosting non risolve. La diagnosi va fatta con strumenti come WebPageTest che mostrano in dettaglio dove si perde tempo. La procedura corretta per migrare hosting senza problemi è trattata in un approfondimento dedicato.
Conviene investire su un developer dedicato per le ottimizzazioni?
Per ecommerce di certo livello (sopra i 30.000-50.000 euro di fatturato mensile) sì, quasi sempre. Le ottimizzazioni di prestazioni hanno ROI alto e durevole: ogni intervento si ripercuote su tutto il traffico per mesi o anni. Per ecommerce più piccoli, le ottimizzazioni “low hanging fruit” (immagini, caching, CDN, audit plugin) si possono fare con plugin e configurazioni standard, senza necessariamente uno sviluppatore dedicato.
