Un WooCommerce lento non è sfortuna: è quasi sempre la somma di autoload gonfio, cart fragments e troppi plugin che si contendono le stesse risorse. In questa guida vediamo perché succede, come misurarlo con dati reali (TTFB, Core Web Vitals, Query Monitor) e come velocizzarlo passo per passo, fino al punto in cui conviene ripensare l'impianto invece di rattopparlo.
Un WooCommerce lento raramente è colpa di una sola cosa. Nella maggior parte dei casi è la somma di tre fattori: la tabella wp_options gonfia di dati caricati a ogni richiesta (l'autoload), i cart fragments che interrogano il server a ogni pagina, e troppi plugin che si contendono database e memoria. Capire quale dei tre pesa di più è il primo passo per velocizzare il negozio sul serio, invece di installare l'ennesima estensione.
Sotto trovate le cause tecniche più frequenti, come misurarle con dati reali e una procedura in sette passi per intervenire. Lo stesso ragionamento vale, con cause diverse, quando WordPress è lento anche senza negozio: WooCommerce eredita quei problemi e ne aggiunge di propri.
Perché WooCommerce è più lento di un sito WordPress normale?
Un sito vetrina serve pagine quasi statiche. Un negozio no: a ogni caricamento WooCommerce gestisce la sessione del carrello, calcola prezzi, sconti e disponibilità, e legge dati sparsi su tabelle come wp_postmeta, che cresce con ogni prodotto, variazione e ordine.
Questo lavoro extra ha un costo in tempo macchina. Se il server non ha una cache a oggetti e gira su un hosting condiviso, il costo si accumula richiesta dopo richiesta e diventa TTFB alto, cioè attesa prima ancora che la pagina cominci a disegnarsi.
Le cause tecniche più comuni di un WooCommerce lento
Nella pratica, i colli di bottiglia si ripetono. Questi sono quelli che troviamo più spesso, in ordine di impatto tipico.
1. Autoload gonfio in wp_options. WordPress carica in memoria a ogni richiesta tutte le righe con autoload = yes. Plugin installati e poi rimossi male lasciano lì opzioni orfane: una tabella di autoload da diversi megabyte rallenta ogni singola pagina, non solo il negozio.
2. Cart fragments su ogni pagina. Lo script wc-cart-fragments.js aggiorna il mini-carrello via admin-ajax.php anche dove il carrello non serve, ad esempio negli articoli del blog. Su siti con molto traffico è una richiesta AJAX non cacheabile ripetuta all'infinito.
3. Stacking di plugin. Non conta quanti plugin avete, conta cosa fanno a ogni caricamento. Due estensioni che eseguono query pesanti o iniettano CSS e JavaScript ovunque pesano più di dieci plugin leggeri.
4. Nessuna object cache. Senza un sistema come Redis, le stesse query al database vengono ripetute a ogni richiesta invece di essere tenute in memoria. Su cataloghi ampi la differenza sul TTFB è enorme.
5. Action Scheduler intasato. WooCommerce accoda molte attività in background (email, sincronizzazioni, ordini programmati). Se la coda si riempie di task falliti, il carico sul database resta alto anche quando il negozio sembra fermo.
6. Immagini prodotto non ottimizzate e PHP datato. Foto caricate a piena risoluzione senza formati moderni gonfiano l'LCP; una versione di PHP vecchia (sotto la 8.x) e un OPcache non attivo lasciano prestazioni sul tavolo senza motivo.
Come capire se il tuo WooCommerce è davvero lento, e dove
Prima di toccare qualcosa, misurate. Ottimizzare a sensazione fa perdere tempo e a volte peggiora la situazione. Vi bastano tre indicatori e uno strumento di diagnosi.
| Sintomo | Causa probabile | Dove verificarlo |
|---|---|---|
| Pagina che tarda a rispondere, anche vuota | TTFB alto: database o hosting | PageSpeed Insights, scheda Rete del browser |
| Schede prodotto che si compongono a scatti | LCP alto: immagini o CSS bloccante | Core Web Vitals in PageSpeed |
| Backend e carrello lentissimi, front-end no | Query non cacheabili, cart fragments | Query Monitor (query per pagina) |
| Rallentamenti a ondate senza traffico | Action Scheduler o WP-Cron | Stato > Azioni programmate in WooCommerce |
Il plugin Query Monitor è il modo più rapido per vedere quante query genera ogni pagina e quali plugin le producono. Come riferimento: un TTFB sotto i 200 ms è sano, oltre gli 800 ms indica un problema strutturale. Lo stesso vale per gli altri motori e-commerce: anche un PrestaShop lento erode le vendite per le stesse ragioni di fondo, database e caching.
Come velocizzare WooCommerce: sette passi concreti
In ordine, dal più economico al più strutturale. Fermatevi quando i numeri tornano nel verde.
1. Pulite l'autoload. Individuate le opzioni più grandi con autoload = yes ed eliminate quelle lasciate dai plugin disinstallati. È l'intervento con il miglior rapporto tra fatica e risultato.
2. Disattivate i cart fragments dove non servono. Caricate wc-cart-fragments.js solo sulle pagine con carrello, non su blog e pagine informative.
3. Fate un audit dei plugin. Rimuovete i doppioni, tenete solo ciò che serve a vendere. Ogni estensione attiva è codice eseguito a ogni richiesta.
4. Attivate una cache di pagina e una object cache. La cache di pagina serve schede e categorie; l'object cache (Redis) alleggerisce carrello, checkout e area cliente, che statici non sono.
5. Aggiornate PHP e attivate OPcache. Passare a PHP 8.x con OPcache attivo è spesso il singolo cambio più efficace lato server.
6. Ottimizzate le immagini. Ridimensionate alla dimensione reale, servite formati moderni e attivate il lazy loading sotto la piega per migliorare l'LCP.
7. Sistemate il database. Su MySQL o MariaDB, un innodb_buffer_pool_size adeguato alla RAM e la pulizia periodica di revisioni e task falliti tolgono peso costante. Se dopo tutto questo il TTFB resta alto, il limite è l'hosting: è ora di un server dedicato.
Quando il problema non è un plugin, ma l'impianto
C'è un punto in cui l'ottimizzazione smette di essere un progetto e diventa manutenzione infinita. Ogni aggiornamento di WooCommerce o di un'estensione può rompere quello che avevate sistemato, e vi ritrovate a curare cache, object cache e tuning del server solo per restare al punto di partenza.
Quando succede, la domanda giusta non è più "quale plugin installo", ma "quanto mi costa tenere in piedi questo impianto". È il ragionamento che portiamo avanti in KeideaCMS: invece di impilare estensioni su un motore generalista, il negozio nasce su una piattaforma integrata, con cache e sicurezza gestite a monte e server dedicati con backup Acronis, senza lo stacking di plugin che genera la maggior parte dei rallentamenti. In un intervento reale su un sito appesantito, questo approccio ha portato il tempo di caricamento da 4 secondi a 0,3 secondi.
Se volete capire la differenza tra questo modello e un negozio costruito a plugin, il confronto tra KeideaCMS e le piattaforme basate su plugin mette in fila i punti che contano: chi gestisce cache e sicurezza, chi aggiorna, che cosa è incluso e che cosa è un extra. E se il vostro negozio è già su WooCommerce, si può migrare da WordPress a KeideaCMS conservando URL, prodotti e posizionamento, senza ripartire da zero.
La velocità è una questione di vendite, non di estetica
Un negozio lento non è solo fastidioso: è un negozio che perde ordini prima ancora di mostrarli. Ogni secondo di attesa sul percorso verso il checkout è un cliente che può chiudere la scheda. Per questo la velocità rientra nei Core Web Vitals con cui Google valuta l'esperienza, e per questo va misurata come un dato di business, non come un dettaglio tecnico.
La buona notizia è che, salvo casi limite, un WooCommerce lento si aggiusta: prima con la diagnosi, poi con interventi mirati, infine con la scelta onesta di cambiare impianto quando rattoppare costa più che rifare.
Il negozio rallenta le vendite?
Vi diciamo dove perde tempo il vostro WooCommerce e come sistemarlo.
Vedi il confronto →Richiedi un'analisi gratuita
A cura del team tecnico di Keidea, con esperienza diretta di hosting, performance e sicurezza su motori e-commerce open source.
