Det mest almindelige markedsføringsudsagn for komprimeringsværktøjer er tal som »volumen reduceret med 70 %« – tal, der ikke kan verificeres. Denne artikel citerer ingen branchestatistikker, men viser blot et sæt virkelige testresultater og giver en fuld sammenligningsmetode, som enhver kan reproducere.
1. Testobjekt: ikke originalbilleder, men billeder, der allerede er komprimeret én gang
De fleste komprimeringstests bruger originalbilleder direkte fra kameraet, hvilket er alt for ideelle forhold. Denne test er bevidst lagt tæt på et realistisk forretningsscenarie: en hjemmeside, der tillader brugere at uploade billeder, og som allerede har kørt en almindelig komprimering, når billederne gemmes – det vil sige, at testobjektet ikke er ubehandlede billeder, men færdige billeder, der allerede er blevet »komprimeret én gang«.
Stikprøvestørrelse: 78 mapper, i alt 4.624 billeder (primært JPG), med en mappestruktur, der er typisk arkivering med »et album pr. mappe«, uden nogen filtrering eller oprydning.
Den samlede oprindelige størrelse af disse filer på serveren: 1,41 GB.
Kernespørgsmålet: Hvor meget ekstra plads kan man presse ud af et billede, der allerede er blevet behandlet af et komprimeringsværktøj, når det gives til et andet komprimeringsværktøj? De fleste brugere har en mavefornemmelse af, at »er det først komprimeret, er det komprimeret, og yderligere komprimering giver ikke meget mening«.
2. Kontrolgruppe: Hvor meget kan man spare ved at pakke som zip?
Før du kører ImgZilla, pakkes de samme filer uændret som en zip-fil for at se effekten af en generel komprimeringsalgoritme:
| Størrelse | I forhold til original | |
|---|---|---|
| Originalfiler efter webstedets komprimering | 1,41 GB | — |
| Pakket som zip | 1,41 GB | -0,2 % |
Næsten ingen ændring. Årsagen er ikke kompliceret: JPEG er i sig selv et komprimeringsformat. Billeddataene er allerede entropikodede, og en generel algoritme (zip bruger DEFLATE) kan vanskeligt komprimere allerede komprimeret data yderligere – uanset om originalbilledet er behandlet af webstedet eller ej, kan zip ikke gøre noget ved det.
3. ImgZilla-test med genkomprimering
Træk ovenstående filer ind i ImgZilla, og komprimér på stedet. 78 mapper og 4.624 billeder bevares fuldstændigt med filnavne og mappestruktur:
| Størrelse | I forhold til original | |
|---|---|---|
| Originalfiler efter webstedets komprimering | 1,41 GB | — |
| Pakket som zip | 1,41 GB | -0,2 % |
| Efter ImgZilla-genkomprimering | 0,75 GB | -46,8 % |
Ud over webstedets egen komprimering sparer ImgZilla yderligere ca. 662 MB, hvilket næsten halverer størrelsen. Alle mappestier, filnavne og hierarkier er fuldstændig identiske før og efter – dette er reelle data, der kan verificeres direkte, ikke marketingjargon.
Dette illustrerer en vigtig kendsgerning: »Komprimeret ved upload« og »fintunet kodningskomprimering med formatspecifikke parametre« er to forskellige ting. De fleste websteder udfører en engangs-, forholdsvis konservativ komprimering ved upload (typisk kun med begrænsning af kvalitetsparametre eller dimensioner), som er langt fra at udnytte kodningspotentialet i hvert format. ImgZilla justerer parametrene individuelt for hvert format og udfører visuelt tabsfri omkodning af JPEG – på pixelplan er der ganske vist ændringer, men parametrene er sat inden for et interval, der er næsten umuligt at skelne med det blotte øje, og dermed udvindes mere plads oven i det allerede komprimerede.
En forvirrende term bør afklares: »Visuelt tabsfri« er ikke det samme som »tabsfri«. Ægte tabsfri (hvor pixel er fuldstændig uændret) gælder kun for PNG (oxipng) og SVG; JPEG, WebP, AVIF, HEIC og GIF er principielt tabsgivende omkodninger, men komprimeringsparametrene holdes inden for den visuelt tabsfri tærskel. ImgZilla har et indbygget sammenligningsvindue, der giver mulighed for før/efter-delt skærm, zoom til faktisk størrelse og pixel-for-pixel-sammenligning, så du selv kan verificere.
4. Detaljeret analyse: komprimeringsforhold pr. fil, pixelstørrelser og varighed
Det samlede komprimeringsforhold på 46,8 % er et aggregeret resultat for 4.624 billeder. Når man bryder det ned på enkeltfilniveau, kan man få flere detaljer.
Komprimeringsforholdet er ujævnt fordelt for hvert billede
Beregn komprimeringsforholdet (komprimeret antal bytes / originalt antal bytes) for hvert billede; det spænder fra 32,3 % til 85,8 %:
- Den gruppe med højeste komprimeringsforhold: ca. 765 KB komprimeret til 109 KB, komprimeringsforhold 85,8 % – disse billeder har typisk haft for lidt komprimering fra starten og har stadig et stort omkodningspotentiale.
- Den gruppe med laveste komprimeringsforhold: ca. 572 KB komprimeret til 387 KB, komprimeringsforhold 32,3 % – disse billeder er allerede blevet komprimeret hårdt tidligere, så der er begrænset plads tilbage.
- Det aritmetiske gennemsnit af komprimeringsforholdet for 4.624 billeder er 46,44 %, tæt på, men ikke helt det samme som de 46,8 % beregnet ud fra den samlede størrelse – førstnævnte er et simpelt gennemsnit af hver fils komprimeringsforhold, sidstnævnte er »samlede sparede bytes ÷ samlede originale bytes«. Forskellen viser, at filer med højt og lavt komprimeringsforhold ikke har symmetrisk vægt i den samlede størrelse; nogle få store filer påvirker totalen mere.
Det er værd at bemærke, at komprimeringsforholdet er positivt for alle billeder – der er ingen tilfælde af »allerede minimal, sprunget over« – det vil sige, at hvert eneste af disse »webstedskomprimerede« billeder kan komprimeres yderligere af ImgZilla for at frigøre faktisk plads.
Pixelstørrelse: nøjagtig den samme
Opgør pixelstørrelsen for alle 4.624 billeder; de mest almindelige formater er 1600×2400 (1.756 billeder) og det liggende 2400×1600 (500 billeder). Størrelserne spænder fra de mindste 450×675 (ca. 300.000 pixels) til de største 3000×2000 / 2000×3000 (ca. 6 millioner pixels).
Stikprøvekontrol af pixelstørrelser før og efter komprimering viser, at de er fuldstændig identiske uden nogen ændring:
| Fil (eksempel) | Original størrelse | Størrelse efter komprimering |
|---|---|---|
| Eksempel 1 | 1600×1066 | 1600×1066 |
| Eksempel 2 | 2000×3000 | 2000×3000 |
| Eksempel 3 | 1416×2128 | 1416×2128 |
Dette er den anden halvdel af definitionen på »komprimering på stedet«, som let overses: ikke kun filnavne og stier forbliver uændrede, opløsningen forbliver også fast. ImgZilla hverken skalerer eller beskærer; al størrelsesreduktion stammer udelukkende fra omkodning og ikke fra at ofre pixels.
Varighed: 4.624 billeder færdige på 51 minutter og 32 sekunder – gennemsnitligt 0,669 sekund pr. billede
Testmiljø: Mac mini med Apple M1-chip, 8 GB samlet hukommelse. Billederne var gemt på en NAS-mekanisk harddisk forbundet via 2,5G kablet netværk.
Fremdriften spores via hvert billedes sidste skrivetidspunkt (det tidspunkt, hvor ImgZilla er færdig med komprimeringen og har skrevet billedet tilbage til disk): første billede blev skrevet kl. 16:06:09, sidste billede kl. 16:57:41. Hele batchen tog i alt 51 minutter og 32 sekunder, gennemsnitligt 0,669 sekund pr. billede.
Disse data stemmer overens med produktets design med »seriel behandling« – billederne komprimeres ét ad gangen i rækkefølge frem for at blive skrevet parallelt i tilfældig rækkefølge. Det svarer til ca. 90 billeder i minuttet. Den faktiske hastighed afhænger af billedstørrelse og maskinens ydeevne; det, der er angivet her, er kun den faktiske varighed for denne batch med billeder på gennemsnitligt ~305 KB under ovenstående miljø og er ikke en generel benchmark.
5. Hvorfor vælge »komprimering på stedet« i stedet for at gemme en kopi?
Hvis denne test havde brugt et værktøj, der »gemmer en komprimeret version separat«, ville resultatet være: originalfiler 1,41 GB + komprimeret version 0,75 GB, hvilket fylder 2,16 GB på samme tid – det ville faktisk optage mere plads og generere en lang række xxx-min.jpg-filer, som skulle sorteres manuelt, og referencer i databaser eller produkttabeller skulle opdateres.
ImgZilla anvender overskrivning på stedet: komprimeringsresultatet skrives direkte til den oprindelige sti, og filnavnene i de 78 mapper (4.624 filer) forbliver uændrede. Dette er især vigtigt for websteder, der allerede har billedstierne i databaser, CDN- eller CMS-referencer – ingen links skal ændres efter komprimering. Prisen er, at de originale filer ændres, så ImgZilla som standard flytter originalerne til systemets papirkurv, før komprimeringsresultatet skrives. Hvis du fortryder, kan du højreklikke på filen i papirkurven og vælge »Sæt tilbage på plads«.
6. Fordele ved at analysere: fra reelle scenarier til månedlige regninger
Hvem har reelt gavn af disse data?
- Websteder / udviklere med brugeruploadede billeder: billedlagring og CDN-trafik faktureres normalt pr. GB. En halvering af størrelsen betyder, at regningen direkte halveres – og trafikafgiften er en omkostning, der påløber for hvert eneste besøg. Jo flere besøg, desto mere markant er rentesnuden. Selv hvis der allerede er udført almindelig komprimering ved upload, viser denne test, at »endnu en runde med skræddersyet komprimering« stadig kan give et betydeligt afkast.
- Servere med begrænset lagerplads / brugere med små diske: oprydningsværktøjer sletter typisk caches og dubletter, men de hober sig op igen efter et par måneder. Den plads, der frigøres via komprimering, skyldes, at de filer, der er i brug, bliver mindre – og den vender ikke tilbage. Disse 78 mapper frigav direkte 662 MB brugbar plads efter komprimering, og det er en permanent frigivelse.
- Brugere, der ofte overfører data: Ved kopiering, synkronisering og sikkerhedskopiering reduceres størrelsen med 46,8 %, og overførselstiden forkortes stort set tilsvarende. Komprimér én gang – og spar tid ved hver efterfølgende overførsel.
Regner vi det om til en månedlig regning: hvad er de 46,8 % egentlig værd?
Størrelsesreduktionen skal i sidste ende afspejles på regningen for at være overbevisende. Nedenstående citerer ingen statistikker som »komprimering øger konverteringsraten«, men ganger blot de 46,8 % fra denne test med offentlige priser for lagring/trafik hos førende clouds – en ren aritmetisk beregning.
Lagringsbesparelse = sparet størrelse (GB) × enhedspris (yuan eller USD / GB / måned)
Besparelse på udgående trafik = sparet størrelse (GB) × antal downloads/besøg i måneden × enhedspris (yuan eller USD / GB)
Når størrelsen halveres, reduceres begge regninger også stort set til det halve – det er matematik, ikke gæt.
Lagringsomkostninger: Jo større billetsamling, desto tydeligere er fordelen
Kinesiske udbydere:
| Original størrelse på billetsamling | Sparet størrelse | Alibaba Cloud OSS standardlagring ¥0,09/GB/måned |
|---|---|---|
| 10 GB | 4,68 GB | ¥0,42/måned |
| 100 GB | 46,8 GB | ¥4,21/måned |
| 1 TB | 479 GB | ¥43,1/måned |
Udenlandske udbydere:
| Original størrelse på billetsamling | Sparet størrelse | AWS S3 Standard $0,023/GB/måned |
Google Cloud Storage $0,020/GB/måned (Regional, USA) |
Azure Blob Storage $0,018/GB/måned (Hot, LRS) |
Cloudflare R2 $0,015/GB/måned |
|---|---|---|---|---|---|
| 10 GB | 4,68 GB | $0,11/måned | $0,09/måned | $0,08/måned | $0,07/måned |
| 100 GB | 46,8 GB | $1,08/måned | $0,94/måned | $0,84/måned | $0,70/måned |
| 1 TB | 479 GB | $11,02/måned | $9,58/måned | $8,62/måned | $7,19/måned |
Lagringspriserne hos flere store udenlandske udbydere ligger meget tæt på hinanden (inden for 30 %). Det vigtigste er ikke, hvem der er billigst, men – uanset hvilken udbyder du vælger, halveres størrelsen, og dermed halveres denne regning stort set også, og den faktureres månedligt. Komprimering er en engangsinvestering, der giver løbende afkast, da hver måned efter faktureres efter den nye størrelse.
Trafikomkostninger: Den virkelig store post, der forstærkes med antal besøg
Trafikomkostninger er mere værd at fokusere på end lagringsomkostninger, fordi de er produktet af størrelse × antal downloads – jo oftere billeder tilgås, desto større er komprimeringsgevinsten. Antag et 100 GB billedbibliotek, der i løbet af måneden genererer 500 GB downloadtrafik via CDN (svarende til, at hele biblioteket downloades ca. 5 gange):
| CDN / udgående trafikpris (første trin) | Månedlig trafikomkostning før komprimering | Efter komprimering (trafik -46,8 %) | Besparelse pr. måned | Besparelse pr. år |
|---|---|---|---|---|
| Alibaba Cloud CDN i Kina (lavt trin ¥0,15/GB) | ¥75,0 | ¥39,9 | ¥35,1 | ¥421 |
| AWS CloudFront Asien-Pacific ($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 |
Ovenstående bruger den laveste trinpris hos hver udbyder; de faktiske trinpriser er ofte højere (Alibaba Cloud CDN's trafikpriser i Kina kan nå op på ¥1,31/GB i øverste trin). Jo større regningen er, desto mere markant er den absolutte besparelse ved komprimering. Bemærk desuden, at Azure i denne kategori i øjeblikket er Front Door Standard, som ud over den GB-baserede udgående trafik inkluderer en basisafgift på ca. $35/måned. Denne afgift kan ikke reduceres ved komprimering og er ikke medtaget i besparelserne i tabellen.
Cloudflare R2 er en undtagelse: dens udgående trafik er i sig selv $0 – hvis din bucket bruger R2, viser komprimeringsgevinsten sig næsten udelukkende på lagringsomkostningerne, da der ikke er nogen regning for trafik. Dette er en anden omkostningsstruktur end den dobbelte fakturering med »lagring + trafik« (f.eks. Alibaba Cloud OSS+CDN, AWS S3+CloudFront), så du bør afklare, hvilke omkostningsposter du har, før du vælger udbyder.
Ovenstående priser er samlet fra platformenes offentlige priser i 2026. De faktiske priser kan påvirkes af region, kontorabat og trin; brug altid de aktuelle priser på de officielle hjemmesider. Antallet af downloads og besøg er antagelser i eksemplet – erstat dem med dine egne faktiske regningsdata for at få et estimat.
7. Besparelser på overførsel og uploadtid
Når størrelsen halveres, forkortes overførselstiden stort set tilsvarende – dette forhold afhænger ikke af cloudregninger og gælder både ved lokal kopiering, sikkerhedskopier og ved brugerupload.
Lokale scenarier: USB 3 og gigabit-netværk
- USB 3 ekstern mekanisk harddisk: Vedvarende læse-/skrivehastighed er typisk 100–150 MB/s; vi bruger medianen 120 MB/s.
- USB 3 ekstern SSD: Gennemstrømningen er markant højere, typisk 400–500 MB/s; vi bruger 450 MB/s.
- Gigabit kablet netværk (1000 Mbps): Teoretisk grænse er 125 MB/s; efter fratrækning af protokol overhead er målt vedvarende gennemstrømning ca. 100–110 MB/s; vi bruger 105 MB/s.
Ovenstående er estimerede værdier baseret på typiske måleintervaller. Den faktiske hastighed afhænger af diskmediet, interfacets kvalitet og netværksmiljøet – kun til reference ved estimering.
| Scenarie | Sparet størrelse | USB 3 mekanisk harddisk @120 MB/s | USB 3 SSD @450 MB/s | Gigabit-netværk @105 MB/s |
|---|---|---|---|---|
| Denne testbatch | 662 MB | ≈5,5 sek. | ≈1,5 sek. | ≈6,3 sek. |
| 10 GB billedbibliotek | 4,68 GB | ≈40 sek. | ≈10 sek. | ≈45 sek. |
| 100 GB billedbibliotek | 46,8 GB | ≈6,5 min. | ≈1,7 min. | ≈7,4 min. |
| 1 TB billedbibliotek | 479 GB | ≈66 min. | ≈18 min. | ≈76 min. |
De 662 MB fra denne test ser ikke ud til at være meget ved en enkelt overførsel – kun et par sekunder. Men på samme måde som med lagringsomkostninger er dette en engangsinvestering med løbende afkast: uanset om du kopierer til/fra en ekstern harddisk, synkroniserer en NAS, kører Time Machine, migrerer til en ny Mac eller sender til en kollega – så længe du flytter disse data, sparer du den samme procentdel tid hver gang. Komprimér én gang – og spar tid ved hver efterfølgende flytning.
Hvis komprimeringen sker før brugerupload: sparet ventetid
Det, vi hidtil har beregnet, er fordelene efter »billederne er gemt« – lagringsomkostninger, CDN-trafikafgifter og lokal overførsel. Der er endnu et led, der er værd at overveje: ventetiden fra brugeren trykker på »Upload«, indtil statuslinjen er færdig. Den bruger brugerens egen uploadbåndbredde, og upload er typisk den langsomste flaskehals på hele stien – hos de fleste forbrugerbredbånd er upload kun en tiendedel til en femtedel af download, og det gælder især på mobilt netværk. Hvis webstedet eller appen først komprimerer billedet med ImgZilla, før brugeren uploader det, bliver den sparede størrelse direkte til kortere ventetid for brugeren.
Ud fra den gennemsnitlige billedstørrelse i denne test: originalbillederne, som webstedet allerede havde komprimeret, er gennemsnitligt 299 KB; efter ImgZilla-genkomprimering er de gennemsnitligt 159 KB, hvilket sparer ca. 140 KB pr. billede.
| Uploadbåndbredde (typiske intervaller fra offentlige hastighedstests, kun reference) | Enkelt billede 299KB→159KB |
Upload af album med 50 billeder ≈15,0MB→8,0MB |
Upload af alle 4.624 billeder fra denne test 1,41GB→0,75GB |
|---|---|---|---|
| Mobilt netværk (4G/5G samlet, median fra offentlige hastighedstests i Kina ca. 10–50 Mbps, vi bruger 30 Mbps) | sparer ca. 0,04 sek. | sparer ca. 1,9 sek. | sparer ca. 3 min. |
| Typisk hjemmebredbånd upload (100M/1000M downloadpakker, upload typisk begrænset, ca. 20–30 Mbps, vi bruger 25 Mbps) | sparer ca. 0,04 sek. | sparer ca. 2,2 sek. | sparer ca. 3,5 min. |
| Gigabit symmetrisk bredbånd upload (få udbydere / virksomhedslinjer, 1000 Mbps) | sparer ca. 0,001 sek. | sparer ca. 0,06 sek. | sparer ca. 5,3 sek. |
| Internationalt reference: USA gennemsnitlig fast bredbånds upload (Ookla data, 2026) | sparer ca. 0,02 sek. | sparer ca. 1 sek. | sparer ca. 1,5 min. |
Ser man på tabellen for et enkelt billede, virker den meningsløs – 0,04 sekunder kan næsten ikke mærkes. Det er et ærligt resultat: denne testbatch er i sig selv ikke særlig stor (webstedet komprimerede billederne ved upload, gennemsnitligt kun 299 KB pr. billede). Der er to scenarier, der for alvor viser værdien: batch-operationer, hvor man uploader et helt album eller snesevis af billeder på én gang, og større originale filer (f.eks. JPEG direkte fra kameraet eller første upload af UGC, der ikke er komprimeret af webstedet, og som typisk er flere MB snarere end et par hundrede KB) – ved samme komprimeringsprocent bliver de absolutte sparede sekunder tilsvarende større. For mobile netværksbrugere med i forvejen langsom upload bliver den kortere ventetid endnu mere tydelig.
Intervallerne for mobilnetværk og hjemmebredbånd er baseret på offentlige hastighedsstatistikker i Kina (4G/5G-medianer og typiske upload-profiler for bredbånd). Den faktiske hastighed påvirkes i høj grad af udbyder, region, enhed og netværksbelastning og bør kun bruges som størrelsesreference. Data for fast bredbånds-upload i USA stammer fra rapporter om Ookla Speedtest.
Vil du selv teste? Download ImgZilla direkte fra Mac App Store, prøv det med et par billeder fra din egen hjemmeside, der allerede er behandlet, og beslut derefter, om du vil komprimere resten.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Lær mere: https://imagetool.app/ImgZilla