Da 10 a 1000 ordini al mese: scalare il tuo negozio PrestaShop

Dieci ordini al mese sono un passatempo. Cento sono un'attività secondaria. Mille sono una vera azienda. L'errore è pensare che il percorso tra questi numeri sia una rampa uniforme. Non lo è. La crescita su PrestaShop arriva a scatti, e a ogni scatto qualcosa che ieri funzionava benissimo smette silenziosamente di reggere: l'hosting condiviso che gestiva 30 ordini si strozza a 300, gli aggiornamenti manuali degli stati che richiedevano dieci minuti ora si mangiano la mattina, la tabella ps_cart, che prima era trascurabile, diventa la query più lenta del sito. Questa guida mostra che cosa si rompe, nello specifico, a ogni fascia di volume su PrestaShop, e che cosa cambiare nel pannello di amministrazione prima che si rompa, non dopo.

Ultimo aggiornamento: giugno 2026.

Una premessa sull'ambito. Questo è l'articolo sulla meccanica della scalabilità: infrastruttura, flussi del pannello di amministrazione, igiene del database man mano che il volume degli ordini cresce. Non riprende volutamente le fasi precedenti: se stai ancora cercando i primi ordini, i tuoi primi 100 ordini: su cosa concentrarti all'inizio copre quel terreno, mentre l'elenco brutalmente onesto delle sorprese è in 15 cose che nessuno ti dice prima di iniziare. Qui partiamo dal presupposto che gli ordini arrivino già: la domanda è se il tuo negozio sia in grado di sostenerli.

Perché i negozi PrestaShop cedono a scatti, non gradualmente

Un negozio PrestaShop consuma tre risorse man mano che cresce, e non si esauriscono allo stesso ritmo. La capacità del server (CPU, RAM, worker PHP-FPM, connessioni MySQL) peggiora sotto concorrenza: tutto va bene finché un picco di traffico la satura, poi diventa tutto lento insieme. Il tuo tempo si erode in modo lineare con il numero di ordini, finché un singolo compito manuale passa da "fastidioso" a "non riesco a fare nient'altro". E il database cresce monotonicamente con ogni carrello, ospite, connessione e riga di log: non si riduce mai da solo, quindi supera una soglia critica di prestazioni un martedì qualsiasi, senza un motivo visibile.

Poiché questi tre elementi raggiungono il limite in momenti diversi, vivi la crescita come una serie di momenti distinti in cui "va tutto a fuoco", invece che come un lieve declino. Le fasce qui sotto sono organizzate intorno al momento in cui ciascun problema di solito morde. Considera i numeri degli ordini come riferimenti indicativi, non promesse: un negozio che vende una macchina da 4 000 EUR a settimana stressa PrestaShop in modo completamente diverso da uno che vende 40 adesivi da 5 EUR all'ora.

Le quattro fasce in sintesi

Fascia 1: 1–50 ordini al mese: resisti alla tentazione di scalare

A questo volume il collo di bottiglia non è il negozio: è la domanda. Un PrestaShop standard su un hosting modesto gestisce 50 ordini al mese senza quasi accorgersene. L'errore più costoso qui è l'infrastruttura prematura: comprare un server dedicato, aggiungere livelli di cache e automatizzare flussi per un traffico che non hai. Spenderai denaro e, peggio, attenzione su problemi che non stai ancora affrontando.

La mossa tecnica davvero utile in questa fase è attivare le buone pratiche di produzione di PrestaShop, così il negozio è veloce e pulito dal primo giorno, senza costi. In Parametri avanzati → Prestazioni, disattiva la Modalità debug, attiva la cache Smarty con Forza compilazione disattivato, e abilita Combina, comprimi e metti in cache (CCC) per CSS/JS. Questa è tutta la lista infrastrutturale da fare in questa fase. Il resto, qui, è commerciale: validare i prodotti, trovare clienti. Ed è un altro articolo: come validare i prodotti prima di investire e perché specializzarsi batte vendere di tutto.

Fascia 2: 50–200 ordini al mese: quando la gestione manuale degli ordini inizia a costarti

Qui la maggior parte dei titolari sente per la prima volta la pressione, e il colpevole è quasi sempre lo stesso: gestire a mano gli stati degli ordini. Ogni ordine su PrestaShop passa attraverso degli stati (Pagamento accettato → Preparazione in corso → Spedito → Consegnato), e a 50 ordini al giorno diventano centinaia di clic nei menu a tendina in Ordini → Ordini ogni settimana: ognuno è un'occasione per dimenticare un'email di tracciamento o spedire due volte lo stesso articolo.

Automatizza il ciclo di vita dell'ordine, non solo gli avvisi

PrestaShop esegue hook a ogni cambio di stato (actionOrderStatusUpdate, actionOrderStatusPostUpdate), ed è esattamente lì che dovrebbe stare l'automazione basata su regole. Invece di cliccare tu, definisci una volta le transizioni: quando un modulo di pagamento conferma, passa automaticamente a Preparazione; quando viene salvato il numero di tracking del corriere, passa automaticamente a Spedito e invia la notifica al cliente. Questo è il compito del nostro modulo Advanced Order Workflow: quindi cosa ti porta concretamente? Recuperi l'ora al giorno che oggi passi a rimettere in ordine la lista degli ordini, con meno errori umani, configurando tutto dal pannello di amministrazione senza toccare codice. Il guadagno in questa fascia non è un server più veloce: è riprenderti il tuo tempo, così non cresce in modo lineare con gli ordini.

Porta l'hosting un passo avanti, con misura

Se sei ancora su hosting condiviso, questa è la fascia in cui passare a una VPS: 4 GB di RAM, SSD, PHP 8.1+ sono una base ragionevole. Il motivo è la concorrenza, non il numero di ordini: centinaia di sessioni giornaliere significano molti processi PHP e connessioni MySQL simultanei, e l'hosting condiviso ti priva di entrambi sotto carico. Non ti serve ancora una macchina dedicata; ti servono risorse prevedibili, che non condividi con un vicino rumoroso.

Fascia 3: 200–500 ordini al mese: accuratezza e velocità diventano il problema

Ora sei un'attività vera, e le modalità di errore cambiano da "è noioso" a "è sbagliato" e "è lento". Tre cose tendono a colpire insieme.

Disallineamento delle scorte

L'inventario su foglio di calcolo regge finché non regge più. Con oltre 200 ordini al mese, più resi, modifiche manuali e magari un secondo canale di vendita, le scorte registrate e le scorte reali divergono, e inizi a vendere più di quanto hai. Le scorte native di PrestaShop vivono in ps_stock_available e vanno bene per il conteggio in un singolo magazzino; includono persino avvisi di soglia per scorte basse. Ma non offrono un flusso per gli ordini di acquisto, un riapprovvigionamento avanzato o un vero modello multi-sede. Se ti stai avvicinando a quel limite, il nostro modulo Warehouse Revolution aggiunge scorte per magazzino, avvisi di scorte basse e gestione dei riordini, così il numero nel pannello di amministrazione coincide con quello sullo scaffale. (La domanda più ampia, "che cosa gestisco io e che cosa delego" - evasione, assistenza, contabilità - è una decisione a parte: vedi che cosa delegare e che cosa tenere in casa.)

Volume dell'assistenza oltre una sola casella email

Non puoi più rispondere a ogni messaggio in modo improvvisato dalla tua casella personale. Il Servizio clienti integrato di PrestaShop (Servizio clienti → Servizio clienti) organizza in conversazioni i messaggi del modulo di contatto, e instradarli per argomento - ordini, resi, pre-vendita - è ciò che mantiene ragionevoli i tempi di risposta mentre il volume cresce. Un modulo di contatto categorizzato e ben instradato come il nostro Better Contact Form alimenta quel flusso in modo pulito. Questa è anche la fascia in cui la domanda "devo assumere?" diventa reale per la prima volta; abbiamo analizzato i segnali concreti in quando assumere il primo dipendente, e perché le risposte rapide contano dal punto di vista commerciale in perché rispondiamo a ogni ticket entro poche ore.

La velocità delle pagine diventa una leva di ricavo

Con migliaia di visualizzazioni di pagina al giorno, il time-to-first-byte smette di essere una metrica di vanità. Il rendering predefinito di PrestaShop a ogni richiesta significa che ogni visita a una pagina non in cache esegue PHP e una pila di SQL. Qui contano due mosse. Primo, sposta la cache delle query di PrestaShop su uno storage in memoria come Redis, così le letture ripetute non martellano MySQL. La schermata Parametri avanzati → Prestazioni → Cache di PrestaShop offre nativamente Memcached/APCu; per Redis nello specifico, il nostro modulo Instant Redis lo collega senza lavoro da console del server. Secondo, metti una CDN davanti agli asset statici, così immagini e bundle CCC non partono tutti dal tuo origin. L'analisi dettagliata di come diagnosticare la lentezza di PrestaShop merita un articolo a parte: qui meglio linkarla che comprimerla. Ma il principio in questa fascia è: meno andata e ritorno al database per visitatore.

Fascia 4: 500–1000+ ordini al mese: infrastruttura e concorrenza

Oltre i 500 ordini, di solito hai migliaia di visitatori al giorno che consultano il catalogo mentre un flusso costante di acquirenti arriva alla finalizzazione dell'ordine, e il database diventa la risorsa contesa. Questa è la fascia in cui smetti di ottimizzare e inizi a progettare l'architettura.

La cache a pagina intera non è più opzionale

Il cambiamento con il rapporto impatto/sforzo più alto qui è servire la maggior parte del traffico di catalogo dalla cache invece di rigenerarlo. CCC (Fascia 1) minifica solo le risorse; non impedisce a PHP e MySQL di ricostruire la pagina. La cache a pagina intera serve una copia HTML memorizzata ai visitatori anonimi, così i worker PHP e il database restano riservati alle persone che stanno davvero aggiungendo prodotti al carrello e completando l'ordine. Il nostro modulo Performance Revolution lo fa a livello applicativo; in alternativa, un livello Varnish davanti a Nginx/Apache lo fa al bordo. Tradotto in termini di business: lo stesso server assorbe ora un picco di traffico che prima avrebbe buttato giù il negozio nel mezzo di una promozione. E una finalizzazione dell'ordine che resta disponibile durante la tua ora migliore di vendite è il punto centrale.

Separa il database dal server web

Su una sola macchina, MySQL e PHP-FPM si contendono la stessa RAM e la stessa CPU sotto carico. Spostare MySQL su un host dedicato - PrestaShop legge la connessione al DB da app/config/parameters.php (o da config/settings.inc.php su 1.6), quindi è una modifica di configurazione, non di codice - permette a ogni macchina di specializzarsi: i nodi web eseguono PHP, il nodo DB esegue query con molta RAM per il buffer pool (16 GB+ sono ragionevoli a questa scala). Se resti su un singolo server, storage NVMe e 8 GB+ di RAM sono il minimo pratico.

Tutto diventa un'operazione massiva

Il lavoro amministrativo uno alla volta, tollerabile in Fascia 2, ora diventa un lavoro a tempo pieno che nessuno dovrebbe fare. Devi stampare 50 documenti di preparazione in un'unica azione, cambiare 100 stati ordine con una sola selezione ed esportare gli ordini al commercialista o al 3PL in un unico file invece di copiare e incollare. La lista ordini di PrestaShop supporta nativamente le azioni massive; per esportazioni pulite e filtrate, il nostro Orders CSV List Exporter trasforma una vista ordini filtrata in un CSV pronto. La regola in questa fascia: se un'attività cresce con il numero di ordini e la fai ordine per ordine, è una perdita.

Sicurezza e controllo degli accessi quando la posta in gioco sale

Più volume significa più denaro in movimento e un bersaglio più grande. Prima di tutto, due mosse native di PrestaShop: crea profili dipendente reali in Parametri avanzati → Team con permessi limitati al ruolo (chi prepara i pacchi non ha bisogno delle schede Pagamento o Clienti), e abilita il monitoraggio del catalogo e dei log che segnala attività di brute force e scansione: il nostro modulo Security Revolution copre la parte di monitoraggio. I backup smettono di essere una buona idea e diventano non negoziabili: a 1 000 ordini al mese, perdere un giorno di database significa perdere un giorno di ricavi e dati clienti.

Il database è la parte che nessuno guarda finché non è troppo tardi

Questo merita una sezione a parte perché è il killer silenzioso più comune di un negozio PrestaShop in crescita. Ogni visitatore che non compra lascia comunque righe dietro di sé: un carrello abbandonato in ps_cart, un ospite in ps_guest, una connessione in ps_connections / ps_connections_source, visualizzazioni di pagina in ps_page_viewed e statistiche nelle tabelle ps_stats* (ps_statssearch, ps_statsdata e simili). Un negozio che fa 1 000 ordini genera forse oltre 50 000 sessioni, la stragrande maggioranza delle quali serve solo a gonfiare queste tabelle. Lasciate a sé stesse, crescono senza limiti finché le join su di esse rallentano tutto il pannello di amministrazione e i controlli delle regole carrello durante la finalizzazione dell'ordine iniziano a trascinarsi.

La soluzione è una pulizia programmata di carrelli scaduti, regole carrello usate o scadute e vecchie righe statistiche, con attenzione, perché alcune di queste tabelle alimentano report legittimi. Il nostro modulo Cleanup Revolution automatizza questa manutenzione su pianificazione, così il database resta snello mentre il volume cresce, invece di costringerti a ricordare di eseguire SQL a mano (rischiando di eliminare la cosa sbagliata). E quindi? Un pannello di amministrazione che resta reattivo a 1 000 ordini come lo era a 100, senza rallentamenti misteriosi tra tre mesi.

Gli errori che compaiono a ogni fascia

• Scalare troppo presto. Comprare infrastruttura da Fascia 4 a 30 ordini al mese. Spenderai denaro e attenzione per risolvere problemi che non hai, trascurando quello che hai davvero: la domanda.
• Scalare troppo tardi. Aspettare che il sito cada durante una promozione per aggiungere la cache a pagina intera. Quando i clienti ti dicono che è lento, hai già perso gli ordini.
• Aggiungere strumenti invece di rimuovere attrito. Impilare dieci moduli configurati a metà sopra una base lenta. Meno moduli usati bene battono più moduli usati male: i moduli extra sono hook extra eseguiti a ogni caricamento di pagina.
• Ignorare il database. Ne abbiamo parlato sopra: è il precipizio che non vedi arrivare.
• Nessun monitoraggio. Su scala, devi venire a sapere di un'interruzione da un avviso, non da un'email del cliente. Controlli di uptime e tracciamento degli errori sono un'assicurazione economica contro un guasto silenzioso costoso.

Il principio: un passo avanti, non dieci

Il negozio che gestisce 1 000 ordini non condivide quasi nulla, a livello infrastrutturale, con quello che ne gestiva 10. Ed è giusto così. La mossa perdente è cercare di costruire l'assetto da 1 000 ordini il primo giorno; l'altra mossa perdente è rifiutare di aggiornare finché qualcosa non si rompe. Il modello che funziona è restare più o meno una fascia avanti rispetto al tuo volume reale: a 200 ordini ti prepari con calma per 500, così quando arrivi a 500 i sistemi sono già in posizione e la crescita sembra slancio, non crisi.

E l'economia conta quanto l'ingegneria. Aumentare il volume degli ordini ha senso solo se ogni ordine aggiuntivo è davvero profittevole, una volta conteggiati i costi reali: commissioni di pagamento, tempo di assistenza, resi, l'infrastruttura descritta sopra. Prima di spingere forte sul volume, assicurati che l'economia unitaria regga: capire i tuoi veri margini di profitto e i costi di cui nessuno parla. Mille ordini profittevoli sono una vera azienda; mille ordini in pareggio sono solo mille unità di lavoro.

FAQ

I numeri degli ordini non corrispondono al mio negozio: sto leggendo male le fasce?

No. Considera i conteggi degli ordini come riferimenti indicativi, non soglie. Conta il vincolo principale, non il numero. Un negozio che vende poche macchine di alto valore raggiunge i limiti di database e concorrenza molto più tardi di uno che vende molti articoli economici, perché il secondo genera molte più sessioni, carrelli e visualizzazioni del catalogo per ordine. Trova la tua fascia in base al sintomo che morde per primo: flusso manuale che ti mangia la giornata, disallineamento delle scorte, pagine lente o finalizzazione dell'ordine che cede sotto carico. Agisci su quello, non su un conteggio obiettivo di ordini.

Quando devo aggiungere la cache a pagina intera: a che punto CCC non basta più?

Aggiungi la cache a pagina intera quando il traffico anonimo sul catalogo rigenera pagine che i tuoi worker PHP e il database non riescono più a sostenere durante un picco: di solito intorno alla fascia dei 500 ordini al mese, quando hai migliaia di visitatori al giorno. CCC minifica e combina solo CSS/JS; non fa nulla per impedire a PHP e MySQL di ricostruire la pagina a ogni visita. La cache a pagina intera serve HTML memorizzato ai visitatori anonimi, così worker e DB restano riservati alle persone che stanno davvero aggiungendo prodotti al carrello e completando l'ordine. Se una promozione ha già rallentato il sito fino quasi a bloccarlo, sei già oltre il punto in cui avrebbe dovuto essere attiva.

Devo davvero pulire il database, o è ottimizzazione prematura?

Diventa manutenzione reale, non ottimizzazione prematura, quando superi qualche centinaio di ordini al mese. Ogni visitatore che non compra lascia comunque righe dietro di sé: carrelli abbandonati in ps_cart, ospiti, connessioni, visualizzazioni di pagina, statistiche. E quelle tabelle crescono soltanto. Un negozio che fa 1.000 ordini può generare oltre 50.000 sessioni, la grande maggioranza delle quali serve solo a gonfiare quelle tabelle finché le join su di esse rallentano il pannello di amministrazione e appesantiscono i controlli delle regole carrello durante la finalizzazione dell'ordine. La pulizia programmata di carrelli scaduti, regole carrello usate e vecchie statistiche mantiene snello il database; falla con attenzione, perché alcune di quelle tabelle alimentano report legittimi.

Dovrei spostare MySQL su un server dedicato o comprare semplicemente una macchina più grande?

Resta su una singola macchina ben dimensionata (storage NVMe, 8 GB+ di RAM) finché un solo server assorbe comodamente il carico di picco. Sposta il database su un host dedicato quando MySQL e PHP-FPM si contendono visibilmente la stessa RAM e la stessa CPU sotto carico, tipicamente nella parte avanzata della fascia 500–1.000+. PrestaShop legge la connessione al DB dalla configurazione (app/config/parameters.php, o config/settings.inc.php su 1.6), quindi spostare il database è una modifica di configurazione, non di codice. Dopo la separazione, ogni macchina si specializza: i nodi web eseguono PHP, il nodo DB esegue query con un buffer pool ampio.

Qual è l'errore di scalabilità più comune?

I due opposti, ugualmente costosi. Scalare troppo presto, cioè comprare infrastruttura da Fascia 4 a 30 ordini al mese, consuma denaro e attenzione su problemi che non hai, trascurando quello che hai davvero: la domanda. Scalare troppo tardi, cioè aspettare che il sito cada nel mezzo di una promozione per aggiungere la cache, significa che i clienti ti dicono che è lento solo dopo che hai già perso gli ordini. Il modello che funziona è restare più o meno una fascia avanti rispetto al tuo volume reale, così i sistemi sono pronti appena prima che servano.