Quanta RAM consuma WooCommerce con 50, 500 e 5.000 prodotti: l'abbiamo misurato
Misure di laboratorio del 5 ottobre 2026: il numero di prodotti non fa crescere la memoria PHP per richiesta. Cresce il database, non la RAM.
Redazione UptimeMag · 6 ottobre 2026 · 2 minuti di lettura

Chi dimensiona un VPS per un negozio WooCommerce si pone quasi sempre la stessa domanda: con 5.000 prodotti mi serve più RAM che con 50? Il 5 ottobre 2026 abbiamo messo alla prova la domanda in laboratorio, invece di rispondere a sensazione.
Come abbiamo misurato
Ambiente: WordPress 7.1.2, WooCommerce 11.1.2, tema Storefront, PHP 8.3.35 con Apache, MariaDB 11.8.9, Redis 7, WP_MEMORY_LIMIT a 512M, container Docker su una macchina a 8 core. Per ogni pagina abbiamo fatto 15 richieste, scartando il valore e prendendo la mediana, con due richieste a vuoto prima per scaldare OPcache. Le righe a 50 e 500 prodotti sono state rifatte in un secondo giro indipendente: numeri identici.
I numeri
| Catalogo | Picco memoria PHP (catalogo) | Query (catalogo) | Tempo generazione |
|---|---|---|---|
| 50 prodotti | 10,80 MB | 80 | 178 ms |
| 500 prodotti | 10,80 MB | 80 | 176 ms |
| 5.000 prodotti | 10,80 MB | 80 | 147 ms |
Scheda prodotto: 10,77 MB di picco, 99 query, uguali a tutte le taglie di catalogo. Home: 10,59 MB. Container: PHP+Apache stabile fra 144 e 146 MiB, MariaDB fra 108 e 135 MiB.
Con object cache Redis attiva, a catalogo pieno (5.000 prodotti): 15 query invece di 80 sul catalogo, 15 invece di 99 sulla scheda, memoria 10,84 MB, tempo 172 ms.
Perché la memoria non si muove
Il catalogo di Storefront mostra 16 prodotti per pagina, sempre. Che il negozio ne abbia 50 o 5.000, la richiesta HTTP che arriva al server lavora sullo stesso sottoinsieme di righe. È per questo che il picco PHP resta a 10,80 MB indipendentemente dalla dimensione del catalogo: chi alza memory_limit perché "ho tanti prodotti" sta curando un sintomo che il numero di prodotti non causa.
Quello che cresce con il catalogo è il database: le tabelle wp_posts e wp_postmeta si allargano, gli indici diventano più pesanti da mantenere, i backup durano di più. Non la memoria PHP per richiesta.
L'object cache Redis fa esattamente quello che promette: toglie l'80% delle query (da 80 a 15 sul catalogo, da 99 a 15 sulla scheda). Non ha tagliato il tempo di risposta, perché su una macchina scarica il collo di bottiglia non era il database.
Il conto per dimensionare un server
Per il dimensionamento conta il picco PHP per richiesta (nei nostri test 12 MB, perché PHP alloca a blocchi da 2 MB) moltiplicato per il numero di richieste PHP contemporanee attese, più lo spazio per il database che cresce con il catalogo.
Limiti della misura
Richiesta singola, senza concorrenza e senza page cache, database sulla stessa macchina del web server, prodotti semplici senza varianti, nessun plugin oltre a WooCommerce, Storefront e Redis Object Cache. Un negozio con trenta plugin attivi consuma di più: questi numeri sono il pavimento, non il soffitto.
Come rifarlo sul proprio server
Per leggere il picco di memoria di una richiesta: php -d memory_limit=-1 -r "echo memory_get_peak_usage(true);" dentro uno script che carica wp-load.php e genera la pagina. Per contare le query: attivare SAVEQUERIES e leggere $wpdb->num_queries a fine richiesta. Per il tempo di generazione: il timer di Query Monitor o un semplice microtime(true) a inizio e fine template_redirect.
Testo redatto con il supporto dell'intelligenza artificiale e verificato dalla redazione (AI Act, art. 50).