Guida alla compressione delle immagini: scegliere tra JPG, PNG e WebP
Riepilogo (TL;DR)
Lo scorso fine settimana ho caricato una foto del mio gatto da 4,2 MB su Squoosh con WebP qualità 80. È uscita a 380 KB – una riduzione del 91% – e, onestamente, non riesco a distinguerla dall’originale a nessuna dimensione realistica di schermo. Questa è la compressione lossy che fa esattamente quello che deve fare. Ogni volta che me ne dimentico, apro un blog qualsiasi e aspetto tre secondi perché si carichi un hero JPG da 2 MB in LTE, e la lezione torna a bussare da sola.
Scegliere un formato di immagine non significa tanto trovare “il migliore”, quanto abbinare il formato a uno scopo. Per la fotografia a tono continuo, i formati lossy come JPEG, WebP lossy e AVIF mantengono i file piccoli con una differenza percettiva minima; a parità di qualità visiva, WebP produce tipicamente file più piccoli di circa il 25–35% rispetto a JPEG, mentre AVIF arriva spesso intorno al 40–50% più piccolo di JPEG, a seconda delle impostazioni dell’encoder. Per loghi, icone, screenshot e qualsiasi cosa dove contino bordi netti o leggibilità del testo, i formati lossless come PNG, WebP lossless e TIFF sono più sicuri. Se ti servono trasparenza e animazione insieme, WebP, APNG e AVIF sono le opzioni principali. Il supporto dei browser è ampio a inizio 2026: WebP è disponibile da Chrome 32 (2014), Firefox 65 e Safari 14 (fine 2020), e AVIF funziona in Chrome 85 (agosto 2020), Firefox 93 (ottobre 2021) e Safari 16 (settembre 2022) in poi. Una base di partenza ragionevole è “SVG per i loghi vettoriali, WebP o AVIF per le foto, PNG per gli screenshot”, con un fallback <picture> su JPEG quando devi supportare ambienti più vecchi.
Contesto e concetti
I formati lossy (JPEG, WebP lossy, AVIF) riducono la dimensione del file scartando informazioni a cui il sistema visivo umano è meno sensibile. Due tecniche di base guidano tutto questo: la quantizzazione, che arrotonda i coefficienti nel dominio delle frequenze in modo più aggressivo per le alte frequenze spaziali, e il chroma subsampling, che memorizza i canali cromatici a risoluzione inferiore rispetto alla luminanza. Un’impostazione 4:4:4 preserva la crominanza a piena risoluzione, mentre il più comune 4:2:0 dimezza la crominanza in entrambe le direzioni. Quel default va bene per la maggior parte delle foto, ma può sfocare i bordi di testo colorato, soprattutto caratteri rossi e blu su sfondo scuro.
JPEG, standardizzato nel 1992, usa una trasformata discreta del coseno (DCT) a blocchi applicata su blocchi di 8×8 pixel. WebP si basa sulle tecniche intra-frame del codec video VP8, e AVIF usa il toolset intra-frame di AV1. Entrambi sono quindi sostanzialmente più moderni di JPEG nel modo in cui predicono, trasformano e quantizzano i dati dell’immagine, con blocchi più grandi, predizione direzionale e un miglior entropy coding. PNG è un animale diverso: è un formato lossless che usa la famiglia di compressione deflate, con supporto integrato per trasparenza alpha e colore indicizzato basato su palette. PNG non scarta mai dati, ma per contenuti fotografici questa purezza si paga con file molto più grandi.
Un concetto correlato è la decodifica progressiva. Il JPEG progressivo e il PNG interlacciato permettono a un visualizzatore di vedere subito una versione a bassa risoluzione dell’immagine e di affinarla man mano che arrivano altri byte. WebP e AVIF oggi generalmente decodificano in un’unica passata, il che conta soprattutto per immagini molto grandi o connessioni lente. SVG, infine, non è un formato raster compresso ma una descrizione vettoriale; la dimensione del file è guidata dal numero di forme e dalla compressione del testo stesso (gzip e brotli sono molto efficaci sul sorgente SVG).
Confronto e dati
| Formato | Lossy | Lossless | Trasparenza | Animazione | Compressione tipica (foto) | Supporto browser 2025 |
|---|---|---|---|---|---|---|
| JPEG | Sì | No | No | No | Circa 10:1 | Tutti i browser |
| PNG | No | Sì | Sì | Estensione APNG | Circa 2–3:1 | Tutti i browser |
| WebP | Sì | Sì | Sì | Sì | ~25–35% più piccolo di JPEG | Safari 14 (2020) e successivi, di fatto universale |
| AVIF | Sì | Sì | Sì | Sì | ~40–50% più piccolo di JPEG | Chrome 85+, Firefox 93+, Safari 16+ |
| GIF | Sì (palette 256 colori) | No | Solo 1 bit | Sì | Scarso per foto | Tutti i browser |
Considera questi numeri come tendenze generali. La compressione reale dipende molto da contenuto sorgente, encoder, preset e qualità target. Lo stesso JPEG a qualità 85 e a qualità 60 può differire di 3–4 volte in dimensione, e il vantaggio di efficienza di AVIF si riduce quando usi preset veloci. I benchmark pubblicati da Google e Mozilla tra il 2019 e il 2023 hanno riportato risparmi WebP intorno al 26–34% rispetto a JPEG a SSIM equivalente, e risparmi AVIF intorno al 40–50% rispetto a JPEG – ma quegli intervalli assumono encoder con preset lenti e qualità target calibrate, non i default a un clic della maggior parte delle app di editing.
Un’altra dimensione è il costo di codifica e decodifica. JPEG decodifica in frazioni di millisecondo su qualunque dispositivo. WebP è molto vicino. La decodifica AVIF è più pesante per la CPU, e la codifica AVIF su preset ad alta qualità può richiedere secondi per immagine. Quel profilo di costo va bene per una pipeline di asset a build time ma è scomodo per contenuti user-generated dal vivo dove un server ricodifica ogni upload sul percorso critico.
Scenari reali
Scenario 1 — Thumbnail e immagini hero del blog. Il mese scorso ho fatto un audit del mio sito e ho trovato un’immagine hero pesante 1,8 MB. Riesportandola in WebP qualità 82 è scesa a 210 KB, e il Largest Contentful Paint della pagina è crollato da 2,4 s a 1,1 s su un profilo 4G simulato in Lighthouse. Metti WebP come formato primario e lascia che un elemento <picture> serva JPEG come fallback per ambienti molto vecchi. Ridimensiona sempre l’immagine esportata alla larghezza effettiva di visualizzazione CSS; servire una foto larga 3000 pixel in un contenitore da 600 pixel spreca banda indipendentemente dal formato.
Scenario 2 — Loghi e icone. Se hai un sorgente vettoriale, esporta SVG come prima scelta. Una volta ho revisionato una landing page dove un logo rosso del brand era stato esportato come JPEG a qualità 75; i bordi rossi sanguinavano in un alone rosa attorno a ogni glifo. Il chroma subsampling a 4:2:0 rovina i bordi rosso-su-scuro prima di quasi tutto il resto. Se hai solo artwork raster, scegli PNG o WebP lossless. Considera la compressione lossy sui loghi come un segnale di allarme, non un’ottimizzazione.
Scenario 3 — Screenshot e catture UI. Gli screenshot dovrebbero avere PNG come default. La chrome del browser, gli snippet di codice e i font CJK mostrano artefatti JPEG in modo forte – l’ho imparato dopo che un revisore di documentazione mi ha segnalato “font monospace sfocato” su due PR consecutive. Se devi ridurre il file, ricorri a pngquant (su macOS, brew install pngquant) per ridurre la palette a 256 colori; gli screenshot di UI quasi mai mostrano la differenza, e il file spesso si riduce di 4–6 volte. Per i siti di documentazione, considera di abbinare PNG a markup di immagini responsive CSS in modo che i display Retina ricevano asset 2x mentre gli schermi più vecchi scaricano la versione 1x – di solito ciò risparmia più byte che cambiare formato.
Scenario 4 — Archiviazione di materiale sorgente. Per originali che potresti rielaborare in futuro (master fotografici, scansioni raw, foto di prodotto), conserva una copia lossless come TIFF o WebP lossless in cold storage e deriva le varianti di consegna lossy su richiesta. Ricomprimere un JPEG lossy ripetutamente degrada la qualità ad ogni ciclo (“generation loss”), quindi vuoi avere un sorgente pulito a cui tornare.
Errori comuni
“PNG è sempre la qualità più alta.” È lossless, il che significa riproduzione perfetta, ma per le fotografie quella purezza si traduce in file diverse volte più grandi del necessario. Su mobile, foto da più megabyte danneggiano il tempo di caricamento percepito e i Core Web Vitals.
“WebP non funziona in tutti i browser.” Da Safari 14 a fine 2020, WebP è supportato in ogni browser mainstream. Se il supporto legacy è davvero necessario, un elemento <picture> con fallback JPEG è una soluzione pulita.
“AVIF è magico.” L’efficienza di compressione è eccellente, ma la codifica è significativamente più lenta di JPEG o WebP. Sul mio MacBook Air M2, avifenc --speed 4 richiede 5–9 secondi per una singola foto da 2400×1600; a --speed 0, aspettati 30 s o più. Anche la decodifica su dispositivi mobili più vecchi può essere un problema. AVIF si adatta meglio a pipeline batch e ottimizzazione a build time rispetto alla ricodifica di ogni upload utente sul percorso critico.
“Basta usare JPEG.” Era ragionevole fino al 2015 circa, ma WebP e AVIF moderni generalmente offrono file più piccoli a qualità comparabile con supporto universale o quasi. Le nuove pipeline dovrebbero trattare WebP come linea di base invece di JPEG.
“Le impostazioni di qualità più alte valgono sempre la pena.” Sopra la qualità 85 circa per JPEG o WebP, la dimensione del file cresce più velocemente della qualità percettiva. Gli spettatori raramente notano la differenza tra qualità 85 e 95, ma il file può essere il doppio. Misura con una metrica percettiva (SSIM, butteraugli) invece di fidarti dello slider di qualità come se fosse una scala lineare.
“Se comprimo bene, ridimensionare non conta.” I guadagni più grandi nella consegna delle immagini di solito arrivano dall’inviare immagini di dimensione appropriata piuttosto che dal tuning della compressione. Un WebP largo 800 pixel è quasi sempre più leggero di un WebP largo 3000 pixel, indipendentemente dall’impostazione di qualità, perché stai rimuovendo pixel invece di approssimarli.
Lista di controllo
- La sorgente è vettoriale? Se sì, salva come SVG.
- Ti serve la trasparenza?
- Sì e il contenuto è fotografico: WebP lossy con alpha o AVIF.
- Sì e il contenuto è un logo o un’icona: PNG o WebP lossless.
- Ti serve animazione? WebP animato, APNG o AVIF. La palette a 256 colori di GIF è scarsa per le foto.
- Il contenuto è fotografico o ricco di gradienti? Default su WebP lossy, e aggiungi AVIF dove la banda conta.
- Il contenuto è uno screenshot o una UI ricca di testo? Preferisci PNG o WebP lossless.
- Ti serve massima compatibilità? Usa un elemento
<picture>con sorgenti AVIF → WebP → JPEG in quell’ordine.
Strumento correlato
Puoi provare questi compromessi direttamente nel compressore di immagini di Patrache Studio indicato in relatedToolUrl. Le immagini di solito fanno parte di una pipeline di asset più ampia, quindi leggere le guide compagne aiuta: Unione e separazione di PDF nel browser copre cosa succede quando le tue immagini finiscono dentro contratti o fascicoli scansionati, e Sicurezza dei codici QR vale la pena leggerla se le tue immagini includono codici QR scansionabili su packaging di prodotto o poster.
Riferimenti
- MDN, “Image file type and format guide” — https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types
- web.dev, “Serve images in modern formats (WebP)” — https://web.dev/articles/serve-images-webp
- AOMedia, “AV1 Image File Format (AVIF)” specification — https://aomediacodec.github.io/av1-avif/
- W3C, “Portable Network Graphics (PNG) Specification” — https://www.w3.org/TR/png/