Un catalogo WooCommerce che supera le migliaia di prodotti rallenta quasi sempre per lo stesso motivo: la struttura database di default di WordPress, pensata per i post di un blog, non è ottimizzata per gestire ordini ed entità ecommerce su grande scala. HPOS, High-Performance Order Storage, è la funzionalità che WooCommerce ha introdotto proprio per risolvere questo collo di bottiglia, spostando i dati degli ordini in tabelle dedicate invece di usare le tabelle standard dei post di WordPress. Su cataloghi grandi non è un’ottimizzazione facoltativa, è la differenza tra un ecommerce che regge il carico e uno che va in errore sotto pressione.
Le agenzie che gestiscono progetti WooCommerce per clienti con cataloghi estesi, distributori, produttori con migliaia di referenze, marketplace verticali, incontrano con una certa regolarità sintomi che sembrano generici (sito lento, checkout che si blocca, pannello di amministrazione che carica con lentezza) ma che hanno quasi sempre la stessa origine tecnica: il database che fatica a gestire il volume di dati.
Perché WordPress standard non regge un catalogo grande senza intervento
WordPress salva ordini, prodotti e meta dati nella stessa struttura di tabelle usata per i post di un blog: wp_posts e wp_postmeta. Questa struttura funziona bene per centinaia di contenuti, ma su un ecommerce con migliaia di prodotti e ordini, ognuno con decine di meta campi associati (varianti, magazzino, prezzi per listino, attributi), la tabella wp_postmeta cresce a dismisura e le query che WooCommerce deve eseguire per mostrare un catalogo o processare un ordine diventano progressivamente più lente.
Il sintomo più comune che le agenzie ci segnalano è il rallentamento del pannello ordini in amministrazione quando il numero di ordini storici supera alcune migliaia: la pagina che dovrebbe mostrare l’elenco ordini impiega diversi secondi a caricare, e su cataloghi molto attivi può arrivare a un errore di timeout.
Problema: pagina ordini WooCommerce lentissima o in timeout
Causa: query su wp_postmeta con migliaia di righe di meta dati per ordine, tabella non indicizzata per il tipo di ricerca che WooCommerce esegue di default
Soluzione Blurr: migrazione a HPOS, che sposta gli ordini in tabelle dedicate (wp_wc_orders e tabelle correlate) progettate specificamente per questo tipo di query, con indici ottimizzati per le operazioni ecommerceCos’è HPOS e come funziona nella pratica
HPOS è stato introdotto da WooCommerce per separare la gestione degli ordini dalla struttura generica dei post di WordPress. Con HPOS attivo, gli ordini vengono salvati in tabelle dedicate (wp_wc_orders, wp_wc_order_operational_data, wp_wc_order_addresses) progettate specificamente per le query che un ecommerce esegue di continuo: ricerca per stato ordine, filtro per cliente, calcolo di totali e statistiche.
Il beneficio principale è sulla velocità delle operazioni relative agli ordini: ricerca, filtro e reportistica diventano sensibilmente più rapide perché le tabelle sono indicizzate per quel tipo specifico di query, invece di appoggiarsi alla struttura generica e meno efficiente di wp_postmeta. Su cataloghi con alto volume di ordini, la differenza si misura in secondi di caricamento risparmiati su ogni pagina del pannello amministrativo, non in millisecondi.
WooCommerce dalla versione 8.2 ha reso HPOS stabile e lo attiva di default sulle nuove installazioni. Per i siti esistenti, l’attivazione richiede una migrazione che va pianificata con attenzione: WooCommerce mette a disposizione uno strumento di sincronizzazione che permette di testare HPOS mantenendo la compatibilità con i dati legacy durante la transizione.
La migrazione a HPOS su un sito già attivo: come evitare problemi
Attivare HPOS su un ecommerce già in produzione, con ordini storici accumulati, non è un’operazione da fare senza preparazione. Il rischio principale è l’incompatibilità con plugin di terze parti che leggono e scrivono direttamente sulle tabelle standard di WordPress invece di usare le API ufficiali di WooCommerce.
Problema: plugin di terze parti (integrazioni gestionale, plugin di reportistica custom) che smettono di funzionare dopo l'attivazione di HPOS
Causa: il plugin accede direttamente alle tabelle wp_posts/wp_postmeta invece di usare le funzioni API di WooCommerce (wc_get_order, CRUD standard), e non trova più i dati nella posizione attesa
Soluzione Blurr: verifica preventiva di compatibilità HPOS su ogni plugin attivo prima della migrazione, consultando la pagina di stato compatibilità in WooCommerce > Impostazioni > Funzionalità > Compatibilità plugin, che elenca automaticamente eventuali incompatibilità noteIl processo corretto che seguiamo su ogni migrazione HPOS per i clienti delle agenzie partner prevede sempre un passaggio su ambiente di staging prima della produzione: attivazione della modalità di sincronizzazione, verifica che tutti gli ordini storici siano stati sincronizzati correttamente, test dei plugin critici (gateway di pagamento, integrazioni gestionale, plugin di spedizione), e solo dopo la verifica completa lo switch definitivo in produzione.
Errori di memoria su cataloghi con migliaia di prodotti
Oltre ai problemi legati agli ordini, i cataloghi molto estesi generano un secondo tipo di problema ricorrente: errori di memoria PHP durante operazioni che coinvolgono l’intero catalogo, come l’esportazione prodotti, la rigenerazione delle miniature immagine o la sincronizzazione con un gestionale esterno.
Problema: Fatal Error: Allowed memory size of 256M exhausted durante l'esportazione o l'importazione massiva di prodotti
Causa: WooCommerce carica in memoria l'intero set di prodotti da processare invece di gestirlo a lotti, e su cataloghi con decine di migliaia di referenze la memoria allocata a PHP non è sufficiente
Soluzione Blurr: aumento del memory limit PHP a 512M come minimo per hosting che gestiscono cataloghi estesi, combinato con l'uso di strumenti di importazione/esportazione che processano i dati a batch (WP All Import con batch size configurato, o script custom con paginazione) invece di caricare tutto il catalogo in un'unica operazioneUn caso reale che abbiamo gestito per un’agenzia partner riguardava un cliente distributore con oltre 15.000 prodotti, che aveva bisogno di sincronizzare quotidianamente disponibilità e prezzi da un gestionale esterno. La sincronizzazione, implementata inizialmente come un unico script che processava tutto il catalogo in una chiamata, andava sistematicamente in timeout dopo circa 8.000 prodotti processati. Riscrivendo la sincronizzazione a lotti di 500 prodotti per volta, con log di avanzamento e ripresa automatica in caso di interruzione, il processo completo è sceso da un timeout costante a circa 12 minuti di esecuzione stabile.
Indicizzazione e ricerca su cataloghi grandi
Un altro collo di bottiglia frequente riguarda la ricerca interna del catalogo lato cliente finale. La ricerca standard di WordPress, basata su query LIKE su wp_posts, diventa progressivamente più lenta all’aumentare del numero di prodotti, e su cataloghi oltre le 5.000-10.000 referenze può diventare un problema di esperienza utente concreto, con tempi di risposta della ricerca che superano il secondo.
La soluzione per cataloghi di queste dimensioni è quasi sempre l’adozione di un motore di ricerca dedicato, come Algolia o ElasticSearch, integrato tramite plugin specifici che sincronizzano il catalogo su un indice esterno ottimizzato per la ricerca full-text. È un investimento aggiuntivo che va proposto al cliente quando il catalogo raggiunge dimensioni che rendono la ricerca nativa di WordPress inadeguata, non aggiunto reattivamente dopo che i clienti finali si lamentano dei tempi di attesa.
Quando proporre questi interventi al cliente
Le ottimizzazioni descritte in questo articolo, HPOS, gestione della memoria, ricerca dedicata, non vanno proposte indiscriminatamente a ogni progetto WooCommerce. Un catalogo con poche centinaia di prodotti non ha gli stessi problemi e non giustifica lo stesso livello di intervento. La soglia indicativa oltre la quale iniziamo a valutare questi interventi come necessari, non opzionali, è intorno ai 2.000-3.000 prodotti per HPOS e la gestione della memoria, e 5.000-10.000 prodotti per la ricerca dedicata.
Per un inquadramento più generale di come impostiamo i progetti WooCommerce per le agenzie, incluse le categorie di complessità e le domande da fare al cliente in fase di brief, abbiamo scritto un articolo dedicato citato sopra. Per la parte di performance generale applicabile a qualsiasi sito WordPress, incluso l’ecommerce, leggi la nostra checklist performance.
Se segui un cliente con un catalogo WooCommerce di grandi dimensioni e vuoi una valutazione tecnica su HPOS e le ottimizzazioni necessarie, su blurr.it/contatti/ puoi prenotare una chiamata per un audit specifico.
Domande frequenti
HPOS, High-Performance Order Storage, è la funzionalità che sposta gli ordini WooCommerce in tabelle database dedicate invece delle tabelle generiche dei post di WordPress. Conviene attivarlo su qualsiasi catalogo con volume di ordini medio-alto, indicativamente oltre le poche migliaia di ordini storici, dove il pannello amministrativo inizia a mostrare rallentamenti evidenti.
Può creare problemi se ci sono plugin di terze parti che accedono direttamente alle tabelle standard di WordPress invece di usare le API ufficiali di WooCommerce. Per questo la migrazione va sempre testata su staging, verificando la compatibilità di ogni plugin attivo prima dello switch in produzione.
Perché molti strumenti caricano l’intero set di prodotti in memoria invece di processarlo a lotti. Su cataloghi estesi la memoria PHP allocata di default non è sufficiente. La soluzione è aumentare il memory limit e usare strumenti di importazione/esportazione che processano i dati a batch.
Indicativamente sopra i 5.000-10.000 prodotti, quando la ricerca nativa di WordPress inizia a mostrare tempi di risposta superiori al secondo. Sotto questa soglia la ricerca standard è generalmente sufficiente e non giustifica il costo aggiuntivo di un motore di ricerca esterno.