Scegliere l'hosting per PrestaShop: cosa conta davvero e cosa è marketing

Ecco la verità scomoda che la maggior parte degli articoli comparativi sull'hosting tende a nascondere: la scheda tecnica che ti viene mostrata quando acquisti un hosting e i fattori che determinano davvero se il tuo negozio PrestaShop risulta veloce hanno pochissimo in comune. Il provider pubblicizza core CPU, "storage NVMe" e "banda illimitata"; PrestaShop, nel frattempo, guarda alla tua versione di PHP, alla memoria consentita per una singola richiesta, al fatto che OPcache sia attivo e alla vicinanza del server MySQL al processo PHP. Puoi pagare per un piano più grande senza percepire alcuna differenza, oppure spendere la stessa cifra per un hosting configurato per applicazioni PHP e vedere il time-to-first-byte dimezzarsi. Questa guida serve a leggere un'offerta di hosting come la leggerebbe PrestaShop: separando le voci che incidono sul tempo di generazione delle pagine da quelle create solo per vincere la guerra delle tabelle comparative.

Rivisto rispetto ai requisiti di hosting di PrestaShop 1.6, 1.7, 8.x e 9.x. Gestiamo mypresta.rocks su un VPS che configuriamo direttamente. La lista riflette queste scelte di hosting; misura le prestazioni del tuo negozio con una configurazione di test documentata.

Per chiarire il perimetro: questo articolo riguarda la scelta della macchina su cui vive il tuo negozio. Non è la guida all'ottimizzazione (quella è l'ottimizzazione delle prestazioni dalle query al database fino alla cache full page), non è la diagnosi del "perché il mio negozio è lento" (cosa rende davvero lento PrestaShop) e non è l'analisi dei moduli di cache (spiegazione dei moduli di cache full page). L'hosting è una delle tre gambe del tavolo: database, moduli, hosting. Qui restiamo sulla gamba dell'hosting.

Che cosa richiede davvero PrestaShop a un server

Prima di confrontare anche un solo piano, conviene sapere cosa fa PrestaShop a ogni richiesta non in cache, perché è quella la capacità che stai davvero acquistando. Il rendering di una pagina del front office avvia il framework PHP, carica i moduli attivi, esegue gli hook registrati per quella pagina, lancia una serie di query SQL (una pagina categoria con navigazione a faccette può generarne decine), renderizza i template Smarty e assembla la risposta. È un carico di lavoro PHP e MySQL, non un carico da file statici. Quindi le risorse che contano sono quelle che fanno eseguire PHP velocemente e permettono a MySQL di rispondere in fretta, non quelle che rendono generosa una brochure.

I requisiti minimi dichiarati da PrestaShop sono una base, non un obiettivo. La piattaforma documenta la necessità di PHP e di un database MySQL/MariaDB con InnoDB, ma la versione PHP supportata cambia in base al ramo: PrestaShop 1.7.8 arriva fino a PHP 7.4, PrestaShop 8 gira su 7.4/8.0/8.1 a seconda della minor release, e PrestaShop 9.x richiede PHP 8.1+. Un hosting che nel 2026 ti assegna ancora PHP 7.2 come predefinito, o che non può offrire 8.1, ti sta già dicendo qualcosa su quanto sia aggiornato il resto del suo stack.

Cosa conta davvero: leggi l'offerta come la legge PrestaShop

php -i | egrep 'opcache.enable|opcache.memory_consumption|memory_limit'
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\n' https://www.example.com/

Queste sono le voci che cambiano il comportamento di una vera richiesta PrestaShop. Se un hosting è vago su una qualsiasi di esse, quella vaghezza è già la risposta.

Quindi, in concreto, cosa ti compra questa lista? La tranquillità che il denaro speso finisca dove PrestaShop lo percepisce davvero. Le due voci in cima, PHP aggiornato e OPcache, sono spesso la differenza tra un negozio lento e uno reattivo, e non costano nulla in più: sono una scelta di configurazione, non un upgrade di piano. Se un commerciale non sa dirti quale versione PHP avrai e se OPcache è attivo, stai parlando con l'hosting sbagliato.

Cosa è soprattutto marketing

Nessuna delle cose seguenti è esattamente una bugia. Ognuna è un'affermazione vera costruita per sembrare un vantaggio, senza dirti nulla su come si comporterà il tuo negozio.

Storage / banda / database "illimitati". Nulla è illimitato; esiste una clausola di uso corretto, e un negozio PrestaShop che usa davvero risorse prima o poi la incontrerà. La parola "illimitato" significa soprattutto "abbiamo scelto di non stampare il limite". Peggio ancora, i piani illimitati sono di solito server condivisi venduti ben oltre la capacità ideale: la generosità sulla carta è finanziata stipando più siti sul server, cioè esattamente ciò che rende imprevedibile il tuo negozio.

"Ottimizzato per PrestaShop." A volte è vero (una build PHP sensata, OPcache, MySQL ottimizzato per InnoDB, magari un livello di cache già collegato). A volte significa che qualcuno ha installato PrestaShop una volta e ha aggiunto la frase alla pagina di vendita. Il test è specifico e corretto: chiedi "quale versione PHP, OPcache è attivo, qual è il memory_limit predefinito, e Redis o Memcached sono disponibili?" Un hosting che ottimizza davvero risponde subito. Un hosting che ha solo stampato un badge resta in silenzio.

"Garanzia di uptime 99,9%." La dichiarano tutti, e 99,9% consente comunque circa 8,7 ore di inattività all'anno. La garanzia è quasi sempre sostenuta da crediti di servizio, pochi centesimi rimborsati, non da un risarcimento per gli ordini persi. Considerala un requisito minimo, non un elemento distintivo, e misura tu stesso l'uptime reale con un monitor esterno.

"Core CPU" e "RAM" come numeri in evidenza. Un piano a 4 core bloccato su PHP 7.2 con OPcache disattivato perderà contro un piano a 2 core su PHP 8.2 con OPcache attivo. Il conteggio grezzo delle risorse conta solo quando lo stack software sottostante è aggiornato. Leggi prima lo stack, poi la scheda tecnica.

"Migrazione gratuita." Una migrazione PrestaShop comprende file, database, configurazione parameters.php, cron job, SSL e riscritture URL. Alcuni hosting fanno tutto; altri copiano i file e ti lasciano i problemi. Chiedi esattamente cosa include la "migrazione", per iscritto, prima di impegnarti.

Le fasce di hosting e il tipo di negozio PrestaShop adatto a ciascuna

Le categorie contano meno dell'allineamento tra la fascia scelta, il traffico reale e quanta amministrazione server sei disposto a gestire.

La lettura onesta: la maggior parte dei negozi PrestaShop sta meglio su un VPS, perché le cose che decidono le prestazioni, versione PHP, OPcache, limiti di memoria, Redis locale, sono esattamente quelle che l'hosting condiviso non ti lascia toccare e che l'hosting gestito ti fa pagare con un sovrapprezzo. Su un VPS puoi impostarle tu, una volta, e tenerti la differenza. Il punto è che tu (o qualcuno per te) devi essere disposto a fare amministrazione server di base; se questo è un no assoluto, l'hosting gestito ricompra quel tempo in modo legittimo.

Una checklist d'acquisto da eseguire in cinque minuti

Prima di pagare, ottieni un sì per ciascuno di questi punti, via email se la pagina commerciale non lo dice:

• "Posso selezionare PHP 8.1 o superiore per singolo sito e cambiarlo da solo?" L'assenza di cambio PHP self-service è un segnale d'allarme per una piattaforma datata.
• "OPcache è abilitato per impostazione predefinita?" Se non sanno cosa sia OPcache, chiudi la chiamata.
• "Quale memory_limit ottengo e posso alzarlo a 512M per l'amministrazione?" Sotto 256M avrai problemi con importazioni e aggiornamenti.
• "Il database MySQL è sullo stesso server o sulla rete locale?" Un DB remoto condiviso aggiunge latenza a ogni query su ogni pagina.
• "Redis o Memcached sono disponibili?" Non devi usarli per forza oggi, ma li vorrai più avanti: vedi sotto.
• "SSL Let's Encrypt gratuito?" HTTPS è obbligatorio per un negozio; un hosting che nel 2026 fa pagare l'SSL è un segnale d'allarme.
• "Che cosa include esattamente un backup e per quanto tempo viene conservato?" Ti servono backup giornalieri automatici, conservazione minima di 7 giorni, e comunque una tua copia offsite, perché un backup che non hai mai ripristinato non è un backup.

Un buon hosting richiede comunque configurazione, ed è un lavoro diverso

Acquistare la macchina giusta è metà del lavoro; quella macchina va ancora configurata. Le impostazioni server con il maggior impatto per PrestaShop sono OPcache (così il sorgente PHP non viene ricompilato a ogni richiesta), HTTP/2 o HTTP/3, e la compressione Brotli/Gzip sulle risposte testuali. Due di queste, OPcache e compressione, sono di solito un interruttore lato hosting; se sono disattivate, attivarle è l'accelerazione più economica che potrai mai ottenere.

Su un VPS dove questi file sono sotto il tuo controllo, due impostazioni portano la maggior parte del guadagno lato server. OPcache impedisce a PHP di ricompilare il tuo negozio a ogni richiesta: valori di produzione sensati per un'installazione PrestaShop assomigliano a questi (da inserire in un .ini caricato dal tuo pool PHP-FPM):

opcache.enable=1
opcache.memory_consumption=192
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

PrestaShop distribuisce un numero elevato di file, quindi max_accelerated_files deve essere generoso o OPcache espellerà il tuo stesso codice; 192MB di memoria OPcache ospitano comodamente un negozio 8/9 più il suo stack di moduli. Su PHP 8 la leva più grande è il JIT, che fa parte di OPcache: per un negozio limitato dalla CPU è il maggior guadagno gratuito offerto dalle versioni PHP più recenti, ed è un motivo per non accontentarsi di un hosting fermo alla 7.x.

La leva corrispondente lato MySQL/MariaDB è l'InnoDB buffer pool: la cache in RAM che evita letture da disco per le tabelle di prodotti e categorie. In my.cnf (o in un drop-in /etc/mysql/conf.d/):

[mysqld]
innodb_buffer_pool_size = 1G
innodb_buffer_pool_instances = 1
innodb_flush_log_at_trx_commit = 2

Dimensiona il buffer pool in modo che il working set ci stia: qualche centinaio di MB di dati di catalogo richiede almeno altrettanto pool, e una regola comoda su una macchina dedicata al DB è circa metà o due terzi della RAM di sistema. Il senso della scelta dell'hosting è che su hosting condiviso non puoi impostare nulla di tutto questo; su un VPS lo imposti una volta e ti tieni il vantaggio. Questo è l'intero argomento a favore di un VPS in tre righe di configurazione.

Un argomento di configurazione merita una guida separata: cache degli oggetti con Redis. Un modulo compatibile o un’integrazione di cache può consentire a PrestaShop di usare Redis per i dati memorizzati nella cache. L’archiviazione delle sessioni PHP si configura separatamente: attivare un modulo di cache non sposta automaticamente le sessioni in Redis. L’effetto sui tempi di risposta dipende dal carico e dalla configurazione. Installazione e compromessi sono trattati in Redis per PrestaShop e nella guida passo passo configurazione della cache Redis e guadagni di prestazione. Per scegliere l’hosting, verifica che Redis sia disponibile e che sia possibile configurare l’integrazione necessaria al tuo negozio.

Come verificare un hosting invece di fidarti del piano

Un buon hosting richiede comunque il controllo delle impostazioni di cache di PrestaShop dopo il deploy.

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_starttransfer} %{url_effective}\n" https://www.example.com/product-url
done

Le specifiche sono dichiarazioni; misura la realtà. Il test più pulito è mettere un vero negozio PrestaShop sull'hosting e leggerne il comportamento reale, non la brochure:

• Time to first byte (TTFB) su una pagina non in cache. Disattiva la cache full page, apri una pagina categoria e guarda il TTFB nel pannello Network del browser. È il segnale più grezzo della velocità con cui il server genera una pagina PrestaShop. Un buon VPS con PHP aggiornato e OPcache di solito resta ben sotto il mezzo secondo; un server condiviso in difficoltà può impiegare diverse volte tanto.
• I controlli integrati del pannello di amministrazione. Parametri avanzati → Informazioni riporta versione PHP, memory_limit e stato delle estensioni principali; la pagina Parametri avanzati → Prestazioni mostra la configurazione della cache. Questi dati ti dicono cosa ti ha dato davvero l'hosting rispetto a ciò che era pubblicizzato.
• PageSpeed solo dopo aver attivato la cache. Non giudicare un hosting da un'esecuzione PageSpeed a freddo: quel test mescola velocità server e ottimizzazione front-end. Abbiamo ottenuto un punteggio quasi perfetto da un vero negozio a pieno carico e documentato esattamente cosa ha fatto la differenza in PageSpeed 99/100 su un vero negozio PrestaShop con 130 moduli.

Se hai eseguito questi controlli e il negozio è ancora lento, probabilmente il collo di bottiglia non è l'hosting. Prima di aumentare il piano nella speranza di comprare una via d'uscita, fai diagnosi: il tuo negozio è lento? Come verificarlo e cosa fare, e ricorda che un database gonfiato negli anni rallenterà anche un server perfettamente valido (pulizia del database: perché il tuo negozio diventa più lento nel tempo).

Le domande sull'hosting che i proprietari di negozi fanno davvero

Più RAM o più CPU sono l'upgrade che rende PrestaShop più veloce? Di solito né l'una né l'altra, finché lo stack software non è aggiornato. Il rendering di una pagina è PHP per singola richiesta più MySQL, quindi i primi guadagni arrivano da PHP 8 con OPcache attivo e da un memory_limit sufficiente a completare la richiesta: non costano nulla e battono regolarmente l'acquisto di core. La CPU conta quando la stai saturando con concorrenza reale; la RAM conta soprattutto perché l'InnoDB buffer pool e i tuoi worker PHP devono starci entrambi. Correggi prima versione e OPcache, poi verifica se sei davvero limitato dalle risorse.

Un hosting più veloce risolverà un pannello di amministrazione lento? In parte. Il dolore dell'amministrazione di solito deriva da memory_limit (importazioni e traduzioni esauriscono 128M) e query lente, non dalla velocità grezza del server: quindi un hosting che ti permette di alzare memory_limit a 512M e usa un InnoDB buffer pool ottimizzato aiuta più di una CPU più grande. Se il front office è veloce ma l'amministrazione arranca, guarda memoria e database prima di dare la colpa al piano.

Posso usare Redis su hosting condiviso? Quasi mai: Redis richiede un demone in esecuzione e accesso shell, cose che i piani condivisi non offrono. Se un negozio è abbastanza grande da aver bisogno di Redis, di solito è abbastanza grande da giustificare un VPS, cioè la stessa macchina che ti permette di impostare da solo OPcache, memory_limit e InnoDB buffer pool. Conferma che Redis (o Memcached) sia disponibile prima di presumere che un piano sia "Redis-ready"; il quadro completo è in Redis per PrestaShop.

Un hosting PrestaShop gestito rende superfluo un modulo di performance? No: coprono livelli diversi. L'hosting gestito governa il server: versione PHP, OPcache, backup, patch. Non estrae CSS critico, non elimina selettori inutilizzati, non divide e differisce il tuo JavaScript e non serve AVIF: quello è lavoro sugli asset front-end che vive nell'applicazione, non nel server. Un hosting ottimizzato più una pipeline front-end come Performance Revolution è la combinazione che mantiene veloce un negozio reale; l'hosting da solo lascia intatto il problema del payload.

Come posso dimostrare che un hosting è veloce prima di migrare? Mettici sopra una vera pagina PrestaShop e leggi il TTFB su una pagina categoria a cache fredda (il ciclo curl qui sopra, oppure la scheda Network del browser). Un VPS con PHP aggiornato e OPcache di solito resta ben sotto il mezzo secondo; un server condiviso in difficoltà impiega diverse volte tanto. Poi controlla Parametri avanzati → Informazioni per verificare la versione PHP e il memory_limit effettivamente assegnati rispetto a quanto era pubblicizzato. Le specifiche sono promesse; il TTFB è la misura.

La raccomandazione, in un paragrafo

Per la grande maggioranza dei negozi PrestaShop: un VPS con 4GB di RAM, storage SSD/NVMe, PHP 8.2+ modificabile in autonomia, OPcache abilitato, MySQL/MariaDB locale, Redis disponibile e un datacenter vicino ai tuoi clienti. Parliamo di circa €20-40 al mese, e basta comodamente per la maggior parte dei negozi. Il denaro risparmiato rispetto a un hosting gestito premium è speso meglio su ciò che l'hosting non può correggere: un database pulito, moduli ben costruiti e una vera ottimizzazione dentro il negozio. Noi costruiamo direttamente la parte moduli di questo equilibrio, e puoi vedere come gestiamo il nostro stack nella nostra pagina sull'infrastruttura. L'hosting è la base: sceglilo in base a ciò che PrestaShop esegue davvero, non in base al piano con il numero più grande nella tabella comparativa.