Ottimizzare le immagini per il web: WebP, AVIF, lazy loading e dimensioni corrette

Nella maggior parte dei siti che analizzo le immagini pesano più di tutto il resto messo insieme: HTML, CSS, JavaScript e font. È anche la voce su cui si ottengono i miglioramenti più rapidi, perché quasi sempre il problema non è la compressione ma il fatto che si stanno servendo file molto più grandi del necessario.

Il primo errore: dimensioni sbagliate, non compressione sbagliata

Una foto da 4000 pixel di larghezza mostrata in uno spazio da 800 pixel spreca oltre il 95% dei dati trasferiti, e nessun livello di compressione lo recupera. Prima di toccare qualsiasi altra impostazione verifica quali dimensioni reali occupano le immagini nel layout: negli strumenti per sviluppatori del browser, la scheda Rete mostra per ogni immagine sia la dimensione intrinseca del file sia quella con cui viene effettivamente visualizzata.

La regola pratica: l’immagine sorgente non dovrebbe superare il doppio della larghezza massima con cui viene mostrata, così da coprire anche gli schermi ad alta densità. Oltre quella soglia stai pagando byte che nessuno vede.

Quale formato scegliere

• WebP è oggi la scelta predefinita ragionevole: supportato da tutti i browser in circolazione, produce file mediamente il 25-35% più leggeri di un JPEG di qualità equivalente e gestisce anche la trasparenza.
• AVIF comprime ancora meglio, spesso il 20-30% in più rispetto a WebP, ma la codifica è molto più lenta e conviene servirlo come alternativa con fallback, non come unico formato.
• JPEG resta accettabile per le fotografie quando serve la massima compatibilità o quando il flusso di lavoro non permette la conversione.
• PNG va usato solo dove serve davvero: grafiche con aree piatte, screenshot di interfacce, trasparenze nette. Per le fotografie produce file enormi.
• SVG per loghi, icone e illustrazioni vettoriali: scala a qualsiasi dimensione e pesa pochissimo. Va però ripulito prima dell’uso, perché gli export dai programmi di grafica contengono metadati inutili e possono includere codice.

Immagini responsive: srcset e sizes

Servire lo stesso file a un telefono e a un monitor desktop significa penalizzare il primo. L’attributo srcset permette di dichiarare più varianti della stessa immagine a larghezze diverse, mentre sizes dice al browser quanto spazio occuperà l’immagine nel layout, così può scegliere il file giusto prima ancora di scaricarlo.

La buona notizia per chi usa WordPress: le dimensioni multiple e gli attributi srcset vengono generati automaticamente al caricamento nella libreria media. Il problema tipico nasce a monte, quando un’immagine viene inserita a mano nel tema o in un page builder con un URL fisso, aggirando del tutto il meccanismo.

Lazy loading: utile, ma non ovunque

Il caricamento differito, cioè l’attributo loading="lazy", evita di scaricare le immagini che stanno sotto la piega finché l’utente non ci arriva. È un guadagno netto per le pagine lunghe e per le gallerie.

L’errore frequente è applicarlo a tutte le immagini indiscriminatamente, inclusa quella principale in cima alla pagina. Quell’immagine è quasi sempre l’elemento che determina il Largest Contentful Paint: rimandarne il caricamento peggiora direttamente la metrica. Sull’immagine di apertura va fatto l’opposto, cioè caricamento immediato ed eventualmente fetchpriority="high" per farla scaricare prima delle altre risorse.

Evitare i salti di layout

Ogni immagine dovrebbe dichiarare width e height, oppure un aspect-ratio via CSS. Senza queste informazioni il browser non sa quanto spazio riservare e il contenuto sottostante si sposta quando l’immagine arriva: è una delle cause più comuni di Cumulative Layout Shift alto. Vale anche, e soprattutto, per le immagini con caricamento differito.

Gli strumenti

• Squoosh (squoosh.app) per confrontare formati e livelli di qualità su una singola immagine vedendo il risultato affiancato. Utile per capire dove sta il punto di equilibrio.
• ImageMagick o Sharp per convertire e ridimensionare interi archivi da riga di comando o dentro una pipeline di build.
• Plugin WordPress come ShortPixel, Imagify o EWWW Image Optimizer, che comprimono al caricamento e possono riprocessare la libreria esistente. Fai sempre un backup della cartella uploads prima di una riottimizzazione massiva.
• Una CDN con trasformazione al volo, che genera formato e dimensione giusti in base al browser che li richiede. È la soluzione più comoda quando il volume di immagini è alto.

Checklist rapida

1. Nessuna immagine sorgente più larga del doppio dello spazio in cui viene mostrata.
2. WebP come formato predefinito, AVIF dove il flusso di lavoro lo consente.
3. srcset e sizes attivi, non aggirati da inserimenti manuali.
4. Lazy loading su tutto tranne l’immagine principale in cima alla pagina.
5. width e height sempre dichiarati.
6. Immagini decorative con alt vuoto, immagini informative con una descrizione reale del contenuto.

Applicata su un sito medio, questa lista taglia tipicamente il peso delle pagine della metà o più, con un effetto immediato sui tempi di caricamento percepiti e sui Core Web Vitals misurati sul traffico reale.