Guida per principianti su cosa migliora davvero i tempi di caricamento: immagini, caching, hosting, codice e Core Web Vitals—con interventi rapidi da provare subito.
Quando si dice “il mio sito è lento” di solito si intende una di due cose:
“Tempo di caricamento” non è un unico numero cronologico. Una pagina si carica per fasi: il browser richiede file (HTML, immagini, font, script), li scarica e poi li trasforma in una pagina utilizzabile. Puoi pensarci come aprire un negozio: sbloccare la porta, accendere le luci, sistemare gli scaffali e infine essere pronto a servire i clienti.
La velocità influisce su:
Non servono 50 micro-ottimizzazioni. Per la maggior parte dei siti per principianti, i miglioramenti più grandi arrivano da una breve lista: immagini, troppo JavaScript/CSS, widget di terze parti e tempo di risposta del server/hosting.
Questa guida si concentra su passi pratici e a basso rischio che migliorano il tempo di caricamento nel mondo reale, specialmente su mobile. Non entrerà in argomenti avanzati come riscrivere l’architettura dell’app, costruire layer di caching personalizzati o budget di prestazioni per grandi team di ingegneria. L’obiettivo è aiutarti a fare cambiamenti che puoi effettivamente finire—e verificare—senza rompere il sito.
Quando si dice “il mio sito è lento” spesso si intende una di tre cose: il contenuto principale appare tardi, la pagina è laggosa quando si tocca, o il layout continua a saltare. I Core Web Vitals di Google mappano bene queste lamentele.
LCP (Largest Contentful Paint): quanto tempo impiega il più grande elemento “principale” (spesso un’immagine hero o un blocco titolo) ad apparire. Se l’LCP è alto, gli utenti guardano una pagina per lo più vuota.
INP (Interaction to Next Paint): quanto velocemente la pagina risponde dopo un’interazione dell’utente (tap, clic, digitazione). Se l’INP è alto, il sito sembra appiccicoso—i pulsanti reagiscono in ritardo, i menu si aprono con delay.
CLS (Cumulative Layout Shift): quanto salta la pagina durante il caricamento. Se il testo si sposta e premi per errore un pulsante, quello è CLS.
TTFB (Time to First Byte) è quanto tempo impiega il server (e tutto ciò che c’è in mezzo) per iniziare a inviare qualcosa. Un TTFB lento ritarda tutto il resto: le immagini non possono iniziare a scaricarsi, i font non possono caricarsi e l’LCP di solito peggiora. I problemi di TTFB spesso indicano hosting, lavoro backend pesante o cache mancanti.
I test di laboratorio (come Lighthouse) simulano un caricamento in condizioni prestabilite. Sono ottimi per il debug e per confronti prima/dopo.
I dati reali degli utenti (detti anche “field data”, come CrUX nei report di PageSpeed Insights) riflettono ciò che i visitatori sperimentano davvero su dispositivi e reti diverse. Questo è ciò che conta davvero per la domanda: “Si percepisce veloce per le persone reali?”
Se inizi a “ottimizzare” senza una linea di base, è facile perdere tempo—o rendere il sito più lento accidentalmente. Prenditi 20 minuti per misurare prima, così saprai quali cambiamenti hanno aiutato.
Usa PageSpeed Insights per uno snapshot veloce. Riporta dati reali degli utenti (quando disponibili) e dati di laboratorio. Fai attenzione a:
Per test di laboratorio più approfonditi, esegui Lighthouse in Chrome:
Quando vuoi vedere cosa sta ritardando la pagina, WebPageTest è uno degli strumenti più chiari. La vista a cascata mostra ogni file che si carica in ordine—HTML, immagini, font, script e tag di terze parti—e dove il browser sta aspettando.
Inizia con una pagina chiave (homepage o pagina di atterraggio principale) e testa:
Annota per ogni test:
Crea un piccolo registro (va bene un foglio di calcolo): data, strumento usato, URL, risultati e cosa è cambiato. Cambia solo una o due cose alla volta, poi ritesta nelle stesse condizioni.
Se stai iterando su un’app (non solo un sito statico), è utile avere un modo sicuro per distribuire ed eventualmente annullare esperimenti di prestazioni. Piattaforme come Koder.ai (che può generare e ospitare app React/Go da un workflow in chat) sono utili perché puoi prendere snapshot, testare modifiche e rollback velocemente se una “correzione di velocità” peggiora l’esperienza utente.
Le pagine lente raramente sono causate da un unico problema misterioso. Di solito sono il risultato di alcuni problemi comuni di “peso e ritardo” che si sommano—soprattutto su mobile.
Le immagini sono spesso la parte più pesante di una pagina. Una singola immagine hero esportata nelle dimensioni sbagliate (o in un formato vecchio) può aggiungere megabyte e secondi.
Colpevoli comuni:
Il JavaScript può ritardare quanto rapidamente una pagina diventa utilizzabile. Anche se la pagina “si vede”, può risultare lenta mentre gli script si scaricano, parsano ed eseguono.
Gli script di terze parti sono spesso i peggiori: widget di chat, popup, heatmap, tool di A/B testing, tag pubblicitari e embed social. Ognuno può aggiungere chiamate di rete extra e può ritardare lavori critici del browser.
A volte il browser aspetta il server prima di poter iniziare a caricare la pagina. Questo si percepisce come una risposta iniziale lenta (TTFB). Cause comuni: hosting sottodimensionato, database occupati, temi/plugin non ottimizzati o pagine costruite dinamicamente a ogni visita.
Se il sito obbliga ogni visita a partire da zero, i visitatori di ritorno ne risentono. Senza caching, il server ricostruisce le pagine e il browser riscarica file che raramente cambiano.
Inoltre, molti file piccoli (font, script, stili, tracker) creano “overhead di richieste”. Anche se ogni file è piccolo, il tempo di attesa combinato cresce.
La buona notizia: queste cause sono correggibili—e di solito ottieni i maggiori guadagni affrontandole in quest’ordine.
Se devi fare una sola cosa per le prestazioni, fallo sulle immagini. Su molti siti per principianti, le immagini rappresentano la maggior parte del “peso” scaricato della pagina—soprattutto su mobile. La parte positiva: le correzioni sulle immagini sono solitamente sicure, rapide e non richiedono di cambiare il design.
Un errore comune è caricare una foto enorme (es. 4000px) e mostrarla a 800px. Il browser scarica comunque il file grande.
Esporta le immagini vicino alla dimensione massima a cui appariranno realmente. Ad esempio, se l’area dei contenuti del blog è larga 800px, non caricare immagini da 3000–4000px “per sicurezza”.
JPEG e PNG funzionano ancora, ma i formati moderni spesso offrono la stessa qualità visiva a dimensioni molto inferiori.
Se il tuo CMS o plugin immagini può servire automaticamente WebP/AVIF con fallback, è l’ideale.
La compressione è dove avvengono la maggior parte dei guadagni immediati. Un’immagine “visivamente identica” può spesso essere ridotta del 30–70%.
Rimuovi anche i metadata non necessari (info della fotocamera, dati di posizione). Non cambiano l’aspetto dell’immagine, ma aggiungono byte.
Regola pratica: comprimi finché noti un calo visibile di qualità, quindi torna indietro di un livello.
srcset) per mobile vs desktopGli utenti mobile non dovrebbero scaricare immagini per desktop. Le immagini responsive permettono al browser di scegliere la dimensione giusta in base alla larghezza dello schermo.
Se il tuo sito genera più dimensioni automaticamente, assicurati che il tema le usi correttamente. Cerca nell’HTML della pagina qualcosa come srcset (più versioni) invece di un unico file enorme.
Prima di passare ad ottimizzazioni più avanzate (come minificare il codice), controlla le immagini principali:
Fai queste quattro cose con costanza e la velocità del tuo sito e i tempi di caricamento miglioreranno di solito immediatamente—spesso abbastanza da muovere i Core Web Vitals nella direzione giusta.
Il lazy loading significa che la pagina ritarda il download di alcune immagini (e a volte iframe) finché non sono vicino a comparire sullo schermo. Questo può ridurre il caricamento iniziale perché il browser non cerca di prendere tutto subito—utile su pagine lunghe con molte immagini sotto la piega.
Il lazy loading è più utile per:
Usato bene, riduce il lavoro iniziale e aiuta la pagina a sembrare più veloce.
La tua immagine più grande above-the-fold è spesso l’hero. Se la carichi in lazy, il browser potrebbe aspettare troppo a richiederla, danneggiando la Largest Contentful Paint (LCP).
Regola pratica: mai fare lazy-load dell’immagine hero o di qualsiasi elemento critico nella prima schermata (immagine del titolo, foto principale del prodotto, banner top).
width/heightIl lazy loading può far “saltare” il layout quando le immagini compaiono. Per evitare layout shift (CLS), riserva sempre lo spazio:
width e height sulle immagini, oppureIn questo modo il layout resta stabile mentre le immagini si caricano.
Se un’immagine o un font above-the-fold è essenziale per la prima impressione, considera di preloadarlo in modo che il browser lo prenda subito. Usa il preload con parsimonia—preloadare troppo può avere l’effetto contrario competendo per la banda.
Se vuoi un approccio checklist, abbina questo al passo di misurazione in blog/how-to-measure-site-speed-before-you-change-anything.
La cache è il modo del browser per dire: “Ho già scaricato questo—posso riutilizzarlo?” Invece di riscaricare logo, CSS o bundle JavaScript a ogni visualizzazione, il browser conserva una copia locale per un po’. Questo rende le visite successive notevolmente più veloci e riduce l’uso di dati—soprattutto su mobile.
Quando il tuo sito invia un file (come styles.css o app.js), può anche inviare istruzioni su quanto tempo quel file può essere riutilizzato. Se al browser è permesso conservarlo, per esempio, 30 giorni, alla visita successiva quei file si caricano istantaneamente dal dispositivo invece che dal server.
Questo non accelera la prima visita, ma può velocizzare molto:
I file statici sono cose che non cambiano ogni minuto: immagini, CSS, JavaScript, font. Sono candidati perfetti per tempi di cache più lunghi.
Concettualmente desideri:
Il tuo host, CMS o framework potrebbe offrire un’opzione semplice per “static asset caching”. Se lavori con uno sviluppatore, chiedi di impostare intestazioni Cache-Control appropriate per gli asset.
Una preoccupazione comune è: “Se cacheiamo i file per un mese, come fanno gli utenti a ottenere l’aggiornamento domani?” La soluzione sono i nomi di file versionati.
Invece di riutilizzare app.js per sempre, il processo di build (o lo sviluppatore) può generare qualcosa come:
app.3f2a1c.jsstyles.a81b09.cssQuando il contenuto cambia, cambia anche il nome del file, quindi il browser lo scarica immediatamente—pur mantenendo la cache delle versioni vecchie al sicuro.
I service worker possono portare il caching oltre, permettendo al sito di controllare cosa conservare e quando, abilitando a volte comportamenti offline. Possono però causare problemi di “contenuto obsoleto” se implementati male. Se sei un principiante, considera i service worker come un’opzione avanzata—ottimi quando hai obiettivi chiari e qualcuno esperto che li mantenga.
Un CDN (Content Delivery Network) è un insieme di server distribuiti in diverse regioni che possono consegnare i file del tuo sito da una posizione più vicina al visitatore. Invece di far viaggiare ogni richiesta fino al tuo server singolo, molte richieste sono gestite “vicino a loro”.
I CDN sono ottimi per velocizzare gli asset statici—cose che non cambiano a ogni richiesta—come immagini, CSS, JavaScript, font e video. Questi file possono essere copiati sui server del CDN e riutilizzati per molti visitatori.
Chi ne beneficia di più: siti con visitatori in più città/paesi, siti ricchi di media e attività di marketing con traffico da tutto il mondo.
La distanza aggiunge ritardo. Se il tuo server è in un paese e il visitatore in un altro continente, ogni richiesta impiega più tempo. Un CDN riduce quel ritardo servendo file da un edge server più vicino al visitatore, migliorando di solito il tempo di caricamento e aiutando i Core Web Vitals—specialmente su connessioni mobile.
Intestazioni di cache mal configurate possono impedire la cache del tutto (o fare il contrario, ossia cacheare troppo). Il problema opposto è la cache obsoleta: aggiorni un file ma i visitatori vedono ancora la versione vecchia. Per evitarlo, usa nomi di file con cache-busting (es. app.1234.js) e impara la funzione di “purge” del tuo CDN.
Un CDN non sostituisce la correzione di immagini pesanti, script gonfi o hosting lento—ma può essere un forte moltiplicatore quando le basi sono a posto.
CSS e JavaScript sono spesso il “peso invisibile” che rallenta una pagina. A differenza delle immagini, il problema non è sempre visibile—but il browser deve comunque scaricare, parsare ed eseguire questi file prima che la pagina risulti pronta.
La minificazione rimuove spazi extra, commenti e formattazione. Di solito riduce le dimensioni dei file e accelera il download.
Cosa cambia: la dimensione del file.
Cosa non cambia: quanto lavoro il browser deve fare per parsare ed eseguire il codice. Se i tuoi script fanno troppo al caricamento, la minificazione non risolverà quel problema—quindi considera la minify come una vittoria rapida, non una soluzione completa.
Molti siti caricano un foglio di stile “one size fits all” che include regole per pagine e componenti che la pagina corrente non usa. Quel CSS in più viene comunque scaricato e può rallentare il rendering.
Un approccio pratico:
L’obiettivo è semplice: la homepage non dovrebbe portare il peso dell’intero sito.
Alcuni script bloccano la pagina dall’essere interattiva perché il browser si ferma per eseguirli.
defer è solitamente la scelta migliore per i tuoi script che possono aspettare che l’HTML sia parsato.async è migliore per script indipendenti (spesso di terze parti) che non dipendono da altro codice.Se non sei sicuro, comincia deferendo tutto ciò che non è richiesto per la prima schermata (menu, animazioni, slider, tracking extra).
Librerie grandi possono aggiungere centinaia di KB (o più). Prima di aggiungere un plugin o un framework, chiediti:
Meno script significano meno sorprese—soprattutto per le prestazioni mobile, dove il tempo CPU conta tanto quanto la dimensione del download.
Gli script di terze parti sono tutto ciò che il tuo sito carica dai server di un’altra azienda. Sono popolari perché aggiungono funzionalità rapidamente—ma possono anche essere alcune delle cause più grandi e imprevedibili di rallentamenti.
Molti rallentamenti provengono da categorie come:
Questi script spesso scaricano file extra, eseguono molto JavaScript e a volte bloccano il browser dal finire il caricamento della pagina.
Apri Chrome DevTools → Performance, registra un caricamento della pagina e cerca:
Puoi anche eseguire Lighthouse (Chrome DevTools → Lighthouse) e controllare le raccomandazioni relative a “Reduce JavaScript execution time” e “Eliminate render-blocking resources.”
Alcune vittorie facili per principianti:
Invece di caricare un embed completo di YouTube/Facebook/Map alla prima vista, mostra un’anteprima semplice (thumbnail + pulsante play). Carica il vero embed solo quando l’utente clicca.
Questo mantiene la pagina veloce per tutti—soprattutto su mobile—senza togliere la funzionalità.
TTFB (Time to First Byte) è il tempo che impiega il server a iniziare a rispondere dopo che il browser ha richiesto una pagina. Pensalo come “quanto tempo prima che la cucina inizi a cucinare”, non quanto tempo prima che il pasto sia servito.
Un sito bello può comunque sembrare lento se il TTFB è alto—soprattutto su reti mobili dove ogni ritardo è più evidente.
Il TTFB riguarda principalmente il lavoro server-side prima che venga inviato qualcosa:
Anche se immagini e script sono ottimizzati, una risposta server lenta può lasciare il browser a guardare uno schermo vuoto.
Se il tuo sito è costruito con un CMS o genera pagine dinamicamente, il caching lato server è spesso l’improvviso miglioramento più grande per il TTFB. Invece di ricostruire la stessa pagina per ogni visitatore, il server può conservare una versione pronta da servire.
Esempi pratici:
Abilita Brotli (preferito) o Gzip per file testuali come HTML, CSS e JavaScript. Questo riduce la quantità di dati da trasferire, migliorando la velocità percepita—specialmente per caricamenti ripetuti e utenti mobile.
Un hosting migliore può ridurre il TTFB, ma è più intelligente risolvere prima i problemi front-end evidenti (immagini enormi, troppi script di terze parti, JavaScript pesante). Se il browser scarica megabyte di roba, un hosting più veloce non farà sembrare la pagina veramente rapida.
Una volta risolte le basi, l’upgrade dell’hosting (più CPU/RAM, database ottimizzato, runtime migliore) può essere il passo finale che rende il sito costantemente reattivo.
Se stai costruendo un nuovo prodotto e vuoi meno variabili di hosting fin da subito, considera una piattaforma managed che incorpora default sensati. Per esempio, Koder.ai ospita app su AWS globalmente e supporta deploy, domini custom e rollback degli environment—utile quando testi cambi di performance across regioni o hai requisiti di residenza dei dati.
Non serve un progetto enorme per migliorare la velocità. Serve un ordine di operazioni semplice, un modo per confermare di non aver peggiorato le cose e la preferenza per correzioni che riducono davvero il tempo di caricamento.
Giorno 1: misura (prima di toccare nulla).
Scegli 2–3 pagine importanti (homepage, landing principale, post del blog/prodotto popolare). Esegui:
Annota la baseline per mobile e desktop. Se puoi, testa anche su un telefono reale (anche il tuo) in 3G/4G — spesso rivela problemi che i test di laboratorio non mostrano.
Giorni 2–3: sistema le immagini (la vittoria più rapida e affidabile).
Priorità:
Ritesta dopo aver aggiornato solo alcune immagini per vedere l’effetto.
Giorni 4–5: sistema il caching (rendere le visite ripetute molto più veloci).
Abilita il caching del browser e il caching server/pagina dove appropriato. L’obiettivo è: non rigenerare o riscaricare gli stessi asset a ogni visita. Dopo aver abilitato la cache, verifica che il ritorno sulla pagina sia notevolmente più veloce.
Giorni 6–7: riduci JavaScript (spesso il guadagno più grande a lungo termine).
Cerca:
Piccoli cambiamenti qui possono migliorare molto l’interattività e i Core Web Vitals, specialmente su mobile.
Dopo ogni modifica importante (immagini, caching, script), fai tre controlli rapidi:
Se hai ottimizzato immagini e caching e vedi ancora TTFB persistentemente alto, di solito è l’hosting/configurazione server, un database lento o lavoro backend pesante. Considera aiuto anche se il sito è una app complessa (siti a membership, marketplace, molta personalizzazione) dove “cache everything” non è semplice.
Se vuoi una guida più approfondita sul tempo di risposta del server, vedi blog/ttfb-explained.
La velocità di un sito di solito indica due cose:
Una pagina può sembrare caricata ma risultare comunque lenta se JavaScript è occupato o il layout continua a spostarsi.
I Core Web Vitals corrispondono ai reclami più comuni degli utenti:
Migliorare questi parametri solitamente migliora la percezione reale della velocità, non solo il punteggio.
Usa questi obiettivi pratici:
Usali come linee guida: concentra gli sforzi sul metrica peggiore prima.
Inizia con una baseline così non indovini:
Registra dispositivo, rete, posizione, URL esatto e cambia solo 1–2 cose prima di ritestare.
Le cause più frequenti sono:
Correggere questi problemi in quest’ordine tende a dare i guadagni più rapidi.
Perché spesso sono i file più grandi della pagina e influenzano download e LCP. Concentrati su quattro basi:
Il lazy loading aiuta per i contenuti sotto la piega, ma può danneggiare l’LCP se usato male.
Regole pratiche:
width/ o un rapporto d’aspetto fisso.Il caching accelera soprattutto le visite ripetute (la seconda pagina cliccata, visite successive):
app.3f2a1c.js) così la cache lunga non blocca gli aggiornamenti.Fatto bene, il caching riduce i ricaricamenti e il lavoro del server senza rompere gli aggiornamenti.
Un CDN aiuta soprattutto quando hai visitatori distribuiti in più regioni e servì molti file statici. È ideale per:
Stai attento a:
Un CDN non risolve pagine pesanti da solo: ottimizza immagini/script prima, poi aggiungi il CDN come moltiplicatore.
Segui una sequenza semplice che puoi completare e verificare:
Dopo ogni step, ritesta nelle stesse condizioni e naviga il sito per assicurarti che nulla si rompa.
srcset) così il mobile scarica file più piccoli.Questi cambiamenti sono a basso rischio e misurabili immediatamente.
heightSe qualcosa è critico per la prima schermata, considera il preload con parsimonia.