Perché il mio sito è lento?

Quando un sito sembra lento, la causa raramente è una sola. La lentezza è spesso il risultato di più livelli che si sommano: browser, rete, server, applicazione e servizi esterni. Per capire davvero il problema, conviene smettere di chiedersi solo “perché va piano?” e iniziare a chiedersi “in quale strato si sta perdendo tempo?”.

Questo articolo non è una guida operativa, ma una mappa di lettura del problema. Serve a distinguere tra front end, backend, database e contesto infrastrutturale, così da interpretare meglio il collo di bottiglia.

Front end, backend e rete: tre tipi di lentezza diversi

Nel linguaggio quotidiano si dice semplicemente che un sito è lento. In realtà, però, possono esserci ritardi molto diversi. Una pagina può mostrare presto la struttura ma restare pesante da usare per via di CSS o JavaScript. Un’altra può tardare prima ancora di mostrare contenuti, e lì il sospetto cade più facilmente su server e rete.

• Front end: tutto ciò che il browser scarica ed esegue, come HTML, CSS, JavaScript, immagini e font.
• Backend: il lavoro del server, di PHP, dell’applicazione e del database per generare la risposta.
• Rete: DNS, distanza dal server e trasporto della richiesta.

Quando il problema sembra partire prima del contenuto visibile, un dato utile è il TTFB. Per chiarire questo concetto, puoi leggere che cos’è il TTFB.

TTFB: cosa indica davvero

TTFB significa Time to First Byte ed esprime il tempo che passa prima che il browser riceva il primo byte dal server. Non racconta tutta la velocità del sito, ma aiuta molto a capire se la risposta iniziale si sta formando lentamente. Un TTFB alto può dipendere da PHP pesante, query lente, cache assente o chiamate esterne che rallentano la generazione della pagina.

Il punto chiave è che il TTFB non misura solo la “forza” del server. Misura anche quanta logica viene eseguita prima di rispondere. Un sito con molte regole dinamiche può risultare più lento all’avvio anche se l’infrastruttura non è debole.

Se il TTFB è alto ma il sito non sembra particolarmente complesso, il collo di bottiglia è spesso nel backend. Se invece il TTFB è nella norma ma la pagina sembra comunque pesante, il problema è probabilmente più avanti, nel front end.

Immagini, CSS e JavaScript: quando il browser lavora troppo

Non tutta la lentezza nasce sul server. Spesso la risposta arriva presto, ma il browser deve ancora scaricare e processare troppi elementi prima che la pagina sia davvero fruibile. Immagini troppo grandi, CSS che blocca il rendering e JavaScript eccessivo possono allungare molto l’esperienza percepita.

Tra le cause più comuni ci sono:

• immagini più pesanti del necessario
• foglio di stile che ritarda il primo rendering
• JavaScript caricato troppo presto o ovunque senza necessità
• font web e librerie di icone molto numerose
• widget, mappe, chat ed embed esterni

In questi casi il server può anche rispondere rapidamente, ma il sito continua a sembrare lento perché il browser ha ancora molto lavoro da fare.

Core Web Vitals: capire che tipo di frizione vede l’utente

Le Core Web Vitals aiutano a distinguere tra visibilità, stabilità e reattività. Non parlano solo di tempo di caricamento, ma anche di quanto sia fluida l’esperienza. Un sito può sembrare caricato eppure risultare fastidioso se il layout si sposta, se gli elementi principali appaiono tardi o se i clic rispondono con ritardo.

Per una spiegazione più ampia delle metriche, consulta che cosa sono le Core Web Vitals. Il valore non è nel numero in sé, ma nel tipo di problema che quel numero aiuta a individuare.

Backend, PHP e database: la parte invisibile del lavoro

Su molti siti PHP, e soprattutto su WordPress, il server esegue parecchio lavoro prima di restituire la pagina. PHP gestisce la logica del tema, i plugin, le condizioni dinamiche e talvolta le chiamate ad API esterne. Il database, a sua volta, deve fornire contenuti, opzioni, metadati e dati prodotto.

La lentezza può emergere da query ripetute, tabelle cresciute nel tempo, plugin pesanti o temi che aggiungono molta logica per ogni richiesta. Una pagina semplice alla vista può nascondere un lavoro notevole dietro le quinte.

Nel caso di WooCommerce, il peso cresce ulteriormente perché il sito può calcolare stock, prezzi, tasse, spedizioni e contenuto del carrello in tempo reale. Il risultato è più simile a un’applicazione che a una vetrina statica.

Plugin, temi e cache in WordPress

Un WordPress lento raramente dipende da un solo plugin. Molto più spesso il problema nasce dall’insieme di estensioni, tema, page builder e script aggiunti. Ogni componente introduce query, file o logica extra. Il risultato è un sistema che fa molto più lavoro di quanto sembri dalla sola interfaccia.

La cache serve proprio a ridurre il lavoro ripetuto. Se una pagina può essere servita da un risultato già pronto, il server evita di ricrearla per ogni visita. Però la cache non cancella la complessità: se la pagina è molto dinamica, una parte importante del costo rimane comunque.

Per un quadro più completo sul caching, può essere utile questo approfondimento: guida definitiva a LiteSpeed LSCache.

API esterne, cron job, bot e picchi di traffico

Non tutte le lentezze nascono dentro il sito. API esterne, gateway di pagamento, mappe, chat o strumenti di analytics possono introdurre ritardi se rispondono lentamente o bloccano il flusso della pagina. Anche se il server principale funziona bene, una dipendenza esterna può rallentare l’esperienza percepita.

I cron job contano altrettanto. Sincronizzazioni, importazioni, invii email, aggiornamenti di feed e processi di coda consumano CPU, RAM e I/O. Se si sovrappongono al traffico reale, il sito entra in competizione per le risorse.

Bot e crawler aggiungono ulteriore pressione. E durante i picchi di traffico, un sito normalmente stabile può mostrare i propri limiti di concorrenza. In questi casi la domanda giusta non è solo “quanto è veloce?”, ma anche “quanto regge sotto carico?”.

Quando basta ottimizzare e quando conta anche l’ambiente

Non ogni sito lento richiede più risorse, ma non ogni problema si risolve con immagini più leggere o meno script. Se il front end è già ragionevole, la cache è presente e le dipendenze esterne sono limitate, allora entrano in gioco CPU, RAM, I/O e storage. Nei carichi con molte letture e scritture piccole, il tipo di storage può fare una differenza concreta. Per questo è utile capire che cos’è l’hosting NVMe.

NVMe non corregge una logica applicativa inefficiente, ma può ridurre alcune attese nei siti che interrogano spesso database e sessioni.

La conclusione pratica è semplice: “sito lento” è un sintomo, non una diagnosi. Separare front end, backend e rete aiuta a capire se il problema sta nel contenuto, nel codice, nel traffico o nella capacità dell’ambiente.

Quando un sito rallenta, conviene distinguere tra il peso dei contenuti e la loro distribuzione: una CDN riduce la distanza dagli utenti, mentre la cache del sito web fa lavorare meno spesso il server.