Il messaggio pubblicitario più comune per gli strumenti di compressione è «riduzione del volume del 70%», un numero impossibile da verificare. Questo articolo non cita statistiche di settore: mostra soltanto una serie di risultati di test reali, con un metodo di confronto completo che chiunque può replicare.
I. Oggetto del test: non originali, ma immagini già «passate» da un'altra compressione
La maggior parte dei test di compressione usa immagini originali direttamente dalla fotocamera, condizioni troppo ideali. Questo test vuole avvicinarsi a uno scenario reale: un sito che consente agli utenti di caricare immagini ha già eseguito una compressione standard al momento del caricamento — quindi l'oggetto del test non sono immagini grezze, ma immagini già compresse una volta.
Campione: 78 cartelle, 4624 immagini (prevalentemente JPG), struttura a directory tipica «una cartella per album», senza alcun filtraggio.
Volume totale originale su server: 1,41 GB.
Domanda chiave: un'immagine già elaborata da uno strumento di compressione, se viene data a un altro strumento, quanto spazio può ancora liberare? La maggior parte degli utenti pensa: «se è già compressa, ricomprimerla non serve».
II. Gruppo di controllo: quanto si risparmia impacchettando in zip?
Prima di eseguire ImgZilla, impacchetto lo stesso file in zip e osserva l'effetto dell'algoritmo di compressione generico:
| Volume | Rispetto all'originale | |
|---|---|---|
| File originale dopo la compressione del sito | 1,41 GB | — |
| Compresso in zip | 1,41 GB | -0,2% |
Quasi nessuna variazione. Il motivo non è complicato: JPEG è di per sé un formato compresso; i dati immagine sono già passati da codifica entropica, quindi un algoritmo generico (zip usa DEFLATE) difficilmente può comprimere ulteriormente dati già compressi — che l'originale abbia o meno subito l'elaborazione del sito, zip non può farci nulla.
III. Test reale di ricompressione con ImgZilla
Trascino i file sopra ImgZilla e avvio la compressione in place. 78 cartelle, 4624 immagini, nomi file e struttura directory completamente preservati:
| Volume | Rispetto all'originale | |
|---|---|---|
| File originale dopo la compressione del sito | 1,41 GB | — |
| Compresso in zip | 1,41 GB | -0,2% |
| Dopo ricompressione con ImgZilla | 0,75 GB | -46,8% |
Sulla base della compressione già eseguita dal sito, ImgZilla risparmia altri 662 MB circa, quasi dimezzando il volume. Percorsi delle cartelle, nomi dei file e gerarchia restano identici: sono dati reali e verificabili, non slogan di marketing.
Questo dimostra un fatto fondamentale: «compressa al caricamento dal sito» e «codifica fine calibrata con parametri specifici per il formato» sono due cose diverse. La maggior parte dei siti esegue una compressione una tantum e prudente al momento del caricamento (di solito limitando solo il parametro qualità o le dimensioni), lontana dallo sfruttare appieno lo spazio di codifica di ciascun formato. ImgZilla calibra i parametri per ogni formato e applica a JPEG una ricodifica visivamente lossless — a livello di pixel ci sono effettivamente differenze, ma i parametri sono impostati su una soglia quasi impercettibile all'occhio umano, riuscendo così a scavare ulteriore spazio su file già compressi.
Va chiarito un concetto facilmente confondibile: «visivamente lossless» non significa «lossless». La vera compressione senza perdita (pixel invariati) è possibile solo per PNG (oxipng) e SVG; JPEG, WebP, AVIF, HEIC e GIF sono per definizione ricodifiche con perdita, solo che i parametri sono tenuti sotto la soglia del visivamente lossless. ImgZilla ha una finestra di confronto integrata che permette di dividere lo schermo prima/dopo, zoomare al 100% e confrontare pixel per pixel, così puoi verificare tu stesso.
IV. Analisi di dettaglio: rapporto di compressione per file, dimensioni pixel e tempi
Il 46,8% complessivo è il risultato aggregato di 4624 immagini. Andando a livello di singolo file si ottengono altri dettagli.
Il rapporto di compressione non è uniforme
Calcolando il rapporto per ogni immagine (byte dopo / byte prima), si va da 32,3% a 85,8%:
- La fascia più alta: circa 765 KB compressi a 109 KB, rapporto 85,8% — in genere immagini con una compressione iniziale insufficiente, con ampio spazio di ricodifica.
- La fascia più bassa: circa 572 KB compressi a 387 KB, rapporto 32,3% — immagini già compresse in modo piuttosto aggressivo, con margini limitati.
- La media aritmetica dei rapporti delle 4624 immagini è 46,44%, vicina ma non identica al 46,8% calcolato sul volume totale — la prima è la media semplice dei rapporti di ogni file; la seconda è «byte risparmiati totali ÷ byte originali totali». La differenza indica che i file con rapporti diversi hanno peso diverso sul totale: pochi file grandi incidono più di tanti piccoli.
Vale la pena notare che tutti i rapporti sono positivi, nessun caso «già minimo, saltato» — ogni immagine di questo lotto, già compressa dal sito, ha potuto essere ulteriormente compressa da ImgZilla.
Dimensioni pixel: identiche
Contando le dimensioni pixel di tutte le 4624 immagini, il formato più comune è 1600×2400 (1756 immagini) e la sua versione orizzontale 2400×1600 (500 immagini). Le dimensioni vanno da 450×675 (circa 300.000 pixel) a 3000×2000 / 2000×3000 (circa 6 milioni di pixel).
Confrontando a campione le dimensioni prima e dopo la compressione, perfettamente invariate:
| File (esempio) | Dimensioni originali | Dimensioni dopo compressione |
|---|---|---|
| Campione 1 | 1600×1066 | 1600×1066 |
| Campione 2 | 2000×3000 | 2000×3000 |
| Campione 3 | 1416×2128 | 1416×2128 |
Anche questa è l'altra metà della definizione di «compressione in place» che spesso viene ignorata: non cambiano solo nome file e percorso, ma anche la risoluzione resta fissa. ImgZilla non ridimensiona e non ritaglia; ogni riduzione di volume deriva esclusivamente dalla ricodifica, non dal sacrificio di pixel.
Tempo di elaborazione: 4624 immagini in 51 minuti e 32 secondi, 0,669 secondi a immagine
Ambiente di test: Mac mini con chip Apple M1, 8 GB di memoria unificata; immagini su NAS con disco meccanico collegato in rete cablata 2,5G.
Seguendo l'ultima data di scrittura di ogni immagine (cioè il momento in cui ImgZilla ha completato e riscritto il file), la prima è stata scritta alle 16:06:09, l'ultima alle 16:57:41: tempo totale 51 minuti e 32 secondi, media 0,669 secondi per immagine.
Questo dato rispecchia il design di «elaborazione seriale» del prodotto — compressione sequenziale, non scrittura parallela casuale. In termini pratici, circa 90 immagini al minuto. La velocità reale dipende dal volume delle immagini e dalle prestazioni della macchina; questo è il tempo effettivo per una media di ~305 KB per immagine in questo ambiente, non un benchmark universale.
V. Perché scegliere la compressione «in place» invece di creare una copia
Se il test avesse usato uno strumento che «salva una copia compressa», il risultato sarebbe: 1,41 GB originali + 0,75 GB compressi = 2,16 GB occupati, e genererebbe una marea di file xxx-min.jpg da riorganizzare manualmente e aggiornare i riferimenti nel database o nelle tabelle prodotti.
ImgZilla sovrascrive in place: il risultato della compressione viene scritto direttamente nel percorso originale. I 4624 nomi file in 78 cartelle restano invariati — un aspetto fondamentale per i siti che hanno già scritto i percorsi delle immagini in database, CDN o CMS. Dopo la compressione non serve modificare alcun link. Il costo è che modifica il file originale, quindi di default sposta prima l'originale nel Cestino di sistema e poi scrive il file compresso; se vuoi tornare indietro, puoi fare clic destro sul file nel Cestino e scegliere «Ripristina».
VI. Analisi dei benefici: dallo scenario reale alla bolletta mensile
Per chi ha valore questo set di dati
- Siti/sviluppatori che gestiscono caricamenti di immagini da parte degli utenti: lo storage immagini e il traffico CDN vengono di solito fatturati a GB; dimezzare il volume significa dimezzare la bolletta — e il traffico è un costo che si genera a ogni accesso, quindi più crescono le visite, più l'interesse composto è evidente. Anche se al caricamento è già stata fatta una compressione standard, questo test dimostra che «far girare un'altra compressione calibrata apposta» dà ancora benefici notevoli.
- Utenti con server a spazio limitato / dischi piccoli: i tool di pulizia eliminano cache e file duplicati, ma dopo qualche mese si riaccumulano; lo spazio liberato dalla compressione è invece file in uso che diventano più piccoli, quindi non torna a riempirsi. Queste 78 cartelle hanno liberato direttamente 662 MB di spazio utilizzabile, in modo permanente.
- Chi sposta spesso dati: in copie, sincronizzazioni e backup, la riduzione del 46,8% riduce i tempi di trasferimento quasi in proporzione. Comprimi una volta e ogni trasferimento successivo farà risparmiare tempo.
Convertito in bolletta mensile: quanto vale questo 46,8%?
Alla fine la riduzione di volume deve riflettersi sulla bolletta per essere convincente. Qui non si citano statistiche del tipo «la compressione aumenta la conversione»: si prende il 46,8% di questo test e lo si moltiplica per le tariffe pubbliche di storage/traffico dei principali provider, in una pura stima aritmetica.
Risparmio storage = volume risparmiato (GB) × prezzo unitario (€/$ per GB al mese)
Risparmio traffico in uscita = volume risparmiato (GB) × download/visite del mese × prezzo unitario (€/$ per GB)
Se il volume si dimezza, entrambe le voci in pratica si dimezzano: è matematica, non una previsione.
Costi di storage: più grande è l'archivio, più alto è il guadagno
Provider nazionali (cinesi):
| Dimensione originale archivio | Volume risparmiato | Alibaba Cloud OSS Standard ¥0,09/GB/mese |
|---|---|---|
| 10 GB | 4,68 GB | ¥0,42/mese |
| 100 GB | 46,8 GB | ¥4,21/mese |
| 1 TB | 479 GB | ¥43,1/mese |
Provider internazionali:
| Dimensione originale archivio | Volume risparmiato | AWS S3 Standard $0,023/GB/mese |
Google Cloud Storage $0,020/GB/mese (Regional, US) |
Azure Blob Storage $0,018/GB/mese (Hot, LRS) |
Cloudflare R2 $0,015/GB/mese |
|---|---|---|---|---|---|
| 10 GB | 4,68 GB | $0,11/mese | $0,09/mese | $0,08/mese | $0,07/mese |
| 100 GB | 46,8 GB | $1,08/mese | $0,94/mese | $0,84/mese | $0,70/mese |
| 1 TB | 479 GB | $11,02/mese | $9,58/mese | $8,62/mese | $7,19/mese |
I prezzi di storage dei grandi provider internazionali sono molto vicini tra loro (differenza entro il 30%); la cosa importante non è chi costa meno, ma che — con qualsiasi provider — dimezzando il volume, la bolletta si dimezza di conseguenza, e il costo è ricorrente ogni mese. Una compressione sola, poi ogni mese si paga in base al nuovo volume: un investimento una tantum con benefici che durano nel tempo.
Costi di traffico: la voce davvero grande, amplificata dalle visite
Il traffico conta più dello storage perché è il prodotto volume × numero di download: più l'immagine viene visitata, più alto è il guadagno dalla compressione. Supponiamo un archivio di 100 GB, con 500 GB di traffico in uscita via CDN in un mese (cioè l'intero archivio scaricato circa 5 volte):
| Tariffa CDN / uscita (primo scaglione) | Costo mensile prima | Dopo compressione (-46,8% traffico) | Risparmio mensile | Risparmio annuale |
|---|---|---|---|---|
| Alibaba Cloud CDN Cina (scaglione basso ¥0,15/GB) | ¥75,0 | ¥39,9 | ¥35,1 | ¥421 |
| AWS CloudFront Asia Pacifico ($0,12/GB) | $60,0 | $31,9 | $28,1 | $337 |
| Google Cloud CDN Nord America/Europa ($0,08/GB) | $40,0 | $21,3 | $18,7 | $224 |
| Azure Front Door standard Zone 1 ($0,08/GB) | $40,0 | $21,3 | $18,7 | $224 |
Sono le tariffe minime di ciascun provider; i prezzi reali a scaglioni sono spesso più alti (per il traffico CDN interno di Alibaba Cloud il livello massimo può arrivare a ¥1,31/GB). Più la bolletta è alta, più il risparmio assoluto è interessante. Azure in questo livello è attualmente Front Door standard: oltre al traffico in uscita a consumo, ha anche un canone base di circa $35/mese che la compressione non può ridurre, quindi non è incluso nel risparmio in tabella.
Cloudflare R2 è un'eccezione: il traffico in uscita è $0 — se il bucket usa R2, il guadagno della compressione si riflette quasi tutto sullo storage, perché la voce traffico non esiste. Questa è una struttura di costo diversa dall'architettura «storage + traffico» (come Alibaba OSS+CDN, AWS S3+CloudFront); prima di scegliere il provider bisogna capire quali voci si pagano.
I prezzi sopra sono le tariffe pubbliche dei provider raccolte nel 2026; i prezzi effettivi dipendono da area geografica, sconti sull'account e scaglioni. Fai riferimento ai prezzi in tempo reale sul sito ufficiale; download/visite sono valori di esempio da sostituire con i dati reali della tua bolletta per una stima.
VII. Risparmio sui tempi di trasferimento e caricamento
Se il volume si dimezza, i tempi di trasferimento si riducono quasi in proporzione — vale sia in locale (copia, backup) sia nel caricamento da parte degli utenti.
Scenario locale: USB 3 e rete Gigabit
- HDD esterno USB 3: throughput tipico 100–150 MB/s, prendiamo la mediana 120 MB/s.
- SSD esterno USB 3: throughput molto più alto, tipico 400–500 MB/s, prendiamo 450 MB/s.
- Rete cablata Gigabit (1000 Mbps): limite teorico 125 MB/s, tolto l'overhead di protocollo, in pratica si attestano 100–110 MB/s, prendiamo 105 MB/s.
Sono stime su intervalli comuni rilevati; la velocità reale dipende da supporto, qualità delle porte e ambiente di rete; servono solo per un calcolo approssimativo.
| Scenario | Volume risparmiato | HDD USB 3 @120 MB/s | SSD USB 3 @450 MB/s | Rete Gigabit @105 MB/s |
|---|---|---|---|---|
| Il lotto di questo test | 662 MB | ≈5,5 s | ≈1,5 s | ≈6,3 s |
| Archivio da 10 GB | 4,68 GB | ≈40 s | ≈10 s | ≈45 s |
| Archivio da 100 GB | 46,8 GB | ≈6,5 min | ≈1,7 min | ≈7,4 min |
| Archivio da 1 TB | 479 GB | ≈66 min | ≈18 min | ≈76 min |
I 662 MB di questo test sembrano pochi, solo pochi secondi. Ma come per lo storage, è un investimento una tantum con benefici che durano: che tu copi dentro/fuori un disco esterno, sincronizzi un NAS, esegua Time Machine, migri a un nuovo Mac o trasferisca a un collega, finché sposti questi dati ogni volta risparmi la stessa percentuale di tempo. Comprimi una volta, ogni trasferimento successivo fa risparmiare tempo.
Se la compressione avviene prima del caricamento dell'utente: il tempo di attesa risparmiato
Quanto calcolato prima riguarda i benefici «dopo che l'immagine è stata salvata»: costi di storage, traffico CDN, trasferimenti locali. Ma c'è un altro aspetto ancora più interessante: il tempo di attesa tra il clic su «Carica» e il completamento della barra. Qui si usa la banda di upload dell'utente, che di solito è il collo di bottiglia più lento di tutta la catena — nella maggior parte delle linee consumer la banda di upload è solo da un decimo a un quinto della download, e sulle reti mobili è ancora più evidente. Se prima dell'upload il sito o l'app comprime le immagini con ImgZilla, il volume risparmiato si traduce direttamente in meno tempo di attesa per l'utente.
Con la dimensione media delle immagini di questo test: le immagini già compresse dal sito sono in media 299 KB; dopo ImgZilla scendono a 159 KB, con un risparmio medio di circa 140 KB per immagine.
| Banda di upload (intervalli tipici da test pubblici, orientativi) | Singola immagine 299KB→159KB |
Upload album da 50 foto ≈15,0MB→8,0MB |
Upload delle 4624 immagini di questo test 1,41GB→0,75GB |
|---|---|---|---|
| Rete mobile (4G/5G combinati, mediana test pubblici nazionali ~10–50 Mbps, prendiamo 30 Mbps) | ≈0,04 s risparmiati | ≈1,9 s risparmiati | ≈3 min risparmiati |
| Upload famiglia tipico (pacchetti 100/1000 Mbps in download, upload limitato ~20–30 Mbps, prendiamo 25 Mbps) | ≈0,04 s risparmiati | ≈2,2 s risparmiati | ≈3,5 min risparmiati |
| Fibra simmetrica Gigabit (pochi operatori/linee business, 1000 Mbps) | ≈0,001 s risparmiati | ≈0,06 s risparmiati | ≈5,3 s risparmiati |
| Riferimento estero: upload medio fisso USA (dati Ookla, 2026) | ≈0,02 s risparmiati | ≈1 s risparmiato | ≈1,5 min risparmiati |
Guardando la singola immagine, la tabella sembra inutile: 0,04 secondi sono impercettibili. Ed è un risultato onesto: questo campione di test è già piccolo (compresso dal sito prima dell'archivio, in media solo 299 KB per immagine). I casi in cui il valore si vede davvero sono due: il caricamento in blocco di un intero album o di decine di immagini, e materiali originali più grandi (come JPEG direttamente dalla fotocamera o UGC al primo upload senza compressione del sito, che in genere pesano diversi MB e non centinaia di KB) — con lo stesso rapporto di compressione, i secondi assoluti risparmiati crescono in proporzione. Per gli utenti mobili con upload già lento, la riduzione dell'attesa è ancora più evidente.
Gli intervalli per reti mobili e banda domestica si basano su statistiche pubbliche nazionali (mediana 4G/5G, rapporti tipici upload/download); la velocità effettiva dipende fortemente da operatore, area, dispositivo e congestione. I valori servono solo come ordine di grandezza. Il dato sull'upload fisso USA cita report Ookla Speedtest.
Vuoi verificare di persona? Scarica ImgZilla direttamente dal Mac App Store, prova con alcune immagini già elaborate del tuo sito e poi decidi se comprimere le altre.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Scopri di più: https://imagetool.app/ImgZilla