Komprimeringsverktygens vanligaste marknadsföringsspråk är siffror som ”volymminskning med 70 %”, vilka inte går att verifiera. Den här artikeln citerar ingen branschstatistik – den presenterar bara ett verkligt testresultat, med en komplett jämförelsemetod, så att vem som helst kan upprepa det själv.
1. Testobjektet: inte originalbilder, utan bilder som redan komprimerats av någon annan
De flesta komprimeringstester använder originalbilder direkt från kameran, vilket är en alltför idealisk förutsättning. Detta test är medvetet utformat för att efterlikna en verklig verksamhetssituation: en webbplats som tillåter användare att ladda upp bilder har redan vid inlagringen kört en egen konventionell komprimering – med andra ord är testobjektet inte obearbetade bilder, utan färdiga bilder som redan har ”komprimerats en gång”.
Provstorlek: 78 mappar med totalt 4624 bilder (främst JPG). Katalogstrukturen är typisk arkivering med ”en mapp per album”, utan någon filtrering eller rensning.
Dessa filer har en total originalvolym på servern: 1,41 GB.
Kärnfrågan: hur mycket utrymme kan man pressa ur en bild som redan behandlats av ett komprimeringsverktyg, när man ger den till ett annat komprimeringsverktyg? De flesta användare har en intuition att ”är den redan komprimerad så är den, vidare komprimering spelar knappast någon roll”.
2. Kontrollgrupp: hur mycket kan man spara genom att paketera som zip?
Innan ImgZilla körs paketeras samma filuppsättning oförändrad till en zip-fil för att observera effekten av generella komprimeringsalgoritmer:
| Volym | Relativt originalet | |
|---|---|---|
| Originalfiler efter webbplatsens komprimering | 1,41 GB | — |
| Paketerade till zip | 1,41 GB | -0,2 % |
Nästan ingen förändring. Orsaken är inte komplicerad: JPEG är i sig ett komprimeringsformat. Bilddata har redan genomgått entropikodning, och generella algoritmer (zip använder DEFLATE) har svårt att komprimera redan komprimerad data ytterligare – oavsett om bilden har behandlats av webbplatsen eller inte kan zip inte göra något åt det.
3. ImgZilla-omkomprimering i praktiken
Dra ovanstående filer till ImgZilla och komprimera på plats. 78 mappar med 4624 bilder – filnamn och katalogstruktur behålls helt:
| Volym | Relativt originalet | |
|---|---|---|
| Originalfiler efter webbplatsens komprimering | 1,41 GB | — |
| Paketerade till zip | 1,41 GB | -0,2 % |
| ImgZilla-omkomprimerat | 0,75 GB | -46,8 % |
Utöver webbplatsens egen komprimering sparar ImgZilla ytterligare cirka 662 MB – volymen nästan halveras. Alla mappsökvägar, filnamn och hierarkiska relationer är exakt desamma före och efter – detta är verifierbara, verkliga data, inte marknadsföringssnack.
Detta visar på en viktig sak: ”komprimerad vid uppladdning” och ”finkalibrerad kodningskomprimering med formatspecifika parametrar” är två olika saker. De flesta webbplatser kör en engångskomprimering vid inlagring som är relativt försiktig (oftast bara begränsning av kvalitetsparametrar eller dimensioner), och den utnyttjar inte alla kodningsutrymmen som formatet erbjuder. ImgZilla justerar parametrarna separat för varje format och utför en visuellt förlustfri omkodning av JPEG – det sker visserligen förändringar på pixelnivå, men parametrarna är inställda inom ett intervall som praktiskt taget inte kan uppfattas med blotta ögat, och därmed kan man fortsätta pressa ut utrymme ur redan komprimerade bilder.
En lättförväxlad term behöver förtydligas: ”visuellt förlustfri” är inte samma sak som ”förlustfri”. Verklig förlustfrihet (pixlarna förändras inte alls) gäller endast PNG (oxipng) och SVG; JPEG, WebP, AVIF, HEIC och GIF är i princip förlustbehäftad omkodning, men komprimeringsparametrarna hålls inom det visuellt förlustfria tröskelvärdet. ImgZilla har ett inbyggt jämförelsefönster där du kan visa före/efter sida vid sida, zooma till verklig storlek och jämföra pixel för pixel – för egen verifiering.
4. Detaljerad analys: kompressionsförhållande per fil, pixelmått och tidsåtgång
Den totala kompressionsgraden på 46,8 % ovan är ett aggregerat resultat för 4624 bilder. Genom att bryta ner det på enskild filnivå får man ytterligare detaljer.
Kompressionsförhållandet varierar mellan bilderna
Beräkna kompressionsförhållandet för varje bild (antal byte efter komprimering / antal byte före komprimering); det varierar från 32,3 % till 85,8 %:
- Högst kompressionsförhållande: cirka 765 KB komprimeras till 109 KB, en minskning på 85,8 % – sådana bilder har oftast inte komprimerats tillräckligt hårt från början och har fortfarande stort omkodningsutrymme.
- Lägst kompressionsförhållande: cirka 572 KB komprimeras till 387 KB, en minskning på 32,3 % – dessa bilder har redan komprimerats hårt och har begränsad potential.
- Det aritmetiska medelvärdet av kompressionsförhållandet för 4624 bilder är 46,44 %, vilket ligger nära men inte exakt lika med 46,8 % beräknat på total volym – det förra är ett enkelt medelvärde av varje fils kompressionsförhållande, det senare är ”totala sparade byte ÷ totala ursprungliga byte”. Skillnaden visar att filer med högt respektive lågt kompressionsförhållande inte väger symmetriskt i den totala volymen; ett fåtal stora filer påverkar totalsumman mer.
Det är värt att notera att alla bilder har ett positivt kompressionsförhållande; det finns inga fall av ”redan minimal, hoppa över” – varje bild i denna uppsättning bilder som redan komprimerats av webbplatsen kan alltså komprimeras ytterligare av ImgZilla med faktisk utrymmesbesparing.
Pixelmått: exakt likadana
Statistik för pixelmåtten på alla 4624 bilder: den vanligaste storleken är 1600×2400 (1756 bilder) och dess liggande variant 2400×1600 (500 bilder). Storleksintervallet går från minsta 450×675 (cirka 300 000 pixlar) till största 3000×2000 / 2000×3000 (cirka 6 miljoner pixlar).
Vid stickprovskontroll av pixelmåtten före och efter komprimering är de exakt desamma, utan några ändringar:
| Fil (exempel) | Ursprunglig storlek | Storlek efter komprimering |
|---|---|---|
| Prov 1 | 1600×1066 | 1600×1066 |
| Prov 2 | 2000×3000 | 2000×3000 |
| Prov 3 | 1416×2128 | 1416×2128 |
Detta är den andra hälften i definitionen av ”komprimering på plats” som lätt förbises: inte bara filnamn och sökvägar förblir oförändrade, upplösningen förblir också oförändrad. ImgZilla skalar inte och beskär inte; all volymminskning kommer uteslutande från omkodning, inte från att offra pixlar.
Tidsåtgång: 4624 bilder på 51 minuter och 32 sekunder, i genomsnitt 0,669 sekunder per bild
Testmiljö: Mac mini med Apple M1-chip, 8 GB enhetligt minne. Bilderna ligger på en NAS-mekanisk hårddisk ansluten via 2,5G kabelnätverk.
Förloppet följdes via varje fils senaste skrivningstid (dvs. när ImgZilla avslutade komprimeringen och skrev tillbaka till disken): första bilden skrevs 16:06:09, sista bilden skrevs 16:57:41, hela batchen tog 51 minuter och 32 sekunder, i genomsnitt 0,669 sekunder per bild.
Denna siffra stämmer med produktens design för ”seriell bearbetning” – bilderna komprimeras en efter en i ordning, inte parallellt i oordning. Det motsvarar ungefär 90 bilder per minut. Den faktiska hastigheten beror på bildstorlek och maskinprestanda; siffran här är bara den verkliga tidsåtgången för denna uppsättning bilder på i genomsnitt cirka 305 KB per bild i ovanstående miljö – inte ett allmänt riktmärke.
5. Varför välja komprimering ”på plats” i stället för att spara en kopia?
Om detta test hade använt ett verktyg som ”spara som komprimerad kopia”, skulle resultatet bli: originalfiler 1,41 GB + komprimerade kopior 0,75 GB, totalt 2,16 GB, vilket tvärtom tar mer plats. Dessutom skulle det generera många xxx-min.jpg-filer som kräver manuell sortering och uppdatering av referenser i databasen eller produkttabellen.
ImgZilla använder överskrivning på plats: komprimeringsresultatet skrivs direkt tillbaka till originalets sökväg, och alla 4624 filnamn i de 78 mapparna förblir oförändrade – detta är särskilt viktigt för webbplatser som redan har skrivit in bildsökvägar i databas, CDN eller CMS-referenser; inga länkar behöver ändras efter komprimeringen. Priset är att originalfilerna ändras, så som standard flyttas originalbilderna först till systemets papperskorg innan komprimeringsresultatet skrivs. Vill du ångra dig kan du högerklicka på dem i papperskorgen och välja ”Lägg tillbaka på ursprunglig plats”.
6. Vinstanalys: från verkliga scenarion till månadskostnader
För vem har denna data verkligt värde?
- Webbplatser / utvecklare med användaruppladdade bilder: bildlagring och CDN-trafik debiteras oftast per GB; halverad volym innebär direkt halverade räkningar – och trafikavgiften är en kostnad som uppstår vid varje besök; ju fler besök, desto tydligare blir ränta-på-ränta-effekten. Även om en konventionell komprimering redan utförts vid inlagring, visar detta test att en extra omgång med specialanpassad komprimering fortfarande ger betydande vinster.
- Servrar med ont om lagringsutrymme / användare med små diskar: rensningsverktyg tar vanligtvis bort cache och duplicerade filer, men efter några månader samlas det igen; utrymmet som frigörs genom komprimering är däremot att filerna som redan används blir mindre – det kommer inte tillbaka. Dessa 78 mappar frigjorde direkt 662 MB efter komprimering, och det är permanent frigjort.
- Användare som ofta flyttar data: vid kopiering, synkronisering och säkerhetskopiering minskar volymen med 46,8 %, och överföringstiden förkortas i princip i samma proportion. Komprimera en gång – varje framtida flytt sparar tid.
Omvandlat till månadskostnad: hur mycket är dessa 46,8 % värda?
För att volymminskningen ska vara övertygande måste den slutligen synas på fakturan. Nedan citeras ingen statistik om ”komprimering ökar konvertering” eller liknande; vi multiplicerar bara de uppmätta 46,8 % med de ledande molnleverantörernas offentliga priser för lagring/trafik och gör en ren aritmetisk beräkning.
Lagringsbesparing = sparad volym (GB) × enhetspris (yuan eller USD / GB / månad)
Besparing på utgående trafik = sparad volym (GB) × antal nedladdningar/besök under månaden × enhetspris (yuan eller USD / GB)
Halverad volym innebär i princip att båda posterna halveras – det är matematik, inte gissningar.
Lagringsavgift: ju större bildbibliotek, desto tydligare vinst
Kinesiska leverantörer:
| Bibliotekets ursprungsstorlek | Sparad volym | Alibaba Cloud OSS standardlagring ¥0,09/GB/mån |
|---|---|---|
| 10 GB | 4,68 GB | ¥0,42/mån |
| 100 GB | 46,8 GB | ¥4,21/mån |
| 1 TB | 479 GB | ¥43,1/mån |
Internationella leverantörer:
| Bibliotekets ursprungsstorlek | Sparad volym | AWS S3 Standard $0,023/GB/mån |
Google Cloud Storage $0,020/GB/mån (Regional, USA) |
Azure Blob Storage $0,018/GB/mån (Hot, LRS) |
Cloudflare R2 $0,015/GB/mån |
|---|---|---|---|---|---|
| 10 GB | 4,68 GB | $0,11/mån | $0,09/mån | $0,08/mån | $0,07/mån |
| 100 GB | 46,8 GB | $1,08/mån | $0,94/mån | $0,84/mån | $0,70/mån |
| 1 TB | 479 GB | $11,02/mån | $9,58/mån | $8,62/mån | $7,19/mån |
De stora internationella leverantörernas lagringspriser ligger mycket nära varandra (skillnaden är inom 30 %). Poängen är inte vem som är billigast, utan att – oavsett vilken du väljer – halverad volym innebär att även denna avgiftspost i princip halveras, och den debiteras varje månad. En komprimering innebär att alla efterföljande månader debiteras på den nya volymen; det är en engångsinvestering med långsiktig, återkommande avkastning.
Trafikavgift: den verkliga stora posten, som växer med antalet besök
Trafikavgiften är mer värd att uppmärksamma än lagringsavgiften, eftersom den är produkten av volym × antal nedladdningar – ju oftare bilderna besöks, desto större blir komprimeringsvinsten. Anta ett bildbibliotek på 100 GB som under månaden genererar 500 GB nedströms trafik via CDN (motsvarande att hela biblioteket laddas ner cirka 5 gånger):
| CDN / pris för utgående trafik (första steget) | Månatlig trafikavgift före | Efter komprimering (trafik −46,8 %) | Besparing/månad | Besparing/år |
|---|---|---|---|---|
| Alibaba Cloud CDN i Kina (lågt steg ¥0,15/GB) | ¥75,0 | ¥39,9 | ¥35,1 | ¥421 |
| AWS CloudFront Asien–Stillahavsområdet ($0,12/GB) | $60,0 | $31,9 | $28,1 | $337 |
| Google Cloud CDN Nordamerika/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 |
Ovan är de lägsta stegpriserna hos varje leverantör; de faktiska stegpriserna är ofta högre (Alibaba Cloud CDN:s trafik i Kina kan nå upp till ¥1,31/GB i högsta steget). Ju större fakturan är, desto större blir det absoluta besparingsbeloppet. Dessutom är Azure-nivån ovan för närvarande Front Door Standard; förutom utgående trafik per GB ingår en basavgift på cirka $35/månad. Den avgiften kan inte minskas genom komprimering och ingår inte i besparingssiffrorna i tabellen.
Cloudflare R2 är ett undantag: den utgående trafiken kostar i sig $0. Om du använder R2 som lagring hamnar komprimeringsvinsten nästan helt på lagringsavgiften, eftersom trafikdelen inte har någon räkning alls. Detta är en annan kostnadsstruktur än den dubbla debiteringen med ”lagring + trafik” (t.ex. Alibaba Cloud OSS+CDN, AWS S3+CloudFront), och du måste känna till dina egna avgiftsposter innan du väljer leverantör.
Priserna ovan är sammanställda från plattformarnas offentliga priser 2026. Faktiska priser påverkas av region, kontorabatter och pristeg, så använd den officiella webbplatsens realtidspriser. Antalet nedladdningar och besök är exempelantaganden; ersätt med verkliga data från din egen faktura för uppskattning.
7. Besparingar i överförings- och uppladdningstid
Halverad volym innebär i princip att överföringstiden förkortas i samma proportion – detta gäller oavsett molnfakturor, både vid lokala kopior och säkerhetskopior och vid användarens uppladdning.
Lokala scenarion: USB 3 och gigabitnätverk
- USB 3-portabel mekanisk hårddisk: typisk genomströmning vid kontinuerlig läs/skrivning 100–150 MB/s; vi använder medianvärdet 120 MB/s.
- USB 3-portabel SSD: betydligt högre genomströmning, vanligen 400–500 MB/s; vi använder 450 MB/s.
- Gigabit kabelnätverk (1000 Mbps): teoretisk övre gräns 125 MB/s, men efter protokolloverhead är uppmätt kontinuerlig genomströmning cirka 100–110 MB/s; vi använder 105 MB/s.
Ovanstående är uppskattningar baserade på vanliga uppmätta intervall. Faktisk hastighet påverkas av diskmedium, gränssnittskvalitet och nätverksmiljö – de är endast avsedda som uppskattningsreferens.
| Scenario | Sparad volym | USB 3 mekanisk hårddisk @120 MB/s | USB 3 SSD @450 MB/s | Gigabitnätverk @105 MB/s |
|---|---|---|---|---|
| Bilderna i detta test | 662 MB | ≈5,5 s | ≈1,5 s | ≈6,3 s |
| 10 GB bildbibliotek | 4,68 GB | ≈40 s | ≈10 s | ≈45 s |
| 100 GB bildbibliotek | 46,8 GB | ≈6,5 min | ≈1,7 min | ≈7,4 min |
| 1 TB bildbibliotek | 479 GB | ≈66 min | ≈18 min | ≈76 min |
662 MB i detta enskilda test kan verka lite – bara några sekunder. Men precis som med lagringsavgiften är det en engångsinvestering med långsiktiga, återkommande besparingar: oavsett om du kopierar till/från en extern hårddisk, synkroniserar en NAS, kör Time Machine, migrerar till en ny Mac eller skickar till en kollega – så länge du flyttar dessa data sparar du tid i samma proportion varje gång. Komprimera en gång; varje framtida flytt sparar tid.
Om komprimering sker före användarens uppladdning: sparad väntetid
Det som beräknats ovan är vinster ”efter att bilden har lagrats” – lagringsavgift, CDN-trafikavgift och lokal överföring. Men det finns ytterligare en aspekt som är värd att överväga: väntetiden från att användaren trycker på ”ladda upp” tills förloppsindikatorn är klar. Den går via användarens egen upplänk, och upplänken är vanligtvis den långsammaste flaskhalsen i hela kedjan – de flesta konsumentbredband har bara en tiondel till en femtedel av nedlänken i upplänk, särskilt i mobilnät. Om webbplatsen eller appen först komprimerar bilderna med ImgZilla innan användaren laddar upp, omvandlas den sparade volymen direkt till kortare väntetid för användaren.
Med genomsnittsvolymen per bild från detta test: webbplatsens redan komprimerade originalbilder är i genomsnitt 299 KB, efter ImgZilla-omkomprimering i genomsnitt 159 KB, alltså en besparing på cirka 140 KB per bild.
| Uppladdningsbandbredd (typiska intervall från offentliga hastighetstester, endast vägledande) | En enskild bild 299 KB→159 KB |
Ladda upp album med 50 bilder ≈15,0 MB→8,0 MB |
Ladda upp alla 4624 bilder i testet 1,41 GB→0,75 GB |
|---|---|---|---|
| Mobilnät (4G/5G totalt; median i offentliga mätningar i Kina cirka 10–50 Mbps; 30 Mbps används) | sparar cirka 0,04 s | sparar cirka 1,9 s | sparar cirka 3 min |
| Vanligt hushållsbredband, upplänk (100/1000 Mbps nedlänk, upplänk ofta begränsad till cirka 20–30 Mbps; 25 Mbps används) | sparar cirka 0,04 s | sparar cirka 2,2 s | sparar cirka 3,5 min |
| Gigabit symmetrisk bredbandsupplänk (vissa operatörer/företagslinjer, 1000 Mbps) | sparar cirka 0,001 s | sparar cirka 0,06 s | sparar cirka 5,3 s |
| Utländsk referens: genomsnittlig fast bredbandsupplänk i USA (Ookla-data, 2026) | sparar cirka 0,02 s | sparar cirka 1 s | sparar cirka 1,5 min |
Att titta på den här tabellen för en enskild bild kan verka meningslöst – 0,04 sekunder är nästan omärkbart. Det är ett ärligt resultat: testmaterialet är i sig inte särskilt stort (bilderna var redan komprimerade innan de lades in på webbplatsen, i genomsnitt bara 299 KB per bild). Det finns två scenarion där värdet verkligen syns: batchuppladdning av ett helt album eller tiotals bilder på en gång, samt större originalmaterial (t.ex. JPEG direkt från kamera eller UGC som laddas upp första gången utan webbplatskomprimering, där en enskild bild ofta är flera MB i stället för några hundra KB) – med samma kompressionsgrad skalas de absoluta sparade sekunderna upp i motsvarande grad. För mobilnätsanvändare med redan långsam upplänk blir minskningen av väntetiden ännu tydligare.
Intervallerna för mobilnät och hushållsbredband baseras på offentliga hastighetsmätningar i Kina (median för 4G/5G, vanliga upplänkskvoter för bredband). Faktiska hastigheter påverkas i hög grad av operatör, region, enhet och nätverksbelastning; siffrorna är endast avsedda som storleksordningsreferens. Uppgifterna om fast bredbandsupplänk i USA är hämtade från rapporter om Ookla Speedtest.
Vill du verifiera själv? Ladda ner ImgZilla direkt från Mac App Store, testa med några bilder som redan behandlats på din egen webbplats och bestäm sedan om du vill komprimera fler.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Läs mer: https://imagetool.app/ImgZilla