Un sito che impiega 3 secondi a caricarsi su mobile perde circa il 53% dei visitatori da dispositivo mobile prima che il contenuto dei prodotti sia visibile (secondo i dati pubblicati da Google sulle soglie di abbandono mobile).
Tra chi rimane, ogni secondo aggiuntivo di caricamento correla con una diminuzione delle conversioni nell'ordine del 7%, su molteplici studi nel settore commerce (Akamai, Google, Portent). Per uno store con €10.000 al mese di fatturato, questo significa €700 al mese persi per ogni secondo in più di caricamento.
Nessun altro tipo di sito web ha altrettanto da perdere per le prestazioni scadenti, e altrettanto da guadagnare nel risolverle, quanto uno store ecommerce.
I Numeri Dietro la Velocità
Il legame tra velocità delle pagine e fatturato è stato studiato in modo approfondito. I risultati sono coerenti tra settori e periodi temporali diversi:
| Studio / Fonte | Risultato |
|---|---|
| Google / Deloitte (2019) | 0,1 secondi di miglioramento → +8% nel tasso di conversione su mobile |
| Amazon (interno) | Ogni 100ms di ritardo = 1% di fatturato perso |
| Walmart (interno) | 1 secondo di miglioramento → +2% nelle conversioni |
| Portent (2019) | I siti che si caricano in 1 secondo convertono 3 volte meglio di quelli che impiegano 5 secondi |
Non si tratta di risultati isolati ottenuti in condizioni favorevoli. Provengono da dati reali su larga scala, attraverso milioni di transazioni. La direzione è sempre la stessa: più veloce equivale a più fatturato.
Perché l'Ecommerce Mobile è Diverso
Oltre il 70% del traffico ecommerce proviene ora da dispositivi mobile. Eppure il mobile converte attorno al 2%, rispetto a circa il 4% su desktop. Questo divario, che rappresenta miliardi di fatturato non realizzato in tutto il settore, è spiegato in larga parte da velocità e usabilità su mobile.
Le connessioni mobile non sono uniformi. La copertura 4G è discontinua, in particolare nelle aree rurali. I dispositivi Android di fascia bassa, che rappresentano una quota rilevante del mercato, hanno processori più lenti che faticano con le pagine ricche di JavaScript. Una pagina prodotto che si carica in modo accettabile su un nuovo iPhone in centro città può risultare di fatto inutilizzabile per una parte significativa dei clienti reali.
Anche il modello di interazione è diverso. La navigazione con il pollice, le aree di tocco ridotte e i moduli di checkout pensati per desktop aggiungono attrito. Quando questo attrito si somma a una pagina lenta, i tassi di abbandono crescono rapidamente.
- Oltre il 70% del traffico ecommerce è su mobile, ma il mobile converte a circa la metà del tasso desktop
- Le connessioni 4G variano significativamente per posizione e qualità del dispositivo
- I dispositivi di fascia bassa rappresentano una quota rilevante degli utenti reali, non solo casi limite
- L'attrito in fase di checkout su mobile è amplificato quando la pagina risponde con lentezza
Core Web Vitals e Cosa Significano per il Suo Store
Google misura le prestazioni dei siti attraverso un insieme di metriche chiamate Core Web Vitals. Ognuna corrisponde direttamente a qualcosa che i Suoi clienti sperimentano durante gli acquisti:
| Metrica | Cosa Misura | Rilevanza Ecommerce | Buono | Da Migliorare | Insufficiente |
|---|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Quanto tempo prima che il contenuto principale sia visibile | L'immagine hero del prodotto o il banner in evidenza | Sotto 2,5s | 2,5s-4s | Oltre 4s |
| INP (Interaction to Next Paint) | Con quale velocità la pagina risponde a clic e tocchi | Pulsante aggiungi al carrello, selezione filtri, modifica quantità | Sotto 200ms | 200ms-500ms | Oltre 500ms |
| CLS (Cumulative Layout Shift) | Quanto si sposta la pagina durante il caricamento | Le schede prodotto che si spostano mentre le immagini si caricano | Sotto 0,1 | 0,1-0,25 | Oltre 0,25 |
I siti che ottengono verde su tutti e tre i Core Web Vitals ricevono un incremento nel posizionamento sui risultati di ricerca Google. Quelli che non li superano vengono penalizzati. Un sito lento viene quindi penalizzato due volte: minore visibilità organica e tassi di conversione più bassi sul traffico che comunque arriva.
Un punteggio INP insufficiente su un sito ecommerce è particolarmente dannoso. Se un cliente tocca "Aggiungi al carrello" e non accade nulla per mezzo secondo, molti toccheranno di nuovo oppure riterranno il sito difettoso e abbandoneranno.
WooCommerce e il Problema dei Plugin
WooCommerce alimenta una quota rilevante degli store ecommerce ed è anche una delle piattaforme con le maggiori sfide prestazionali su larga scala. Uno store WooCommerce funzionante esegue tipicamente 50-80 plugin. Ognuno aggiunge richieste HTTP, tempo di esecuzione JavaScript e overhead CSS.
Il risultato a livello di pagina:
- Le pagine prodotto trasferiscono tipicamente 4-8 MB di dati al primo caricamento
- Una pagina prodotto WooCommerce standard può generare oltre 100 query al database
- I bundle JavaScript di più plugin bloccano spesso il rendering
- Gli script di terze parti (recensioni, live chat, analytics) aggiungono ulteriori catene di richieste
- L'LCP di WooCommerce su mobile si attesta tipicamente tra 4 e 6 secondi negli audit webvise; i risultati variano in base al tema e alla selezione dei plugin.
Il range 4-6 secondi è ampiamente nella zona "insufficiente" secondo la scala di Google e ben oltre la soglia di abbandono per la maggior parte degli utenti mobile. I plugin di caching aiutano a ridurre il sintomo, ma non modificano l'architettura sottostante che genera il problema.
Il problema delle query al database è strutturale. WooCommerce costruisce le pagine prodotto dinamicamente a ogni richiesta, estraendo dal database dati di prodotto, regole di prezzo, stato dell'inventario, prodotti correlati e stato del carrello ogni volta. Con oltre 100 query per caricamento di pagina, anche un hosting veloce ha un limite invalicabile.
Come Appare uno Stack Ecommerce Ottimizzato per le Prestazioni
Un'architettura headless commerce separa il frontend, ciò che i clienti vedono e con cui interagiscono, dal backend commerce che gestisce prodotti, inventario e ordini. Il frontend è costruito in Next.js e pre-renderizzato a build time. Il backend (Shopify, BigCommerce o WooCommerce headless) gestisce le transazioni via API.
La differenza prestazionale è strutturale, non estetica:
- Pagine prodotto statiche/ISR: pre-renderizzate a build time e servite direttamente dall'edge CDN, senza PHP né query al database al caricamento
- Immagini prodotto lazy-loaded: le immagini fuori schermo si caricano solo quando necessario, usando formati di nuova generazione (WebP, AVIF) che sono del 30-50% più leggeri dei JPEG equivalenti a qualità comparabile (misurazioni Cloudinary e Web.dev)
- JavaScript minimale: niente jQuery, niente Bootstrap completo, bundle tree-shaken che includono solo il codice effettivamente usato da ogni pagina
- Incremental Static Regeneration: le pagine prodotto si aggiornano automaticamente quando cambiano inventario o prezzi, senza ricostruire l'intero sito
| Metrica | WooCommerce (tipico) | Next.js Headless (tipico) |
|---|---|---|
| LCP (mobile) | 4-6 secondi | Sotto 1,5 secondi |
| Time to Interactive | 6-10 secondi | Sotto 2 secondi |
| Peso pagina (pagina prodotto) | 4-8 MB | Sotto 500 KB |
| Punteggio Lighthouse (mobile) | 25-45 | 90-98 |
Questi range riflettono risultati tipici degli audit webvise; i risultati dipendono da tema, set di plugin, peso delle immagini e script di terze parti.
Il Calcolo delle Conversioni per il Suo Store
Esegua il calcolo per il Suo store.
Il metodo è semplice:
- Parta dal fatturato mensile attuale
- Stimi il tasso di conversione attuale (ordini diviso sessioni)
- Applichi il miglioramento atteso da un incremento di velocità
- Calcoli il conseguente aumento di fatturato
Scenario illustrativo: una ricostruzione per le prestazioni che porta la conversione dall'1,5% al 2,1% su uno store con €15.000/mese di fatturato sullo stesso traffico si traduce in circa €6.000/mese di fatturato aggiuntivo con un AOV di €100. I risultati effettivi dipendono dal punto di partenza.
Anche un miglioramento più conservativo può compensare il costo della ricostruzione in modo significativo; i tempi di recupero dipendono dal volume di traffico e dall'AOV.
Il calcolo funziona a qualsiasi livello di fatturato. Uno store da €5.000/mese che guadagna 0,5 punti percentuali di conversione aggiunge €1.667/mese. Uno store da €50.000/mese che ottiene lo stesso guadagno aggiunge €16.667/mese.
Cosa Misurare Prima
Prima di apportare qualsiasi modifica, stabilisca la baseline. Quattro strumenti coprono il necessario:
- Google PageSpeed Insights: inserisca l'URL della pagina prodotto (non solo la homepage) e ottenga un punteggio da 0 a 100 su mobile. Sotto 50 è urgente. Sotto 30 significa che i clienti stanno abbandonando attivamente a causa della velocità.
- Google Search Console, sezione Core Web Vitals: mostra dati di utenti reali dai visitatori effettivi, non condizioni di laboratorio. URL in rosso corrispondono a perdite di fatturato in corso.
- Lighthouse (Chrome DevTools): da eseguire in modalità in incognito sulla pagina prodotto. Verifichi l'elemento LCP: è l'immagine principale del prodotto? È contrassegnata come lazy-loaded? Non dovrebbe esserlo.
- Scheda Network (Chrome DevTools): ordini le richieste per dimensione. Cerchi immagini di grandi dimensioni non compresse, script che bloccano il rendering e richieste di terze parti che allungano i tempi di caricamento.
Presti particolare attenzione all'elemento LCP. Se l'immagine hero del prodotto è lazy-loaded, cosa comune nei setup WooCommerce basati su tema, quella singola modifica, ovvero rimuovere l'attributo lazy-load dalla prima immagine visibile, può migliorare l'LCP di 1-2 secondi immediatamente.
Miglioramenti Rapidi Prima di una Ricostruzione Completa
Se una ricostruzione completa non è nell'agenda immediata, queste modifiche possono migliorare le prestazioni nell'ambito della configurazione attuale:
- Compressione immagini e conversione WebP: convertire le immagini prodotto in WebP può ridurre il peso delle immagini del 40-60%. Strumenti come Imagify o ShortPixel gestiscono questo automaticamente.
- Rimozione dei plugin inutilizzati: esegua un audit dei plugin. Ogni plugin installato, anche quelli disattivati, aggiunge overhead. Elimini tutto ciò che non è attivamente necessario.
- Attivazione del caching delle pagine: WP Rocket o W3 Total Cache riduce il costo della generazione dinamica delle pagine. Non corregge l'architettura, ma riduce l'impatto sulle visite ripetute.
- Aggiornamento dell'hosting: l'hosting condiviso impone un limite rigido alle prestazioni. Passare a un hosting WordPress gestito (Kinsta, WP Engine, Cloudways) aggiunge tipicamente 10-20 punti Lighthouse.
- Differimento del JavaScript non critico: la maggior parte dei temi carica tutti gli script su ogni pagina. Differire gli script non necessari al caricamento iniziale riduce il tempo di blocco del rendering.
Queste modifiche prolungano la vita operativa di un sito e possono portare un punteggio da 35 a 55. Non cambiano però il limite strutturale. Uno store WooCommerce con stack di plugin completo, generazione dinamica delle pagine e database condiviso non raggiungerà 85+ su mobile indipendentemente dalla quantità di configurazione effettuata.
Per gli store con un fatturato mensile significativo, queste sono misure temporanee. La correzione strutturale, ovvero la ricostruzione headless, è ciò che sposta i risultati in modo permanente.
Quando una Ricostruzione per le Prestazioni ha Senso Finanziario
La regola approssimativa: se lo store fattura più di €5.000/mese e il punteggio PageSpeed mobile è sotto 60, una ricostruzione per le prestazioni tipicamente si ripaga entro 6 mesi a questo livello di traffico; si tratta di una stima indicativa, non di una garanzia.
Con €10.000/mese e un miglioramento tipico del tasso di conversione di 0,4-0,6 punti percentuali, l'incremento mensile è di €400-600. Un costo di ricostruzione di €3.000-5.000 viene recuperato in 6-10 mesi, senza considerare il miglioramento nel posizionamento organico derivante da punteggi Core Web Vitals più elevati.
Gli store oltre €20.000/mese con punteggi di prestazione insufficienti hanno un'opportunità di conversione non realizzata ogni mese. La finestra di recupero è spesso inferiore a 3 mesi.
Per vedere esattamente dove si trova il Suo store, ottenga un report gratuito sulla salute del sito su webvise.io/wp-health-report. Analizza i Core Web Vitals, identifica i problemi di prestazione con il maggiore impatto e fornisce un quadro chiaro di cosa cambierebbe realmente con una ricostruzione. Nessuna registrazione richiesta.