Hosting da 44,50 € a 7 € al mese: e va più veloce di prima
Quando un sito è lento, la risposta più comoda del mondo è «serve un server più potente». È comoda per chi te la dà, perché sposta il problema su una fattura mensile invece che su un lavoro. Su un e-commerce complesso ho fatto il contrario, e i numeri stanno qui sotto.
Il conto, per cominciare
44,50 € al mese diventati 7. Sono 534 euro all'anno che diventano 84: 450 euro l'anno risparmiati, l'85% in meno. E il sito, sul piano da sette euro, è più veloce di quanto fosse su quello da quarantaquattro. Non uguale: più veloce.
Cosa compri davvero quando paghi di più
Un hosting più caro ti dà più potenza di calcolo e più memoria. Non ti dà velocità: ti dà tolleranza allo spreco. Se ogni pagina del tuo sito chiede al server cento cose quando ne bastavano dieci, un server più potente le esegue comunque, solo un po' meno lentamente. Il lavoro inutile resta lì, e continui a pagarlo ogni mese, per sempre.
Perché te lo consigliano lo stesso
Perché è la risposta più rapida e la meno rischiosa per chi la dà. Dire «passa al piano superiore» si fa in due minuti, non richiede di aprire il codice, non richiede di ammettere che quel sito è costruito male, e produce un miglioramento piccolo ma reale — abbastanza da chiudere la conversazione. È il modo migliore che esista di lavarsi le mani facendoti pagare il lavaggio.
Cosa ho cambiato al posto del server
Le chiamate al server. Ogni pagina ne faceva un numero enorme, molte identiche fra loro, ripetute a ogni caricamento perché nessuno si era chiesto se servissero. Ottimizzate quelle che servivano, eliminate quelle ridondanti.
E i componenti aggiuntivi
Rimossi e riscritti. Sette o otto componenti diversi facevano ognuno una cosa piccola, e ognuno si portava dietro il proprio codice, le proprie tabelle, le proprie chiamate — spesso per fare la stessa identica operazione dell'altro. Le funzioni in comune sono state unificate in un pezzo solo, scritto una volta. Il risultato non è «meno plugin»: è meno lavoro chiesto al server per ottenere la stessa cosa.
I numeri del prima e dopo
Le richieste di rete per aprire la home sono passate da 284 a 34. Il peso di una pagina da 4,8 MB a 0,4. Il tempo perché comparisse il contenuto principale da 8,7 a 2,7 secondi. Il thread principale del browser, che restava bloccato 592 millisecondi, adesso non si blocca praticamente mai. Il punteggio di Google su telefono è passato da 47 a 94.
Come è stata scelta la misura nuova
Non a occhio, e non prima: dopo. Messo online il sito nuovo, il provider ha lasciato girare il traffico vero e ha analizzato medie e picchi di consumo reale. Solo a quel punto ha consigliato il piano — e ne ha consigliato uno volutamente sovradimensionato, per stare larghi. Quel piano da sette euro regge circa 300 visite contemporanee.
E non è un sitarello
È un e-commerce con centinaia di prodotti, varianti, magazzino, spedizioni, pagamenti, più funzioni costruite su misura che nessun negozio standard ha. Non è il caso facile: è esattamente il tipo di sito per cui ti direbbero che «serve un server serio». Va alla velocità della luce su un piano condiviso da sette euro.
Come capire se stai pagando una toppa
Tre segnali, e li puoi controllare oggi. Primo: il sito è lento anche quando non c'è nessuno — se è lento alle tre di notte non è un problema di capacità, è un problema di come è fatto. Secondo: hai già cambiato piano almeno una volta e il miglioramento è durato poco. Terzo: nessuno ti ha mai mostrato un numero prima di consigliarti di spendere di più.
Quando invece il server serve davvero
Esiste, e sarebbe disonesto non dirlo. Se il sito è costruito bene e il traffico è cresciuto sul serio, la potenza in più serve e va comprata. La differenza sta tutta nell'ordine: prima si misura cosa consuma e perché, poi si decide. Chi ti propone il piano superiore senza averti mostrato dove va il tempo, sta indovinando con i tuoi soldi.
Il dettaglio tecnico: dove se ne va davvero il tempo del server
Il numero da guardare per primo è il TTFB (Time To First Byte): quanto ci mette il server a cominciare a rispondere, prima ancora che il browser scarichi qualsiasi cosa. Lo leggi gratis con curl -o /dev/null -s -w "%{time_starttransfer}" https://tuosito.it/. Sotto i 200 ms sei a posto; oltre i 600 ms il problema è quasi sempre a monte del server, cioè nel codice che gira per costruire la pagina.
Su un sito con database la causa numero uno sono le query per pagina. Un impianto stratificato arriva a centinaia di interrogazioni per una singola schermata, molte identiche fra loro, ripetute perché ogni componente chiede per conto proprio senza sapere che un altro ha già chiesto la stessa cosa. Si misurano con un profiler, e la correzione tipica non è un indice nuovo sul database: è chiedere una volta sola e riusare il risultato.
La seconda voce è il lavoro fatto a ogni richiesta invece che una volta sola: ricalcolare menu, permessi, listini o traduzioni per ogni visitatore, quando il risultato è identico per tutti. È esattamente ciò che una cache a livello di oggetti o di pagina elimina — ma la cache va messa dopo aver ridotto il lavoro, non prima: messa sopra un impianto inefficiente nasconde il problema finché qualcosa la invalida, e a quel punto il server crolla proprio nel momento di punta.
Infine il dimensionamento. La domanda giusta non è «quanta potenza mi serve» ma «quanto consuma una singola richiesta»: se una pagina occupa il processore per 50 ms invece che per 500, con la stessa macchina servi dieci volte le persone. È per questo che l'ordine corretto è misurare il consumo reale a sito già online, e solo dopo scegliere il piano — con un margine, perché il traffico non arriva distribuito ma a ondate.