Perché le immagini rallentano il tuo sito web (e come migliorare la velocità)

Ultimo aggiornamento: June 28, 2026

Su quasi ogni sito lento che ho analizzato, la causa è stata la stessa: le immagini. Testo, font e JavaScript contano tutti, ma i media rappresentano il peso dominante su una tipica pagina di contenuti o e-commerce, ed è la parte che i team ottimizzano per ultima. Questo articolo si concentra strettamente su come le immagini influenzano la velocità di caricamento, con le correzioni che ho misurato in produzione. Per un quadro più ampio, la guida sull'ottimizzazione della velocità del sito web copre anche codice, font e caching.

Risposta rapida: come rallentano le immagini un sito?

Le immagini rappresentano solitamente il 60-80% del peso totale della pagina, e su pagine ricche di immagini sono la singola leva più grande sul tempo di caricamento. Le quattro correzioni che fanno maggiore differenza sono servire un formato moderno con le dimensioni esatte di visualizzazione, comprimere a una qualità ragionevole, implementare il lazy-loading per i media sotto la piega (below-the-fold) e posizionare gli asset dietro un CDN.

Su un blog client che ho misurato, quelle quattro modifiche hanno ridotto il peso della pagina da 3.4 MB a 690 KB e l'Largest Contentful Paint da 4.8 secondi a 1.9 secondi. Iniziate con le immagini più grandi e misurate prima e dopo.

Perché le immagini rallentano il tuo sito?

Ogni immagine è una richiesta di rete più i byte che il browser deve scaricare, decodificare e disegnare. Su una pagina tipica, questi byte eclissano tutto il resto. Ho analizzato il peso sulla stessa pagina client, ordinato per categoria:

Le immagini sono più grandi di tutte le altre categorie combinate, motivo per cui lavorare sulle immagini ripaga più velocemente rispetto a qualsiasi altra modifica. Gli stessi byte costano anche tempo di decodifica: una foto da 4 MB blocca il main thread mentre il browser la decompone, anche dopo che il download è terminato.

Tre meccanismi, nell'ordine in cui li vedo più spesso, spiegano il rallentamento:

• Byte eccessivi — inviare una foto da 4000 pixel in uno slot da 400 pixel.
• Formato sbagliato — PNG a colori pieni per una fotografia invece di WebP.
• Consegna non ottimizzata — nessun CDN, nessun caching, nessuna variante responsive.

I primi due riguardano ciò che inviate. Il terzo riguarda come lo inviate. Ognuno ha una soluzione semplice, trattata di seguito.

Quanto costa in secondi il peso della pagina?

Il peso della pagina si traduce in secondi attraverso la rete. Una regola approssimativa ma utile: un telefono di fascia media su una connessione 4G scarica all'incirca da 1 a 1.5 MB al secondo nel mondo reale, non il picco teorico. Quindi una pagina da 3.4 MB richiede circa 3 secondi solo per essere recuperata, prima che il browser faccia qualsiasi lavoro.

Ho misurato questo direttamente sul sito client, mantenendo tutto il resto costante e modificando solo il peso delle immagini:

Ogni megabyte che tagli è approssimativamente un secondo risparmiato su una tipica connessione mobile. Ecco perché il peso delle immagini conta più di qualsiasi micro-ottimizzazione nel tuo CSS o JavaScript. Google documenta la relazione tra il peso della pagina e le prestazioni di caricamento nella sua guida veloce web.dev, e PageSpeed Insights segnala le immagini di grandi dimensioni come uno dei suoi principali fallimenti di audit.

Come si serve il formato e la dimensione corretti?

Il guadagno singolo più grande è convertire fotografie da JPG e PNG in un formato moderno e ridimensionarle alle dimensioni di visualizzazione. WebP è circa il 25-35% più piccolo di JPG alla stessa qualità percepita; AVIF va oltre ma ha una velocità di codifica più discontinua. Io mi affido a WebP perché si decodifica velocemente e funziona ovunque nel 2026.

1. Ridimensionare alle dimensioni di visualizzazione. Una foto da 4000 pixel in uno slot da 400 pixel è dieci volte più grande del necessario. Limitate le immagini di contenuto a 1600-1920 pixel sul lato lungo.

2. Convertire in WebP con qualità 75-82. Questo intervallo è quasi indistinguibile dalla sorgente per le fotografie e risparmia la maggior parte dei byte. Andare più giù provoca banding nei cieli e nei gradienti.

3. Mantenere una variante AVIF solo per l'hero se lo supportate, poiché l'encoding AVIF è lento e vale la pena solo per l'immagine che diventa il tuo elemento Largest Contentful Paint.

Per le dimensioni esatte in base all'uso, la guida per ridimensionare immagini per il web ha i numeri. Per raggiungere la qualità senza artefatti, il flusso di lavoro per comprimere le immagini senza perdere qualità descrive le impostazioni WebP che utilizzo.

Come si comprime e converte prima di inviare?

La compressione dovrebbe avvenire nel build, mai nel browser. L'obiettivo è un'unica immagine sorgente che diventi automaticamente varianti ottimizzate.

## Converti un hero in WebP alle dimensioni di visualizzazione, qualità 80
cwebp -q 80 -resize 1920 0 hero.jpg -o hero-1920.webp

Per un intero directory uso un piccolo loop che emette diverse larghezze. La disciplina chiave è non commettere mai una foto grezza da 5 MB.

• Impostare un pavimento di qualità di 70 per il contenuto e 75 per le foto di prodotto, quindi regolare a occhio su immagini reali.
• Eliminare i metadati (EXIF, profili colore non necessari) — possono aggiungere decine di kilobyte senza alcun beneficio visivo.
• Generare una variante per breakpoint piuttosto che un'unica immagine gigante per ogni dispositivo.
• Automatizzare in CI in modo che un'immagine non ottimizzata non possa mai raggiungere la produzione.

Un errore comune è comprimere il caricamento ma dimenticare tutte le miniature e le varianti responsive generate dal CMS. Eseguire il pipeline su tutte le dimensioni, non solo sull'originale. Questo è lo step in cui ho misurato i cali più ripidi nel peso della pagina — frequentemente dal 70% all'80% rispetto all'originale.

Come si implementa il lazy-loading sotto la piega?

Le immagini sotto la piega non dovrebbero bloccare il primo rendering. Il native lazy loading lo fa con un attributo e nessun JavaScript.

<img src="gallery-1-800.webp"
     width="800" height="600"
     loading="lazy" decoding="async"
     alt="Foto di prodotto in luce naturale">

Due attributi contano più di quanto le persone si rendano conto:

1. loading="lazy" ritarda il recupero finché l'immagine non si avvicina al viewport, quindi non compete mai con il primo rendering.
2. width e height permettono al browser di riservare la casella prima che arrivi l'immagine, prevenendo lo Shift del Layout Cumulativo (CLS).

Non fare lazy-load sull'hero o sull'immagine LCP — questo ritarda l'elemento più importante della pagina. La regola che seguo: lazy-load tutto sotto la piega, precarica l'unica immagine che gli utenti vedono per primi.

Come un CDN velocizza le immagini?

Un CDN serve le immagini da un server vicino a ogni visitatore, tagliando il round-trip di rete che domina il primo rendering su mobile e traffico internazionale. Sul sito client, aggiungere un CDN davanti alle immagini ha ridotto l'LCP di altri 400 millisecondi per i visitatori al di fuori della regione di origine.

Il CDN fornisce anche trasformazioni in tempo reale: richiedi qualsiasi larghezza o formato tramite URL, e il bordo lo genera e lo memorizza. Ciò elimina la necessità di pre-generare una dozzina di varianti. La guida all'image CDN copre dettagliatamente i header e le chiavi di cache.

Impostare un lungo Cache-Control: max-age=31536000, immutable su URL di immagini con fingerprint per consentire ai visitatori che tornano di riutilizzarle. Pulire la cache al deploy quando cambia il fingerprint.

Come si inseriscono le immagini responsive?

Le immagini responsive dicono al browser esattamente quale variante scaricare per il viewport corrente, in modo che un telefono non recuperi mai l'hero da desktop. Gli attributi srcset e sizes sono il modo nativo e senza dipendenze per farlo.

<img srcset="hero-640.webp 640w,
             hero-960.webp 960w,
             hero-1280.webp 1280w,
             hero-1920.webp 1920w"
     sizes="(max-width: 768px) 100vw, 50vw"
     src="hero-1280.webp"
     width="1280" height="853"
     loading="eager" fetchpriority="high"
     alt="Immagine hero di un laptop che carica un sito web">

Il browser seleziona la variante più piccola che riempie comunque lo slot al rapporto pixel del dispositivo. Su un telefono, spesso il file da 640w, è un quarto dei byte del file da 1920w. Aggiungere fetchpriority="high" all'immagine LCP in modo che il browser la dia priorità durante il caricamento iniziale.

Come misuro l'impatto delle immagini?

Non puoi migliorare ciò che non misuri. Due strumenti coprono bene il lavoro specifico sulle immagini.

• PageSpeed Insights — eseguilo su pagespeed.web.dev. Riporta dati di campo da utenti reali e segnala direttamente le immagini troppo grandi e i formati next-gen mancanti.
• Lighthouse — l'audit di laboratorio dietro PageSpeed Insights. Chrome documenta i suoi controlli sulle immagini nella guida per sviluppatori Lighthouse. Indica le immagini specifiche che sprecano byte.
• Chrome DevTools Network tab — filtra per Img, ordina per dimensione e annota i principali colpevoli. È così che trovo una o due immagini da correggere per prime.
• WebPageTest — un waterfall e un filmstrip che mostrano esattamente quando ogni immagine viene scaricata e come sposta il layout.

Quando laboratorio e campo non coincidono, fidati dei dati di campo. Un punteggio di laboratorio pulito su una macchina veloce tramite Wi-Fi significa poco se gli utenti mobili reali su 4G aspettano ancora. Poiché le immagini guidano l'Largest Contentful Paint sulla maggior parte delle pagine, il lavoro sulle immagini è anche un lavoro Core Web Vitals — la guida all'ottimizzazione delle immagini per Core Web Vitals lega i due concetti insieme.

Cosa dovrei evitare?

• Cercare un punteggio perfetto, non l'utente. Un 100 in laboratorio è inutile se l'LCP di campo è ancora di 4 secondi.
• Compromettere troppo la compressione. Ridurre troppo la qualità risparmia byte ma rovina le foto di prodotto. Testa su immagini reali, non su un campione.
• Ignorare il mobile. La maggior parte del traffico e dei caricamenti lenti sono mobili. Ottimizza per un telefono di fascia media su 4G, non per il tuo laptop da sviluppatore.
• Ottimizzare una sola volta. Le prestazioni decadono man mano che vengono inviate nuove immagini e funzionalità. Ritesta dopo ogni rilascio.
• Un'unica immagine gigante per ogni dispositivo. Senza srcset, i telefoni scaricano l'hero desktop.

Punto chiave

Le immagini sono la singola leva più grande sulla velocità del sito web perché rappresentano la quota più grande del peso della pagina. Le quattro correzioni — formato moderno alle dimensioni di visualizzazione, compressione, lazy-loading e un CDN — non sono glamour, ma è ciò che ha portato il mio sito client da 3.4 MB e LCP di 4.8 secondi a 690 KB e LCP di 1.9 secondi. Fate queste cose in quest'ordine, misurate ogni passo e correggete prima le immagini più grandi.

Un avvertimento onesto: i numeri esatti di byte e secondi sopra provengono da un sito client, e il vostro varieranno a seconda dei contenuti, del traffico e del CDN. Eseguite PageSpeed Insights sui vostri URL prima e dopo, e lasciate che i dati di campo degli utenti reali — non un pulito punteggio di laboratorio — siano il giudice del successo.

Crediti immagini

• Monitor computer moderno che mostra lavoro di web design in uno spazio di lavoro creativo — foto di Tranmautritam su Pexels
• Primo piano di uno schermo laptop che mostra una pagina motore di ricerca in caricamento — foto di cottonbro studio su Pexels
• Sviluppatore che digita codice su un laptop in uno spazio di lavoro concentrato — foto di olia danilevich su Pexels