Hosting WordPress: Cosa Stai Davvero Pagando

L’hosting WordPress si vende in una fascia di prezzo che va da circa £3 al mese a diverse centinaia, e i piani ai due estremi si descrivono con parole quasi identiche. Veloce. Sicuro. Con backup. Con assistenza. La specifica che permetterebbe a un acquirente di distinguerli, cioè quale ramo di PHP esegue il sito, quale motore di database c’è dietro, quanti livelli di cache esistono e quali di essi sono davvero attivi, manca quasi sempre dalla pagina da cui vi si chiede di comprare.

Quell’assenza fa parte del prodotto. “Gestito” è una categoria di marketing e non una categoria tecnica, e nessun ente di normazione la definisce. Due fornitori che usano la stessa parola possono differire su un object cache persistente attivo o meno, sul diritto di tenere il vostro plugin di cache, sulla possibilità che un backup esca dalla loro infrastruttura e sulla possibilità di aprire una shell.

Quel che segue è la specifica che quelle pagine omettono: cosa richiede WordPress, quali parti dello stack spostano la velocità delle pagine, cosa aggiunge e cosa toglie in silenzio l’hosting gestito, e fasce mensili realistiche per ogni livello.

Per che cosa state davvero pagando con l’hosting WordPress? Per quattro cose. Una versione di PHP e un motore di database conformi alla base pubblicata da WordPress. Livelli di cache che altrimenti dovreste installare e regolare da soli. Lavoro operativo, cioè aggiornamenti, staging, backup e firewall. E margine per le richieste che non si possono mettere in cache. Un sito vetrina non ha quasi bisogno di quest’ultima voce. Un negozio o un sito ad abbonamento ci spende la maggior parte del budget.

L’hosting WordPress è un nome di categoria, non una specifica

Lo scarto di prezzo dentro una sola categoria è il segnale. Due piani entrambi etichettati come hosting WordPress gestito possono stare a £20 e a £250 al mese, e il testo commerciale non spiegherà la differenza, perché la differenza è fatta di cose che quel testo non menziona.

All’estremità economica comprate una fetta di macchina condivisa con un pool PHP-FPM, una cache di pagina e un pannello di controllo. All’estremità costosa comprate calcolo isolato, un object cache persistente, un ambiente di staging, un firewall gestito, un team di assistenza che leggerà il vostro log degli errori e qualcuno contrattualmente responsabile quando un aggiornamento del core rompe un template.

Sono entrambi prodotti legittimi. Il problema è che l’acquirente non vede quale dei due ha davanti, quindi la decisione si prende sul prezzo e su siti di recensioni ordinati per commissione di affiliazione. L’esito è prevedibile in entrambe le direzioni. Siti vetrina finiscono su piani da £150 che non esauriranno mai, e negozi WooCommerce finiscono su piani da £5 che crollano al pagamento il primo sabato affollato.

La via d’uscita è comprare in base a quattro domande invece che al nome del livello: quale ramo di PHP, quali livelli di cache, quante richieste non memorizzabili in cache assorbe il piano e cosa succede ai vostri dati quando andate via.

Cosa richiede davvero WordPress da un server

WordPress pubblica una pagina di requisiti ed è breve, che è esattamente il motivo per cui viene saltata. Leggetela come una specifica d’acquisto, perché un piano che non la soddisfa è squalificato prima ancora di parlare di prestazioni.

La versione di PHP

La pagina dei requisiti di WordPress indica come base consigliata “PHP versione 8.3 o superiore”. Porta anche un avviso che conta più della raccomandazione: WordPress “continuerà a funzionare su PHP 7.4+ e MySQL 5.5.5+, ma quelle versioni hanno raggiunto la fine del ciclo di vita ufficiale e possono esporre il vostro sito a vulnerabilità di sicurezza”.

L’intera trappola sta in questa frase. WordPress non si rifiuterà di avviarsi su un ramo di PHP antico. Gira, sembra normale e sta in silenzio su un interprete che non riceve una correzione di sicurezza da anni.

Il database

La stessa pagina chiede “MariaDB 10.11+ o MySQL 8.0+”. I motori più vecchi funzionano ancora, ed è per questo che tanti siti ci girano sopra. Le statistiche d’uso pubblicate da WordPress mostrano che circa una installazione su sei dichiara una versione MySQL 5.x, ben sotto la soglia indicata, con il solo MySQL 5.7 che pesa per circa il 12 per cento dei siti che si dichiarano.

La conseguenza non è che il sito si rompe. È che perdete miglioramenti del motore che contano proprio per i carichi difficili da mettere in cache, e vi ereditate una migrazione che prima o poi dovrete comunque fare.

HTTPS e le estensioni PHP

HTTPS è indicato come “richiesto per ogni installazione”, non come consigliato. Un host che nel 2026 tratta ancora un certificato come un extra a pagamento vi sta dicendo qualcosa sul resto del piano.

Oltre a questo, il manuale di hosting di WordPress indica json e mysqli come richiesti, e curl, dom, exif, fileinfo, hash, igbinary, imagick, intl, mbstring, openssl, xml e zip come fortemente consigliati. Due vale la pena nominarli a un commerciale. Senza zip, i pacchetti di aggiornamento di plugin e core non possono essere decompressi. Senza imagick, i caricamenti multimediali ripiegano su una libreria di immagini più debole e le vostre immagini escono peggiori prima ancora che qualcuno tocchi un plugin di ottimizzazione.

La versione di PHP è la voce più redditizia della fattura

Di tutto ciò che un host controlla, il ramo di PHP ha il miglior rapporto fra effetto e sforzo. Sulla maggior parte dei pannelli è un menu a tendina. Nulla viene ricostruito, nulla viene migrato, e un sito già compatibile inizia semplicemente a girare su un interprete più veloce e meglio supportato.

Il motivo per cui resta invariato per anni è organizzativo e non tecnico. Nessuno se ne occupa. L’agenzia che ha costruito il sito è passata ad altro, l’host non lo cambia unilateralmente perché un errore fatale in un plugin abbandonato diventerebbe colpa sua, e l’azienda non ha motivo di pensare a un numero che non le è mai stato mostrato.

Quindi la prima domanda da fare a un potenziale host non riguarda la velocità. Riguarda quale ramo di PHP il piano esegue per impostazione predefinita, quali rami offre e se potete cambiarlo da soli senza aprire un ticket. Un host che offre solo un ramo che WordPress non consiglia più ha risposto a tutte le altre domande nello stesso momento.

Provate in staging, non cambiate mai la produzione. Un sito che passa da PHP 7.4 a 8.3 fa emergere di solito due o tre avvisi di deprecazione da plugin non mantenuti, e quello è il costo vero. Mettete a budget da mezza giornata a una giornata di sviluppo, trattata più a fondo nella nostra guida su tariffe degli sviluppatori WordPress e domande da fare.

La metà sicurezza dell’argomento PHP

Le prestazioni sono la ragione che si dà per aggiornare PHP. La sicurezza è la ragione che conta davvero, ed è misurabile invece che opinabile.

PHP pubblica il proprio calendario delle versioni supportate. Ogni ramo riceve due anni di supporto attivo e altri due anni di sole correzioni di sicurezza. A settembre 2026 questo mette PHP 8.2 in modalità sola sicurezza fino al 31 dicembre 2026, e PHP 8.3 in sola sicurezza fino al 31 dicembre 2027 dopo che il supporto attivo è terminato il 31 dicembre 2025. PHP 8.4 resta in supporto attivo fino al 31 dicembre 2026 con correzioni di sicurezza fino al 31 dicembre 2028, e PHP 8.5 fino al 31 dicembre 2027 con correzioni fino al 31 dicembre 2029. Tutto ciò che è più vecchio è finito: PHP 8.1 si è chiuso il 31 dicembre 2025, PHP 8.0 il 26 novembre 2023 e PHP 7.4 il 28 novembre 2022.

Mettete tutto questo di fronte a ciò che i siti WordPress eseguono davvero. La pagina delle statistiche di WordPress riporta circa il 38,8 per cento delle installazioni su un ramo completamente a fine vita, con circa il 23,2 per cento ancora su PHP 7.4 o precedente. Solo il 36,4 per cento circa raggiunge la base PHP 8.3 consigliata da WordPress, e un altro 24,8 per cento sta su PHP 8.2, che perde il supporto di sicurezza alla fine di quest’anno.

La maggioranza dei siti WordPress gira quindi su un interprete che non riceve correzioni di sicurezza o che è a pochi mesi da quello stato, e quasi sempre si tratta di un’impostazione di hosting che nessuno ha guardato. Correggerla costa meno di una licenza di plugin, ed è per questo che la nostra checklist di hardening della sicurezza WordPress la tratta come primo passo.

I livelli di cache, nell’ordine in cui una richiesta li incontra

Quasi ogni promessa di prestazioni fatta da un host è una promessa sulla cache, e quasi ogni acquirente la sente come un’unica promessa indifferenziata. I livelli distinti sono quattro, stanno in un ordine fisso e ciascuno risparmia un tipo diverso di lavoro. L’ordine qui sotto è quello che una singola richiesta attraversa, e una richiesta servita da un livello precedente non raggiunge mai i successivi.

La cache di edge o CDN

La prima cosa che una richiesta incontra è una cache del tutto esterna al vostro server, su una rete di punti di presenza vicini al visitatore. Se la risposta è già memorizzata lì, il vostro host non vede affatto la richiesta.

Questo livello risparmia distanza di rete oltre che calcolo. Un visitatore di Manchester che raggiunge un nodo edge a London evita un viaggio transatlantico. Per le risorse statiche è quasi gratis e conviene sempre. Per l’HTML è potente ma condizionata, perché all’edge va detto quali risposte sono personali e non vanno mai condivise.

La cache di pagina intera

Il secondo livello memorizza l’HTML finito di una pagina in modo che PHP e il database non girino di nuovo. Il manuale di hosting di WordPress consiglia un reverse proxy come NGINX o Varnish, che “memorizza l’output direttamente nella memoria del server o sul disco”, e aggiunge la regola che decide se il livello funziona: “è una buona idea escludere dalla cache tutti gli utenti autenticati, perché devono vedere contenuti personalizzati”.

È il livello che fa fare bella figura all’hosting economico. Quando funziona, al visitatore viene servito un file, e la versione di PHP, il motore di database e il numero di plugin smettono di contare per quella richiesta, perché nessuno di essi viene eseguito.

L’object cache

Il terzo livello mette in cache i risultati delle singole query al database e i valori calcolati. WordPress lo fornisce di serie ma non in modo persistente. La documentazione di WP_Object_Cache è esplicita: “Per impostazione predefinita l’object cache non è persistente. Questo significa che i dati memorizzati nella cache risiedono solo in memoria e solo per la durata della richiesta.”

Renderlo persistente significa metterci dietro Redis o Memcached tramite un drop-in, il che trasforma la cache da qualcosa che viene ricostruito a ogni caricamento di pagina in qualcosa di condiviso fra richieste e visitatori. È il livello che conta quando le pagine smettono di essere memorizzabili per intero, ed è quello che più spesso manca nei piani economici.

La cache di opcode

Il quarto livello è OPcache, che tiene in memoria condivisa il bytecode compilato dei vostri file PHP perché l’interprete non debba rianalizzarli e ricompilarli a ogni richiesta. Il manuale di hosting afferma che “per gli ambienti WordPress di produzione si consiglia che OPcache sia abilitato per le richieste web e dimensionato per il sito o per la piattaforma di hosting”.

C’è una conseguenza sul rilascio. Poiché OPcache tiene codice compilato, un rilascio deve azzerarlo o invalidare i file modificati, altrimenti il server continua a eseguire la versione precedente. Un host che non sa dirvi come viene invalidato OPcache è un host in cui un aggiornamento di plugin sembra non fare nulla per diversi minuti.

Perché un sito vetrina è veloce su quasi qualsiasi host

Seguite quei quattro livelli fino in fondo e la conclusione è scomoda per il settore dell’hosting. Se ogni visitatore è anonimo e ogni pagina è memorizzabile, la cache di pagina intera risponde a quasi tutto il traffico, e la scheda tecnica della macchina dietro pesa pochissimo.

Ecco perché un sito aziendale di cinque pagine su un piano da £4 con una cache di pagina decente può registrare un tempo di risposta del server migliore di un sito appesantito su un piano da £200. Il sito economico serve file. Quello costoso esegue PHP.

Il numero da guardare è il tempo al primo byte, che di per sé non è un Core Web Vital. La panoramica sui Web Vitals di Google lo colloca fra le metriche di supporto, utili per “diagnosticare problemi di LCP” causati da tempi di risposta del server lenti. È esattamente la fetta di velocità di pagina che un host controlla.

WordPress è d’accordo abbastanza da averlo scritto nel core. Il test di Salute del sito sulla cache di pagina intera aggiunto in WordPress 6.1 verifica “se il sito usa una soluzione di cache di pagina intera e se il tempo di risposta è accettabile”, con una soglia predefinita di 600 millisecondi. Se il vostro sito sta sopra quella soglia con una cache di pagina presumibilmente attiva, la cache non funziona, e più CPU non lo maschererà.

Per un sito vetrina, quindi, un passaggio a un hosting superiore è di solito l’acquisto sbagliato. A renderlo lento sono più spesso un’immagine di apertura sovradimensionata, un page builder che consegna centinaia di kilobyte di CSS o sei pesi di carattere, che è l’argomento del nostro confronto fra Elementor e un tema su misura.

Il traffico autenticato e WooCommerce rompono il modello

Tutto quanto sopra presuppone che la cache di pagina possa rispondere. Nel momento in cui i visitatori si autenticano, quel presupposto crolla e l’economia dell’hosting si rovescia.

WooCommerce lo documenta direttamente. Le sue indicazioni sulla cache impongono di escludere Carrello, Il mio account e Pagamento dalla cache di pagina perché quelle pagine “devono restare dinamiche, dato che mostrano informazioni specifiche del cliente attuale e del suo carrello”. Elencano anche i cookie che devono aggirare la cache, fra cui woocommerce_cart_hash, woocommerce_items_in_cart e wp_woocommerce_session_, e consigliano di escludere _wc_session_ dalla cache del database.

Letto come una specifica di hosting, dice qualcosa di brutale. In un negozio, le pagine che generano fatturato sono proprio quelle che la cache di pagina non può toccare. Catalogo e schede prodotto si possono mettere in cache per i visitatori anonimi. Carrello e pagamento no, mai, per nessuno.

Lo stesso vale per i siti ad abbonamento, le piattaforme didattiche, i forum e qualsiasi sito con un’area clienti. Una volta impostato un cookie di sessione, la maggior parte dei plugin di cache smette del tutto di servire HTML memorizzato a quel visitatore, quindi ogni clic esegue PHP e interroga il database. È qui che l’object cache smette di essere un’ottimizzazione e diventa portante, ed è qui che un piano economico fa male in un modo che nessun test sintetico sulla home rivela, come spiegato in perché il vostro negozio WooCommerce è lento.

Cosa comprende davvero l’hosting WordPress gestito

Tolti gli aggettivi, l’hosting gestito si riduce a un pacchetto piuttosto costante di lavoro operativo. Vale la pena dare un prezzo onesto a quel lavoro, perché per un’azienda senza personale tecnico spesso costa meno comprato che fatto in casa.

Gli aggiornamenti

I piani gestiti di solito applicano gli aggiornamenti del core automaticamente, a volte anche quelli dei plugin, occasionalmente con un controllo visivo di regressione prima e dopo. La cosa utile da sapere è quanto WordPress fa già gratis.

WordPress aggiorna in automatico le release minori del core e i file di traduzione per impostazione predefinita da anni, e dalla 5.6 le nuove installazioni hanno gli aggiornamenti automatici attivi sia per le release minori sia per quelle maggiori del core, a meno che non venga rilevato un checkout di controllo versione, mentre le installazioni esistenti mantengono il comportamento precedente. La parte a pagamento quindi non sono gli aggiornamenti minori del core. Sono gli aggiornamenti dei plugin, il ripristino quando uno si rompe e qualcuno che si accorge che si è rotto.

Staging e backup

Un ambiente di staging con un clic ha un valore reale ed è davvero noioso da costruirsi da soli. Giudicatelo su due dettagli invece che sulla sua esistenza: se riportare lo staging in produzione sovrascrive il database live, cosa che butterebbe via ordini e commenti raccolti dopo la copia, e se il sito di staging è bloccato ai motori di ricerca e all’invio di email.

Firewall e scansione antimalware

La maggior parte dei piani gestiti include un firewall applicativo sull’edge e una qualche forma di scansione antimalware. Il firewall è valore reale, perché la correzione virtuale a livello di rete compra tempo fra la divulgazione di una vulnerabilità di un plugin e il vostro aggiornamento.

La scansione è più debole di quanto sembri. Di solito rileva firme note di file dannosi, quindi intercetta le infezioni di massa e manca quelle mirate. Trattatela come un rilevatore di fumo e non come una serratura, e tenete il lavoro di hardening dalla vostra parte della linea.

Cosa toglie l’hosting gestito

Le restrizioni sono la metà che nessuno legge, e di solito pesano più delle funzionalità. Esistono per ragioni difendibili, ma sono le ragioni del fornitore, non le vostre.

L’esempio pubblicato più chiaro è l’elenco dei plugin non consentiti di WP Engine, che vieta intere categorie invece dei singoli colpevoli. I plugin di cache sono vietati perché “possono entrare in conflitto con la struttura di cache integrata della nostra piattaforma”. I plugin di backup sono vietati perché “appesantiscono inutilmente il vostro sito”. I plugin di articoli correlati sono vietati come “estremamente pesanti sul database”. I plugin con vulnerabilità documentate sono vietati del tutto, così come quelli che duplicano funzioni della piattaforma.

Ognuna di queste è una decisione tecnica ragionevole. Nel complesso significano che il vostro sito non è portabile come avevate supposto. Se la vostra installazione dipende dalla configurazione di uno specifico plugin di cache, quella configurazione non trasloca con voi.

L’accesso alla shell è l’altra omissione comune. Molti piani gestiti non forniscono alcun SSH, o una shell limitata senza WP-CLI, il che trasforma un lavoro di routine come una sostituzione di massa dopo un cambio di dominio in un ticket di assistenza. Altri due punti colgono di sorpresa: i processi di lunga durata sono spesso limitati, quindi un import di 50.000 prodotti va spezzato, e la posta in uscita è spesso bloccata o limitata, nel presupposto che un sito compromesso verrà usato per lo spam.

Le promesse di prestazioni che non sopravvivono a una prova

Il marketing dell’hosting vive su un piccolo insieme di affermazioni che si sfaldano appena chiedete cosa sia stato misurato.

“Venti volte più veloce” quasi mai nomina un termine di paragone. Più veloce di cosa, su quale pagina, con quali plugin, con quale concorrenza? Senza quei quattro elementi, il numero è un rapporto fra due quantità senza nome.

“Banda illimitata” sta accanto a un limite mensile di visite nella stessa tabella. La banda comunque è raramente il vincolo di un sito WordPress. Il vincolo è l’esecuzione simultanea di PHP, che il piano di solito non menziona affatto.

“99,9 per cento di disponibilità” suona assoluto e non lo è. Su un mese di trenta giorni consente circa 43 minuti di fermo. Tre nove è un valore normale per l’hosting condiviso, quattro nove consente circa quattro minuti al mese, e la differenza è quella fra un fastidio e un’interruzione che nessuno nota. Leggete cosa paga davvero il rimborso quando l’obiettivo non è raggiunto, tema che abbiamo trattato a parte in gli SLA di disponibilità che significano qualcosa.

L’ultima affermazione è la più comune e la più fuorviante: uno screenshot di un test di velocità su una home in cache. Quello misura la cache di pagina, non l’host, e la cache di pagina è l’unico componente più o meno equivalente ovunque.

Come si prova un host per bene

Provare l’hosting non è difficile, ma va fatto sul percorso che mette davvero sotto sforzo il server. Cinque passi, in ordine.

Primo, provate un percorso non in cache. Aggiungete una stringa di query unica per aggirare la cache di pagina, oppure richiedete una pagina che non viene mai messa in cache, come un carrello o una pagina account. Se non riuscite a fare una richiesta che esegua PHP, state provando un file server.

Secondo, ripetete. Una singola richiesta non dice nulla sulla varianza, ed è nella varianza che l’hosting economico si mostra. Prendete almeno venti campioni e leggete il 75esimo percentile, la statistica che Google usa per i dati sul campo.

Terzo, provate da dove sono i vostri visitatori. Una risposta misurata da un data center accanto al server non è la risposta che ricevono i vostri clienti a Leeds.

Quarto, provate sotto concorrenza. Lanciate dieci o venti richieste simultanee non memorizzabili. È l’unica prova che rivela l’esaurimento dei worker PHP, ed è l’esaurimento dei worker che manda giù un negozio durante una promozione.

Quinto, confrontate cose uguali: stesso ramo di PHP, stesso insieme di plugin, stesso tema, stesso volume di contenuti. Una migrazione che cambia lo stack di plugin insieme all’host non ha dimostrato nulla né sull’uno né sull’altro. Se volete questo lavoro su un sito reale invece che su un host candidato, è esattamente ciò che fa un audit delle prestazioni WordPress.

Quali Core Web Vitals l’hosting sposta davvero

I Core Web Vitals sono il punto in cui promesse di hosting e posizionamento nella ricerca si confondono, quindi conviene essere precisi su quale metrica un server possa influenzare.

Sono tre, valutate al 75esimo percentile dei caricamenti e divise fra mobile e desktop. Largest Contentful Paint misura il caricamento ed è buono a 2,5 secondi o meno, da migliorare fra 2,5 e 4,0 secondi, scarso oltre 4,0. Interaction to Next Paint misura la reattività ed è buono a 200 millisecondi o meno, da migliorare fino a 500 millisecondi, scarso sopra. Cumulative Layout Shift misura la stabilità visiva ed è buono a 0,1 o meno, da migliorare fino a 0,25, scarso oltre. First Input Delay è stato ritirato e sostituito da INP, diventato un Core Web Vital stabile nel 2024.

L’hosting ne sposta esattamente una in modo diretto. Il tempo di risposta del server fa parte dell’LCP, quindi un host che ne toglie 400 millisecondi toglie 400 millisecondi di LCP a ogni visitatore. Su un host lento può essere la differenza fra passare e non passare.

Non fa quasi nulla per il CLS, che nasce da immagini senza dimensioni e da font caricati tardi, e pochissimo per l’INP, dominato dal JavaScript sul thread principale. La regola è che se l’LCP è scarso e la vostra risposta server non in cache sta sopra la soglia di 600 millisecondi che WordPress segnala, l’hosting è parte del problema. Se la risposta è comoda e l’LCP resta scarso, il difetto è nella pagina, e la nostra guida per superare i Core Web Vitals nel 2026 è il posto migliore dove spendere il budget.

I backup, e la parte che nessuno controlla

Ogni piano sopra il più economico pubblicizza i backup. Quasi nessuno, comprandone uno, fa le domande che decidono se quel backup vale qualcosa.

Se qualcuno ne abbia mai ripristinato uno

L’NCSC lo dice chiaramente nella sua guida per le piccole organizzazioni: una volta fatto un backup, “è importante sapere come ripristinarlo e verificare che contenga tutti i vostri dati importanti”. Un backup non provato è una convinzione, non un controllo.

Chiedete al fornitore come si avvia un ripristino, quanto dura per un sito della vostra dimensione e se ripristinare il database ripristina anche la cartella dei caricamenti. Poi fatelo una volta in staging, prima di averne bisogno. Il guasto da cercare è un ripristino che restituisce i file ma non il database, oppure uno che riesce e perde in silenzio tutto ciò che è stato creato dopo la copia.

Conservazione e frequenza

Backup giornalieri con sette giorni di conservazione sembrano generosi finché non si considera come un sito WordPress si guasta davvero. Un sito deturpato si nota in poche ore. Una compromissione che inietta in silenzio link di spam in vecchi articoli si nota in settimane, e a quel punto ogni copia conservata contiene l’iniezione.

Trenta giorni sono una soglia minima più utile per qualsiasi uso commerciale, e una copia mensile separata è un’assicurazione a buon mercato. Un negozio ha inoltre bisogno di un intervallo di backup del database commisurato al volume di ordini, perché perdere quattro ore di ordini non è lo stesso genere di problema che perdere quattro ore di modifiche al blog.

Dove sta la copia, e in quale formato

L’altro punto dell’NCSC è che un backup che resta attaccato al sistema in produzione non è separato: un dispositivo che contiene backup “non dovrebbe restare collegato al vostro dispositivo quando non è in uso”, perché ciò che compromette la sorgente può raggiungerlo. Applicato all’hosting, un backup conservato sullo stesso account e ripristinabile solo dallo stesso pannello condivide il destino di ciò che protegge.

Il formato è la versione più sottile dello stesso problema. Se l’unico modo di leggere un backup è il pulsante di ripristino del fornitore, avete una comodità e non una copia portabile. La prova è se potete scaricare oggi un semplice dump SQL e un archivio di file che uno sviluppatore competente potrebbe rimettere in piedi altrove. Se no, la migrazione smette di essere una decisione tecnica e diventa una trattativa.

Dove risiedono i dati, e perché conta per gli acquirenti britannici

Le decisioni di hosting sono decisioni di protezione dei dati, e per un’azienda britannica la domanda non è dove è registrata la società ma dove riposano i dati personali e chi può raggiungerli.

La guida dell’ICO sui trasferimenti internazionali fissa un test in tre passi. Se il GDPR britannico si applica al vostro trattamento, se siete voi ad avviare il trasferimento e se l’organizzazione ricevente è un soggetto giuridico distinto, state facendo un trasferimento soggetto a restrizioni. L’ICO è esplicita nel dire che le regole “si applicano a tutti i trasferimenti soggetti a restrizioni, anche a quelli piccoli e poco frequenti” e coprono ogni organizzazione che tratta dati personali, “compresi i lavoratori autonomi e i liberi professionisti”.

Notate cosa conta come trasferimento. L’ICO vi include sia l’invio di dati personali sia il “renderli accessibili” a un’organizzazione fuori dal Regno Unito. Un team di assistenza all’estero con accesso alla vostra amministrazione, o un backup fuori sede replicato in un’altra regione, possono soddisfare quella definizione.

Ogni trasferimento soggetto a restrizioni va coperto da una di tre cose: norme britanniche di adeguatezza per la destinazione, garanzie appropriate come l’International Data Transfer Agreement, l’Addendum o norme vincolanti d’impresa, oppure un’eccezione. Quando vi appoggiate a garanzie, l’ICO si aspetta anche una valutazione del rischio del trasferimento che mostri che la protezione non è sensibilmente inferiore dopo. Niente di tutto ciò rende inutilizzabile un host estero. Lo rende una decisione da documentare, e documentare costa molto meno prima di migrare che durante una richiesta di accesso.

Cosa deve dire un contratto con il responsabile del trattamento

Il vostro host è responsabile del trattamento e voi siete il titolare, quindi un contratto scritto non è facoltativo. L’ICO elenca cosa deve contenere quel contratto, e quattro delle sue clausole si leggono direttamente come domande di hosting.

I sub-responsabili vengono per primi. Ai sensi dell’articolo 28(3)(d) il responsabile non può ingaggiare un altro responsabile senza la vostra autorizzazione, deve informarvi dei cambiamenti previsti perché possiate opporvi, e deve imporre obblighi equivalenti lungo la catena. In termini di hosting sono il CDN, la destinazione dei backup, il relay di posta e il fornitore cloud sottostante. Chiedete l’elenco.

La sicurezza viene per seconda. L’articolo 28(3)(c) richiede misure conformi all’articolo 32, e l’ICO precisa cosa comprendono: cifratura e pseudonimizzazione, resilienza dei sistemi di trattamento, “la capacità di ripristinare l’accesso ai dati personali in caso di incidente” e “processi per verificare e valutare regolarmente l’efficacia delle misure”. È il collaudo dei ripristini scritto nella legge invece che in un articolo di buone pratiche.

Terza è l’uscita. Ai sensi dell’articolo 28(3)(g) il responsabile deve, a vostra scelta, cancellare o restituire tutti i dati personali alla fine del contratto e cancellare le copie esistenti. Un fornitore i cui backup non possono lasciare la piattaforma ha un problema contrattuale oltre che pratico. Quarta è la verifica, che ai sensi dell’articolo 28(3)(h) vi dà diritto alle informazioni necessarie a dimostrare la conformità e alle sue certificazioni e relazioni.

I livelli, e quanto costano nel Regno Unito

Quattro livelli coprono quasi ogni sito WordPress, e i confini fra loro sono fissati dal carico non memorizzabile piuttosto che dal traffico. Le fasce qui sotto sono quel che gli acquirenti britannici pagano tipicamente al mese. Sono fasce di categoria e non il listino di un singolo fornitore, quindi trattatele come una verifica di buon senso su un preventivo e non come un preventivo.

Hosting condiviso, £3 a £15 al mese

Perfettamente adeguato per un sito vetrina memorizzabile, e davvero poco conveniente appena qualcuno si autentica. Condividete la capacità PHP con vicini che non vedete, quindi sotto carico morde la varianza e non la media. Controllate prima il ramo di PHP, perché è in questo livello che si concentrano gli interpreti a fine vita.

WordPress gestito, £20 a £400 al mese

La scelta predefinita giusta per siti di contenuti e piccoli negozi. Comprate aggiornamenti, staging, un firewall, un object cache persistente e un team di assistenza, e lo pagate con le restrizioni viste sopra. La fascia da £20 a £100 copre un singolo sito di traffico moderato. Oltre, di solito state pagando per più siti, più visite o più worker PHP.

VPS o cloud con il vostro stack, £15 a £120 più la gestione

Un’istanza cloud modesta costa £15 a £120 al mese, ma la macchina è la parte economica. Qualcuno deve applicare le patch al sistema operativo, regolare il reverse proxy, far girare l’object cache e occuparsi dei backup, e comprare quel lavoro costa altri £150 a £600 al mese. Ne vale la pena quando il carico non memorizzabile è reale, o quando il vostro stack ha requisiti che una piattaforma gestita vieta.

Infrastruttura su misura, da £400 al mese in su

Distribuzioni multiregione, eventi ad alta concorrenza, residenza dei dati rigida, o un’architettura in cui WordPress è un componente fra tanti. L’hosting smette di essere una decisione di prodotto e diventa parte della costruzione, che è come lo affrontiamo dentro un incarico di sviluppo di siti web.

Dimensionare sulle richieste non memorizzabili, non sulle pagine viste

I piani di hosting si vendono a visite mensili perché è un numero che gli acquirenti riconoscono. È quasi inutile per dimensionare la capacità, perché 100.000 pagine viste anonime in cache non costano quasi nulla mentre 10.000 pagine viste autenticate possono saturare un piccolo server.

Il numero che conta è quello delle richieste non memorizzabili simultanee, e l’aritmetica è semplice. Un worker PHP gestisce una richiesta non memorizzabile alla volta. I worker necessari sono all’incirca il picco di richieste non memorizzabili al secondo moltiplicato per il tempo medio di risposta di PHP in secondi. Venti richieste non memorizzabili al secondo da 400 millisecondi ciascuna richiedono circa otto worker per stare al passo, e ne volete almeno la metà in più come margine.

Fate quindi due domande a cui nessuna pagina di piani risponde: quanti worker PHP esegue questo piano, e qual è il limite di memoria per processo? Entrambi i numeri esistono e nessuno dei due viene di solito pubblicato. L’assistenza normalmente ve li dirà se chiedete direttamente, e la risposta dice più del piano di ogni benchmark sulla pagina.

Poi stimate onestamente il vostro lato. Contate la quota di sessioni autenticate, il traffico di pagamento e account nella vostra ora di punta invece che in quella media, e tutto il traffico admin-ajax o REST che i vostri plugin generano in background, invisibile nelle analitiche e molto visibile in un log del server.

Numero di plugin e volume editoriale sono decisioni di hosting

Due cose dentro il sito determinano quanto hosting serve, ed entrambe vengono di solito trattate come decisioni di contenuto prese da persone che la fattura non la vedono mai.

La prima è lo stack di plugin. Ogni plugin attivo aggiunge opzioni caricate automaticamente a ogni richiesta, eventi pianificati che scattano sulle richieste dei visitatori perché il cron di WordPress non è un vero cron, e query per ogni costruzione di pagina. Trenta plugin su un sito vetrina in cache si sopportano. Trenta plugin su un negozio dove non si mette in cache nulla significano trenta plugin eseguiti a ogni passo del pagamento. Il core di WordPress ha un’idea approssimativa di quando questo inizia a mordere: il controllo di Salute del sito sull’object cache persistente suggerisce l’object caching quando un sito supera soglie come 2.000 articoli, 2.000 utenti o 600 opzioni caricate automaticamente.

La seconda è il volume editoriale. Le revisioni si accumulano senza limite per impostazione predefinita, le librerie multimediali arrivano a decine di migliaia di file con diverse dimensioni generate ciascuno, e entrambe gonfiano il database e la finestra di backup. Un sito che pubblica ogni giorno da cinque anni è un problema di hosting sostanzialmente diverso dallo stesso progetto che pubblica ogni mese, e nulla sulla pagina del piano lo riflette. Verificare la costruzione, non il piano, è ciò che uno sviluppatore WordPress dovrebbe fare prima di quotare una migrazione.

Scegliere, in ordine

Seguite questa sequenza e la decisione di solito si prende da sola. Stabilite quale quota del vostro traffico non è memorizzabile, perché quel solo numero sceglie il vostro livello. Verificate che il ramo di PHP e la versione del database raggiungano la base pubblicata, perché un piano che lì fallisce è squalificato a prescindere dal prezzo. Stabilite quali livelli di cache sono inclusi e quali dovete fornire voi. Chiedete dove vivono i backup, in quale formato e se potete scaricarne uno oggi. Poi leggete le clausole sul responsabile del trattamento per sub-responsabili, posizione dei dati e cancellazione a fine contratto. Solo dopo tutto questo il prezzo significa qualcosa, perché fino ad allora state confrontando prodotti che non sono lo stesso prodotto.

Mecanik lo fa come blocco di lavoro a prezzo fisso prima di ogni migrazione, di solito insieme a un incarico di sviluppo di siti web, e se ne fa carico come assistenza continuativa attraverso il nostro servizio di sviluppatore WordPress a noleggio. Se state valutando dove sta andando la piattaforma stessa, il nostro approfondimento su WordPress 7.0 e il client IA nel core accompagna bene questo.

Domande frequenti

Quanto dovrebbe costare l’hosting WordPress nel Regno Unito? Dipende quasi interamente da quanto del vostro traffico può essere messo in cache. Un sito vetrina con visitatori anonimi è servito bene da £3 a £15 al mese su hosting condiviso. Un sito di contenuti o un piccolo negozio di solito appartiene all’hosting WordPress gestito da £20 a £100 al mese, che sale a £100 a £400 per piani carichi o multisito. Un negozio o un sito ad abbonamento con molto traffico autenticato richiede tipicamente un VPS o uno stack cloud da £15 a £120 per la macchina più £150 a £600 al mese se lo gestisce qualcun altro.

L’hosting WordPress gestito vale la spesa in più? Sì, se non avete una persona per le operazioni, perché comprate aggiornamenti, staging, backup, un firewall e un object cache persistente che altrimenti dovreste configurare da soli. Lo scambio sono restrizioni reali. I fornitori vietano abitualmente plugin di cache, di backup e pesanti sul database, spesso negano l’accesso alla shell, limitano i processi di lunga durata e bloccano la posta in uscita. Verificate quei limiti rispetto alla vostra installazione prima di impegnarvi, non dopo.

Quale versione di PHP serve a WordPress nel 2026? WordPress consiglia PHP 8.3 o superiore. Funziona ancora su PHP 7.4 e successivi, ma quei rami sono a fine vita e non ricevono correzioni di sicurezza. PHP 8.1 si è chiuso il 31 dicembre 2025, PHP 8.0 il 26 novembre 2023 e PHP 7.4 il 28 novembre 2022, mentre PHP 8.2 è in modalità sola sicurezza fino al 31 dicembre 2026. Circa il 38,8 per cento delle installazioni WordPress dichiara ancora un ramo completamente a fine vita.

Un hosting migliore migliora i Core Web Vitals? Solo una delle tre, e solo indirettamente. Il tempo di risposta del server fa parte del Largest Contentful Paint, quindi un host più veloce abbassa l’LCP per ogni visitatore. Non fa quasi nulla per il Cumulative Layout Shift, che nasce da immagini senza dimensioni e da font caricati tardi, e pochissimo per l’Interaction to Next Paint, dominato dal JavaScript sul thread principale. Se la vostra risposta server è già comoda, il problema restante è nella pagina.

Perché il mio negozio WooCommerce è lento su un piano che si dice veloce? Perché le pagine che contano non possono essere messe in cache. WooCommerce richiede che Carrello, Il mio account e Pagamento restino dinamici, e imposta cookie di sessione che aggirano la cache di pagina per gli acquirenti autenticati. Il test di velocità sulla vostra home misura un file in cache, mentre il pagamento esegue PHP e interroga il database a ogni richiesta. La capacità per le richieste non memorizzabili, non il numero della home in cache, è ciò che un negozio compra davvero.