Il sito è lento? Prima di comprare un server più potente, misura - init.d
EN

# Il sito è lento? Prima di comprare un server più potente, misura

Alessandro Corbelli~5 min
Table of Contents

Un sito lento non è solo un fastidio: è un costo. Chi apre una pagina e la vede caricare a fatica se ne va, e con lui se ne vanno visite, vendite e fiducia. Google, poi, tiene conto della velocità quando decide chi mostrare per primo: un sito lento parte più indietro anche nei risultati di ricerca.

L’istinto, davanti a un sito lento, è quasi sempre lo stesso: “prendiamo un server più potente”. È la reazione più naturale e, nove volte su dieci, è anche quella sbagliata. Un server più grande nasconde il problema per qualche mese, ti fa spendere di più ogni mese, e poi la lentezza torna, perché la causa non era la potenza. La regola è una: prima si misura, poi si spende.

Vediamo perché il “ferro” raramente è la risposta, quali due numeri puoi guardare da solo e gratis, e da dove nasce davvero la lentezza.

Perché un server più potente (di solito) non risolve

Il collo di bottiglia di un sito lento quasi mai è la pura potenza di calcolo. Nella grande maggioranza dei casi è qualcos’altro: immagini enormi mai ottimizzate, una cache assente o mal configurata, query al database scritte male, o troppi script di terze parti che rallentano il caricamento. Raddoppiare CPU e memoria non tocca nessuna di queste cause: le compensa un po’, a caro prezzo, finché il traffico non cresce e il problema riemerge.

Il paragone è quello del traffico in città. Se le strade sono intasate perché ci sono troppi semafori mal regolati, comprare un’auto più veloce non ti fa arrivare prima: resti fermo nella coda, solo con una macchina più costosa. La velocità serve quando la strada è libera, non quando il problema è come è organizzato il percorso.

I due numeri da guardare, gratis

Prima di spendere un euro, guarda come sta il sito davvero. Ti bastano due indicatori, che trovi gratis in strumenti come PageSpeed Insights di Google, semplicemente incollando l’indirizzo del sito:

  • LCP (in italiano “il tempo per vedere il contenuto principale”): quanto ci mette a comparire l’elemento più grande della pagina, di solito l’immagine o il titolo in alto. Dipende molto da quanto è veloce a rispondere il server, un aspetto che ha un nome preciso: il tempo di risposta, o TTFB.
  • INP: quanto è reattiva la pagina quando ci clicchi o ci scrivi dentro. Un valore alto racconta una pagina appesantita da troppo codice che gira nel browser, spesso script di terze parti. È la metrica che ha sostituito il vecchio FID tra i Core Web Vitals di Google.

Questi due numeri ti dicono dove guardare. Un LCP alto punta verso il server e il caricamento; un INP alto punta verso gli script e il codice. È la differenza tra sapere e tirare a indovinare.

Le cause vere della lentezza, in ordine di frequenza

Nella pratica, la lentezza di un sito nasce quasi sempre da queste cause, ed è utile conoscerle perché ognuna ha un rimedio diverso e mirato:

  1. Immagini enormi non ottimizzate. Una foto da 4 MB caricata così com’è pesa più di tutto il resto della pagina. Ridimensionarle e comprimerle bene è spesso il singolo intervento che rende di più.
  2. Cache assente o mal configurata. Senza cache, il server ricalcola ogni pagina da zero a ogni visita. Una cache ben messa, lato server e lato browser, taglia i tempi in modo netto.
  3. Query al database lente. Su CMS ed e-commerce è una causa classica: una singola query scritta male può bloccare intere schermate. È il cuore del problema quando, per esempio, un negozio PrestaShop diventa lento nei momenti di punta.
  4. Troppi script di terze parti. Chat, pixel di tracciamento, tag di marketing, widget: ognuno aggiunge peso e ritardo. Spesso se ne accumulano a decine senza che nessuno li riveda.
  5. Server sottodimensionato o mal configurato. Sì, a volte il server c’entra davvero, ma lo scopri da un TTFB alto misurato, non per sensazione.

Quando invece il server c’entra davvero

Va detto con onestà: capita che la causa sia proprio l’hardware, un hosting condiviso sovraccarico o una macchina sottodimensionata per il traffico reale. Ma anche in questi casi la risposta raramente è “comprare più potenza”. Spesso basta introdurre uno strato di cache (Redis, Varnish), tarare bene il web server e il database, e lo stesso hardware regge il triplo del carico. Si passa a un server più grande solo dopo aver misurato che serve davvero, non come primo tentativo al buio.

In sintesi

Un sito lento raramente si risolve comprando ferro. Prima si misurano LCP, INP e il tempo di risposta del server; poi si interviene sulla causa reale, che nella grande maggioranza dei casi sono immagini pesanti, cache mancante, query lente o script di troppo. Spesso lo stesso hardware, tarato bene, va il triplo, a un costo molto inferiore rispetto a un server più grande che nasconde il problema per qualche mese. Se vuoi capire da dove nasce la lentezza del tuo sito prima di spendere, è il tipo di analisi con cui partiamo nel monitoraggio e ottimizzazione delle performance.

Fonti

Tux versione Gandalf, mascotte del blog init.d

init.d è il team di Alessandro Corbelli, sistemista Linux e sviluppatore backend con oltre vent’anni di esperienza. Progetta e gestisce infrastrutture cloud (Google Cloud, AWS, Azure), server farm e architetture ad alta disponibilità, e sviluppa software su misura in Laravel/PHP e Vue - dalla piattaforma di food delivery Take2Me ai gestionali dei nostri clienti. Su questo blog condividiamo note tecniche su Linux, sistemistica, sviluppo, DevOps ed e-commerce.


Altri articoli