Quasi ogni indagine sulla performance WooCommerce comincia allo stesso modo. Il titolare del negozio si è già spostato su un hosting più veloce, ha installato un plugin di cache e comprato un ottimizzatore di immagini, e il sito continua a essere lento. La conclusione è che WooCommerce sia semplicemente pesante, e a quel punto si rinuncia.

WooCommerce è effettivamente più pesante di un sito vetrina, cosa inevitabile quando ogni pagina può portarsi dietro un carrello. Ma un negozio che impiega sei secondi a caricarsi non soffre per quel peso di base. Soffre per qualcosa di preciso, e nella mia esperienza si tratta quasi sempre di una fra quattro cause.

In breve: i negozi sono lenti perché carrello e checkout non possono essere serviti da una cache di pagina, perché la tabella delle opzioni è cresciuta a dismisura con dati caricati automaticamente, perché le query sui prodotti scandagliano una tabella di metadati priva di indici e perché trenta plugin aggiungono ciascuno i propri script a ogni pagina. L’hosting è l’ultima cosa da cambiare, non la prima.

Perché un negozio non è un blog

Una sola distinzione spiega gran parte del comportamento di WooCommerce in termini di prestazioni.

Un articolo di blog è identico per ogni visitatore, quindi può essere generato una volta e servito dalla cache a tutti. È per questo che i siti vetrina risultano veloci quasi a prescindere da come sono stati costruiti. Un negozio non può farlo su ogni pagina, perché il carrello è personale. Nel momento in cui un visitatore ci mette dentro un articolo, la pagina deve riflettere il suo stato invece di una copia condivisa con tutti.

La conseguenza è che le pagine di carrello, checkout e account scavalcano completamente la cache di pagina ed eseguono PHP e query al database a ogni richiesta. Sono anche le pagine in cui la lentezza ti costa denaro in modo diretto. Una pagina di categoria lenta perde i curiosi; un checkout lento perde chi stava comprando.

La domanda utile quindi non è mai se il sito sia veloce. È quanto sia veloce per un visitatore autenticato che ha qualcosa nel carrello. Testa in modo specifico quello stato, perché è quello da cui dipendono i tuoi incassi ed è quello che ogni test di velocità sintetico si lascia sfuggire.

Le quattro cose che non vanno davvero

Una tabella delle opzioni sovraccarica. WordPress carica una serie di opzioni a ogni singola richiesta, e i plugin ci scrivono dentro liberamente. I plugin disinstallati lasciano regolarmente le proprie righe. Nei negozi più vecchi questa tabella arriva a decine di megabyte di dati caricati automaticamente e letti a ogni visualizzazione di pagina, checkout compreso. È invisibile, si accumula anno dopo anno, ed è uno degli interventi con il rendimento più alto in assoluto. Controlla per prima cosa la dimensione totale delle opzioni caricate automaticamente; se si misura in megabyte anziché in kilobyte, hai trovato tempo vero.

Query sui prodotti contro metadati privi di indici. Storicamente WooCommerce ha memorizzato attributi, prezzi e giacenze dei prodotti in una tabella di metadati generica condivisa con tutto il resto. Filtrare o ordinare un catalogo ampio significa unire quella tabella ripetutamente. Con qualche centinaio di prodotti non se ne accorge nessuno. Con decine di migliaia, le pagine di categoria e di filtro rallentano fino a diventare penose. Le versioni più recenti di WooCommerce hanno spostato i dati degli ordini in tabelle dedicate proprio per alleggerire questa pressione, e attivare quel tipo di archiviazione su un negozio con uno storico ordini lungo di solito vale l’intervento anche da solo.

Plugin e chiamate esterne

Proliferazione di plugin sul percorso critico. Il problema raramente è il numero in sé; è che la maggior parte dei plugin carica il proprio CSS e il proprio JavaScript su ogni pagina invece che solo dove servono. Un plugin di prenotazioni usato su una sola pagina carica i suoi file anche sul tuo checkout. Il rimedio è poco glamour: verificare che cosa carica ciascun plugin, togliere quei file al di fuori delle pagine di competenza ed eliminare tutto ciò di cui non sai indicare la funzione.

Chiamate a terze parti non messe in cache. Tariffe di spedizione in tempo reale, calcolo delle imposte, conversione valuta e controlli di giacenza su un sistema esterno inseriscono tutti una richiesta di rete dentro il caricamento della pagina. Quando quel fornitore è lento il tuo checkout è lento, e quando cade cade anche il tuo checkout. Ogni chiamata esterna nel percorso di una richiesta ha bisogno di un timeout, di una cache e di un comportamento di riserva per quando il servizio non risponde. La nostra guida all’integrazione di API di terze parti spiega come va costruito.

Che cosa aiuta davvero, nell’ordine giusto

Affronta questi punti in sequenza, perché ognuno cambia ciò che ti dirà la misurazione successiva.

Cache a oggetti, non solo cache di pagina. La cache di pagina serve pagine HTML complete e non può fare nulla per carrello e checkout. Una cache a oggetti persistente conserva in memoria il risultato delle query al database e velocizza esattamente le pagine che la cache di pagina non può toccare. Per un negozio è di solito il singolo miglioramento più grande a disposizione, ed è anche il passaggio che viene saltato più spesso, perché il plugin di cache già installato ha dato l’impressione che il lavoro fosse concluso.

Manutenzione del database. Cancella i transient scaduti, rimuovi i metadati orfani di prodotti e ordini eliminati e sfoltisci le revisioni degli articoli. In un negozio che vende da anni questo elimina abitualmente una fetta notevole del database. Programma l’operazione come attività ricorrente, invece di farla una volta sola.

Poi l’hosting. Una volta sistemati cache e database, l’hosting conta davvero: versione di PHP, memoria disponibile, se il database gira sulla stessa macchina e se sei su un piano condiviso in competizione con altri inquilini. Ma cambiare fornitore prima di aver corretto quanto sopra si limita a trasferire il problema a un indirizzo più caro.

Le risorse statiche per ultime. Formati delle immagini, caricamento differito e rinvio degli script meritano attenzione, ed è da qui che parte la maggior parte delle guide. Migliorano l’esperienza di caricamento di pagine che venivano già servite a un ritmo ragionevole. Fanno pochissimo per un checkout che passa quattro secondi dentro PHP prima di spedire il primo byte.

Misurare correttamente la performance WooCommerce

I punteggi sintetici traggono in inganno i titolari di negozi più di qualunque altro pubblico, quindi misura con intenzione.

Testa lo stato autenticato, con il carrello pieno. La maggior parte degli strumenti prova un visitatore anonimo sulla home page, cioè il percorso più rapido possibile dentro il tuo sito, e questo non dice quasi nulla sul checkout.

Separa il tempo del server dal tempo del front-end. Se il server impiega tre secondi a produrre l’HTML, nessuna ottimizzazione delle immagini salverà la pagina. Il tempo al primo byte ti dice quale metà del problema hai davanti, e quindi quale delle correzioni precedenti ti riguarda.

Usa dati sul campo invece che dati di laboratorio ogni volta che puoi. Visitatori reali su connessioni e telefoni reali restituiscono un quadro diverso da un test lanciato in un data center, e i Core Web Vitals vengono valutati sui primi. La nostra guida all’audit delle prestazioni WordPress spiega come leggere correttamente queste metriche, e Core Web Vitals nel 2026 chiarisce che cosa richiedono davvero le soglie.

Infine, osserva il database direttamente durante una richiesta lenta. Un log che mostra la stessa query eseguita duecento volte in un solo caricamento identifica subito il colpevole, e quel comportamento è estremamente comune nei negozi che usano più plugin, ciascuno dei quali chiede i dati dei prodotti per conto proprio.

Quanto costa questo lavoro

I prezzi qui sotto riflettono le tariffe tipiche delle agenzie britanniche per un negozio di dimensioni medie.

Un audit delle prestazioni che individua le cause specifiche, con un elenco di interventi in ordine di priorità e misurazioni prima e dopo, si colloca in genere fra 900 e 2.500 sterline. È un incarico diagnostico e conviene acquistarlo separatamente, perché ti dice se il lavoro rimanente è una settimana o un mese.

Realizzare gli interventi più comuni, cioè cache a oggetti, pulizia del database, verifica dei file caricati dai plugin e messa in cache delle chiamate esterne, costa di solito fra 2.000 e 6.000 sterline a seconda di quanto si è accumulato.

Il lavoro più profondo costa di più perché è sviluppo vero e proprio. Migrare un catalogo ampio verso un’archiviazione indicizzata, ricostruire un sistema di filtri che scandaglia i metadati o sostituire un plugin lento con un’implementazione su misura mirata rientra tipicamente fra 6.000 e 20.000 sterline.

La cifra che conta più di tutte queste è quanto ti costa la lentezza. L’abbandono del checkout cresce in modo misurabile con il tempo di caricamento, per cui un negozio con un fatturato significativo riesce di solito a giustificare l’audit sulla sola pagina di pagamento.

Sistema il negozio, non il punteggio

Mecanik si occupa di performance WooCommerce nell’ambito del nostro servizio di sviluppo WordPress , e partiamo misurando il percorso di checkout da utente autenticato invece della home page, perché è lì che i negozi perdono davvero denaro.

Guardiamo le opzioni caricate automaticamente, l’archiviazione degli ordini, gli schemi delle query e le chiamate esterne prima di consigliare un cambio di hosting, e ti consegniamo le misurazioni sia prima sia dopo, così il miglioramento è verificabile e non semplicemente affermato. Se il tuo negozio è lento perché ha superato i limiti della piattaforma e non perché è configurato male, te lo diciamo lo stesso: il nostro confronto fra Shopify ed e-commerce su misura spiega dove passa quel confine.

Mandaci l’indirizzo del negozio e, all’incirca, quanti prodotti e quanti ordini contiene, e ti diremo quale delle quattro cause qui sopra ti riguarda con maggiore probabilità.

Post correlati: Sito WordPress hackerato: rimuovere il malware , Scalare un e-commerce nel Regno Unito: guida tech 2026 , Assumere uno sviluppatore Drupal: tariffe e selezione , Quanto costa un sito web nel Regno Unito nel 2026? .

Domande frequenti

Perché il mio sito WooCommerce è lento anche con un plugin di cache? La cache di pagina non può essere applicata alle pagine di carrello, checkout e account, perché queste devono riflettere lo stato di ciascun visitatore. Quelle pagine eseguono PHP e query al database a ogni richiesta, quindi velocizzarle richiede una cache a oggetti e lavoro sul database invece della cache di pagina.

Passare a un hosting migliore risolve la performance WooCommerce? Solo in parte, e non dovrebbe essere il primo passo. Se la tabella delle opzioni è gonfia, le query sono prive di indici e i plugin caricano risorse ovunque, un hosting migliore rende gli stessi problemi solo leggermente più veloci a un costo più alto. Sistema prima cache e database, poi rivaluta l’hosting.

Quanti plugin sono troppi per WooCommerce? Il numero conta meno di ciò che ciascuno carica. Venti plugin ben educati che caricano risorse solo sulle proprie pagine fanno meno danni di otto che diffondono script su tutto il sito. Verifica che cosa aggiunge ognuno al checkout e rimuovi tutto ciò di cui nessuno sa spiegare lo scopo.

Quanto costa l’ottimizzazione della velocità di WooCommerce? Un audit diagnostico con un elenco di interventi in ordine di priorità costa in genere fra 900 e 2.500 sterline. Realizzare gli interventi comuni come cache a oggetti, pulizia del database e verifica delle risorse costa di solito fra 2.000 e 6.000 sterline, mentre rifare catalogo o filtri può arrivare fra 6.000 e 20.000 sterline.

Come si testa correttamente la performance WooCommerce? Prova da visitatore autenticato con articoli nel carrello, non con una visita anonima alla home page. Separa il tempo di risposta del server dal rendering front-end per capire quale metà è lenta, e usa dati sul campo raccolti da visitatori reali invece di affidarti solo ai punteggi di laboratorio.