Velocità del sito: immagini, font e script
Perché un sito carica lento dipende spesso da tre cause: immagini troppo pesanti, font lenti e script di terze parti accumulati. Cosa correggere per primo.
Team rabbitclipPubblicato: 6 min di lettura
In breve
Un sito lento raramente ha una sola causa; è spesso la somma di tre fonti: immagini più pesanti del necessario, font che ritardano la visibilità della pagina e script di terze parti che si accumulano nel tempo. Correggere tutte e tre insieme fa una differenza netta; correggerne solo una di rado basta.
Google non misura più la velocità solo in base a quanto rapidamente appare una pagina; misura anche quanto in fretta lo schermo risponde non appena qualcuno tocca un pulsante. Questa metrica si chiama Interaction to Next Paint, o INP (web.dev, INP). La velocità non significa più solo «la pagina si è caricata», ma «la pagina è davvero utilizzabile».
Questo articolo affronta le tre fonti una alla volta: immagini, font, codice di terze parti. Per ciascuna, da dove partire e cosa fa davvero la differenza.
Perché le immagini portano il carico maggiore
La maggior parte del peso totale di una pagina viene di solito dalle immagini. Si pensi alla galleria prodotti di un produttore di pavimentazioni: una pagina da cinquanta megabyte significa diversi secondi di attesa, a seconda del dispositivo e della connessione del visitatore. Quel peso non sparisce finché l'immagine non viene servita nella dimensione e nel formato giusti.
La soluzione ha due passaggi. Prima l'immagine viene ritagliata alla dimensione in cui apparirà davvero; un'immagine che sul telefono occupa quattrocento pixel di larghezza non dovrebbe essere inviata a duemila pixel. Poi si sceglie il formato: AVIF e WebP producono file molto più leggeri del vecchio JPEG a parità di qualità (web.dev, Optimize LCP). Un framework come Next.js automatizza tutto questo, così nessuno deve preparare più versioni a mano.
Perché i font rallentano una pagina
Un font personalizzato fa parte dell'identità di un marchio, ma caricato nel modo sbagliato ritarda la visibilità della pagina. Se il browser nasconde il testo finché il file del font non è scaricato, il visitatore vede lo schermo vuoto per un secondo o due; questo effetto si chiama lampeggio di testo invisibile.
L'impostazione font-display: swap elimina quell'attesa: il browser mostra subito il testo con un font di sistema, poi lo sostituisce con il font personalizzato non appena arriva (web.dev, Best practices for fonts). La pagina di prenotazione di una catena di spa a volte richiede solo due pesi, normale e grassetto, ma dal file di design ne passano spesso cinque o sei così come sono sul sito online; ogni peso in più è un download a parte.
Perché gli script di terze parti sono il carico più insidioso
Strumenti di analytics, finestre di chat dal vivo, pixel pubblicitari, embed dei social: ognuno aggiunge un file JavaScript esterno alla pagina. Si accumulano in silenzio; un sito con cinque o sei strumenti diversi aggiunti nell'arco di un anno non è un caso raro.
Il problema è che questi script occupano il thread principale del browser; finché quel codice è in esecuzione, il browser non può rispondere al clic di un visitatore, il che peggiora direttamente l'INP (web.dev, INP). Rivedere l'elenco degli strumenti in uso ogni pochi mesi, e rimuovere un pannello di analytics che ormai nessuno guarda o un widget di chat che nessuno usa più, vale i dieci minuti che richiede.
In che ordine correggere
Non serve correggere tutte e tre le fonti insieme; un ordine rende il lavoro più semplice.
- Misurare lo stato attuale con PageSpeed Insights o Search Console
- Portare le immagini più grandi visibili senza scorrere alla dimensione e al formato giusti
- Ridurre il numero di pesi del font, aggiungere font-display: swap
- Rimuovere gli script di terze parti inutilizzati, caricare il resto solo quando serve
- Misurare di nuovo con lo stesso strumento dopo la modifica
La velocità è solo una questione tecnica
La velocità è anche una decisione di marketing, perché è il primo contatto del visitatore con il sito. Se la pagina di intervento urgente di un produttore di generatori carica lento, il visitatore torna al risultato di ricerca e prova l'azienda successiva; questa perdita avviene in silenzio, senza reclami né report di rimbalzo che qualcuno legga.
Il lavoro sulla velocità non è un progetto una tantum; appartiene alla manutenzione continua. La stessa disciplina si applica ogni volta che si aggiunge un nuovo strumento o si carica una nuova immagine.
Cosa cambiano Next.js 16 e React 19 per la velocità
Next.js 16 e React 19, ormai diffusi nel 2026, spingono ulteriormente sui componenti server: gran parte di una pagina viene preparata sul server e inviata al browser già finita, riducendo la quantità di JavaScript che il browser deve scaricare. Si tratta di una scelta architetturale che migliora direttamente l'INP.
Per il catalogo prodotti di un produttore con centinaia di pagine, la differenza è concreta: con una vecchia configurazione React ogni pagina viene ricreata nel browser, con la nuova architettura la pagina arriva già pronta e il browser gestisce solo le parti interattive, un filtro, un pulsante di aggiunta al carrello. Nel valutare un passaggio simile, questa differenza architetturale va inserita nel budget di velocità, non solo nel rinnovo visivo.
Perché la cache lato server fa la differenza
Una pagina generata una volta e mantenuta in cache per un periodo definito, invece di essere ricostruita a ogni visita, raggiunge i visitatori successivi molto più in fretta. È un vantaggio che vale per qualsiasi pagina il cui contenuto non cambi spesso, una pagina chi siamo, una descrizione di servizio.
Un calendario eventi sul sito di un'associazione di categoria, aggiornato spesso, richiede una cache di breve durata; una pagina aziendale statica può mantenere la stessa versione in cache per ore o anche giorni. La durata giusta dipende da quanto spesso cambia davvero il contenuto.
Una cache configurata male crea problemi propri: un prezzo vecchio che resta in cache e continua a essere mostrato per un po' dopo un aggiornamento, per esempio. Per questo va pianificato fin dall'inizio quando e come si svuota la cache dopo un aggiornamento.
Immagini, font e script di terze parti, considerati insieme, rendono una pagina più veloce da caricare e più pronta a rispondere ai clic. In una prima chiamata conoscitiva, rabbitclip prepara un report di velocità del sito attuale per vedere insieme quale fonte pesa di più.
Domande frequenti
Dove posso misurare la velocità del mio sito?
Google PageSpeed Insights e il report Core Web Vitals in Search Console forniscono misure separate per mobile e desktop.
AVIF funziona in tutti i browser?
La maggior parte dei browser attuali lo supporta; un sito può essere configurato per servire AVIF dove è supportato e passare automaticamente a WebP o JPEG dove non lo è.
Quanti script di terze parti sono troppi?
Non esiste un numero fisso; ogni script in più ha un costo, per questo vale la pena controllare regolarmente se ciascuno è ancora davvero utilizzato.
font-display: swap rovina l'aspetto del font del marchio?
No, mostra solo brevemente un font di sistema mentre quello personalizzato si scarica; il font del marchio subentra poco dopo.
Passare a Next.js 16 basta da solo per la velocità?
No, il cambio architetturale aiuta in modo significativo, ma senza disciplina su immagini, font e script non basta da solo.
