Per ottimizzare le immagini per il web nel 2026 la strategia vincente è: convertire in formato AVIF come prima scelta (fino al 50% più leggero di WebP, 80% più di JPEG) con fallback WebP per i browser più vecchi, specificare sempre larghezza e altezza per evitare layout shift, e usare `loading="lazy"` per tutto ciò che non è visibile al caricamento iniziale. Questi tre accorgimenti coprono l'80% dei guadagni di performance legati alle immagini.
JPEG, WebP, AVIF: quale formato scegliere e quando
JPEG è il formato più antico e compatibile ma il meno efficiente. WebP, creato da Google, offre file del 25-34% più piccoli di JPEG a parità di qualità percepita e supporta la trasparenza. AVIF, basato sul codec AV1, è il formato più moderno: a parità visiva i file pesano il 40-50% in meno di WebP. Il supporto browser per AVIF ha superato il 95% globale nel 2025, rendendolo sicuro da usare come formato primario con fallback WebP nell'elemento `<picture>`.
Per le immagini con trasparenza (loghi, icone, illustrazioni), WebP e AVIF supportano entrambi il canale alpha, rendendo obsoleto il PNG pesante. Un logo PNG da 450 KB diventa un WebP da 40 KB e un AVIF da 25 KB senza perdita visiva percettibile. PNG rimane preferibile solo per immagini che richiedono assoluta precisione pixel (screenshot di interfacce, grafici tecnici): in tutti gli altri casi WebP o AVIF sono superiori.
Nei progetti che seguiamo a Milano abbiamo adottato AVIF come standard dal 2024. I risultati medi che registriamo: pagine con gallerie di prodotti passano da 3-4 MB di immagini totali a 400-600 KB in AVIF. Questa riduzione si traduce direttamente in LCP più bassi di 1-2 secondi su connessioni mobili. La conversione richiede un investimento tecnico iniziale (setup pipeline di generazione), ma l'impatto sulle metriche è immediato e misurabile.
Come implementare AVIF con fallback WebP in HTML
L'elemento `<picture>` permette di fornire formati multipli: il browser scarica solo quello che supporta. Struttura corretta: primo `<source>` con AVIF, secondo con WebP, e `<img>` finale con JPEG come fallback assoluto. Specifica sempre `width` e `height` sull'`<img>` per permettere al browser di riservare lo spazio prima del caricamento, azzerando il CLS. Su Next.js il componente `<Image>` gestisce tutto questo automaticamente inclusa la generazione dei formati.
Il pattern HTML corretto è: `<picture><source type="image/avif" srcset="img.avif"><source type="image/webp" srcset="img.webp"><img src="img.jpg" width="800" height="600" alt="descrizione" loading="lazy"></picture>`. L'ordine delle `<source>` è importante: il browser usa la prima che supporta. Se metti WebP prima di AVIF, i browser che supportano entrambi useranno WebP invece del più efficiente AVIF. La struttura è verbosa ma è esattamente quello che Next.js `<Image>` genera automaticamente dietro le quinte.
Strumenti per convertire e comprimere le immagini
- Squoosh.app (Google): conversione WebP/AVIF nel browser con preview side-by-side e comparazione SSIM in tempo reale
- Sharp (Node.js): libreria per elaborazione batch server-side, usata da Next.js internamente, supporta pipeline complesse
- ImageOptim (macOS): ottimizzazione lossless di JPEG, PNG e GIF con interfaccia drag-and-drop
- Cloudflare Images: CDN che converte automaticamente nel formato ottimale per ogni browser via URL parametrici
- TinyPNG/TinyJPEG: compressione lossy online semplice, ottima per team non tecnici
- libavif (CLI): conversione AVIF da riga di comando, il più flessibile per pipeline CI/CD
- Imagemin (npm): bundler-agnostic, integra con Webpack/Vite per ottimizzazione automatica al build time
Dimensioni responsive: srcset e sizes
Un errore comune è caricare immagini da 2000px su mobile dove la larghezza è 390px. L'attributo `srcset` permette di fornire versioni multiple: il browser sceglie la dimensione appropriata in base alla viewport e alla densità di pixel dello schermo. Il companion `sizes` descrive quanto spazio occuperà l'immagine in CSS: ad esempio `sizes="(max-width: 768px) 100vw, 50vw"` dice al browser che l'immagine è larga tutto lo schermo su mobile e metà su desktop.
I breakpoint che usiamo come standard nei nostri progetti: 400w, 800w, 1200w, 1600w, 2400w. Per ogni breakpoint generiamo varianti AVIF e WebP. Un'immagine hero full-width su desktop viene servita a 1600px su schermo 1920px (density 1x) o a 2400px su schermo Retina (density 2x). La stessa immagine su mobile a 390px viene servita a 400px — un risparmio dell'85% in pixel, con AVIF ancora più compresso. Il browser fa tutto questo automaticamente se il `srcset` è corretto.
La regola che applichiamo per il calcolo delle dimensioni: genera varianti ogni 400px fino a 2400px per le immagini full-width, e ogni 200px fino a 800px per le immagini in container più piccoli (colonne, card). Non ha senso avere varianti ogni 50px: la differenza percettiva è nulla e il numero di file da generare e mantenere esplode.
Lazy loading: carica solo ciò che è visibile
Il lazy loading nativo (`loading="lazy"`) rimanda il caricamento delle immagini fuori dalla viewport finché l'utente non scorre verso di esse. Non va mai usato sull'immagine LCP (quella principale above-the-fold): quella va precaricata con `<link rel="preload">` e `fetchpriority="high"`. Nelle realizzazioni di siti web applichiamo lazy loading a tutte le immagini tranne la prima, migliorando il LCP senza sacrificare le immagini successive.
Il comportamento del lazy loading nativo varia leggermente tra i browser: Chrome inizia a caricare le immagini quando sono a circa 1200-1500px dalla viewport (distanza sufficiente per un pre-caricamento fluido), Firefox è simile. Questo significa che su uno scroll veloce l'utente potrebbe vedere brevemente un'immagine vuota prima che si carichi: è accettabile per la maggior parte dei casi. Per gallerie con molte immagini piccole o per portfolio fotografici usa intersection observer con placeholder blur per un'esperienza più fluida.
Immagini decorative vs contenuto: la differenza conta
Le immagini decorative (sfondi, pattern, dividers) vanno gestite come CSS background-image, non come `<img>`. Questo permette di escluderle dal calcolo del LCP e di usare media queries CSS per non caricarle affatto su mobile. Le immagini di contenuto (foto prodotto, hero principale, immagini nei blog post) vanno invece come `<img>` con `alt` descrittivo per accessibilità e indicizzazione Google Images.
Un caso limite frequente: le immagini nei banner pubblicitari o nelle sezioni "feature" con testo sovrapposto. Tecnicamente sono decorative (il contenuto è nel testo), ma spesso contengono informazioni visive importanti. La regola che applichiamo: se l'immagine ha un valore informativo autonomo (capisci qualcosa guardando solo l'immagine), va come `<img>` con alt descrittivo. Se è solo un fondale estetico, va come CSS background-image con possibilità di nasconderla su mobile via media query.
CDN per le immagini: trasformazione on-the-fly
I CDN specializzati per immagini come Cloudinary, Imgix, o Cloudflare Images permettono di caricare l'originale ad alta risoluzione e richiedere la versione ottimizzata tramite URL parametrici. Il servizio genera automaticamente le varianti, le converte in AVIF/WebP, le comprime e le distribuisce dall'edge più vicino all'utente. Per i siti con molte immagini o e-commerce con cataloghi di prodotti questo approccio è più scalabile della generazione offline.
Cloudflare Images ha un pricing competitivo: 5$ al mese per 100.000 immagini servite. Per un e-commerce con catalogo di 500 prodotti e 50.000 visite mensili è un costo irrisorio a fronte dei guadagni in performance. Cloudinary ha un piano gratuito fino a 25.000 trasformazioni al mese. Per i progetti che realizziamo in Next.js, il provider di immagini integrato di Next.js (`next/image` con custom loader) permette di integrare Cloudinary o Imgix in pochi minuti.
Next.js Image: ottimizzazione automatica out of the box
Il componente `<Image>` di Next.js è il punto di partenza per qualsiasi progetto che seguiamo. Gestisce automaticamente: generazione WebP e AVIF, lazy loading, placeholder blur durante il caricamento, srcset con breakpoint configurabili, e prevenzione del layout shift con le dimensioni. L'unico requisito è specificare `width` e `height` (o usare `fill` per immagini in container flessibili). Questa sola scelta tecnica risolve il 70% dei problemi di immagini.
Una feature di Next.js `<Image>` spesso sottovalutata è il placeholder blur. Passando `placeholder="blur"` e `blurDataURL` (o lasciando che Next.js lo generi automaticamente per immagini locali), l'immagine mostra un'anteprima sfocata a bassa risoluzione mentre quella ad alta risoluzione si carica. Questo elimina il "flicker" del bianco vuoto e migliora la percezione di velocità anche se il tempo di caricamento tecnico è lo stesso. Per i siti web che costruiamo, è un'opzione che abilitiamo sempre per le immagini hero e le card dei prodotti.
Ottimizzare le immagini nei CMS: WordPress e headless
Per i siti WordPress, il plugin ShortPixel o Imagify converte automaticamente in WebP le immagini caricate nella Media Library e serve la versione corretta tramite `<picture>`. Questa è la soluzione più rapida per migliorare le performance su siti esistenti senza toccare il codice. Il limite: non gestiscono AVIF (ShortPixel solo in piani a pagamento avanzati) e non ottimizzano le immagini già caricate senza ri-processarle manualmente.
Per i CMS headless (Contentful, Sanity, Strapi) la strategia migliore è usare il CDN di trasformazione immagini del CMS stesso: Contentful Images API supporta WebP e AVIF via parametri URL, Sanity ha Sanity Image Pipeline con supporto AVIF nativo. Questo approccio centralizza la logica di ottimizzazione nel CMS e non richiede codice custom nel frontend. Per i clienti che gestiamo con CMS headless, questa è la configurazione standard che impostiamo durante il setup iniziale del progetto.
