De meest voorkomende marketingbelofte van compressietools is zo’n niet-verifieerbaar getal als “70% kleiner”. Dit artikel citeert geen enkele branchestatistiek, maar toont een set echte testresultaten met een volledige vergelijkingsmethode die iedereen zelf kan reproduceren.
1. Testobject: geen originele afbeeldingen, maar afbeeldingen die “al door iemand anders zijn gecomprimeerd”
De meeste compressietests gebruiken originele, rechtstreeks uit de camera afkomstige afbeeldingen; dat is een te ideale uitgangssituatie. Deze test is bewust afgestemd op een realistisch bedrijfsscenario: een website waarop gebruikers afbeeldingen kunnen uploaden, voert bij binnenkomst al een eigen, reguliere compressieronde uit – met andere woorden, het testmateriaal bestaat niet uit onbewerkte beelden, maar uit afgewerkte afbeeldingen die al “één keer gecomprimeerd” zijn.
Omvang van de steekproef: 78 mappen, in totaal 4624 afbeeldingen (voornamelijk JPG), met een typische mappenstructuur van “één album per map”, zonder enige selectie of opschoning.
De totale oorspronkelijke omvang van deze bestanden op de server: 1,41 GB.
Kernvraag: hoeveel ruimte valt er nog uit een afbeelding te halen die al door een compressietool is verwerkt, als je hem door een andere compressietool haalt? Veel gebruikers gaan ervan uit dat “iets dat al gecomprimeerd is, bij verdere compressie weinig oplevert”.
2. Controlegroep: hoeveel bespaart een zip-archief?
Voordat ImgZilla wordt uitgevoerd, wordt eerst dezelfde batch bestanden ongewijzigd in een zip-archief verpakt om te zien wat een generiek compressie-algoritme oplevert:
| Omvang | T.o.v. origineel | |
|---|---|---|
| Originele bestanden na websitecompressie | 1,41 GB | — |
| Als zip-archief | 1,41 GB | -0,2% |
Er is vrijwel geen verschil. De reden is niet ingewikkeld: JPEG is zelf al een compressieformaat; de beeldgegevens hebben al een entropiecodering ondergaan, waardoor een generiek algoritme (zip gebruikt DEFLATE) nauwelijks verdere compressie kan realiseren op al gecomprimeerde gegevens – of het origineel nu door de website is bewerkt of niet, zip kan hier niets aan doen.
3. Praktijktest: hercompressie met ImgZilla
Sleep bovengenoemde bestanden naar ImgZilla en comprimeer ze op de oorspronkelijke locatie. De 78 mappen en 4624 afbeeldingen behouden volledig hun bestandsnamen en mappenstructuur:
| Omvang | T.o.v. origineel | |
|---|---|---|
| Originele bestanden na websitecompressie | 1,41 GB | — |
| Als zip-archief | 1,41 GB | -0,2% |
| Opnieuw gecomprimeerd met ImgZilla | 0,75 GB | -46,8% |
Op basis van de compressie die de website al had toegepast, bespaart ImgZilla nog eens ongeveer 662 MB; het volume wordt bijna gehalveerd. Alle mappaden, bestandsnamen en hiërarchische relaties blijven voor en na volledig identiek – dit zijn direct verifieerbare echte gegevens, geen marketingtaal.
Dit illustreert een belangrijk feit: “gecomprimeerd bij het uploaden op de website” is iets anders dan “fijn afgestelde codering met formatspecifieke parameters”. De meeste websites voeren bij binnenkomst een eenmalige, vrij conservatieve compressie uit (meestal alleen een beperking van de kwaliteitsparameter of afmetingen), waardoor de coderingsruimte van elk formaat lang niet volledig wordt benut. ImgZilla stemt de parameters per formaat afzonderlijk af en past op JPEG visueel verliesvrije hercodering toe – op pixelniveau verandert er wel degelijk iets, maar de parameters worden zo gekozen dat het verschil met het blote oog vrijwel niet waarneembaar is. Zo wordt op basis van “al gecomprimeerd” verder ruimte gewonnen.
Er moet een verwarrend begrip worden verduidelijkt: “visueel verliesvrij” is niet hetzelfde als “verliesvrij”. Echt verliesvrij (pixels blijven exact gelijk) is alleen van toepassing op PNG (oxipng) en SVG; JPEG, WebP, AVIF, HEIC en GIF zijn in principe verliesgevende hercoderingen, alleen worden de compressieparameters binnen de drempel van visueel verliesvrij gehouden. ImgZilla heeft een ingebouwde vergelijkingsweergave met split screen voor en na, inclusief zoomen op ware grootte voor pixel-voor-pixel-vergelijking, zodat je het zelf kunt controleren.
4. Detailanalyse: compressieverhouding per bestand, pixelafmetingen en taakduur
De totale compressie van 46,8% is het geaggregeerde resultaat van de 4624 afbeeldingen. Op het niveau van individuele bestanden zijn meer details te zien.
Ongelijke compressieverhouding per afbeelding
Als je voor elke afbeelding de compressieverhouding berekent (aantal bytes na compressie / aantal bytes vóór compressie), varieert deze van 32,3% tot 85,8%:
- Hoogste compressieverhouding: ongeveer 765 KB teruggebracht tot 109 KB, een compressie van 85,8% – dit soort afbeeldingen heeft doorgaans onvoldoende initiële compressie gehad en biedt nog veel ruimte voor hercodering.
- Laagste compressieverhouding: ongeveer 572 KB teruggebracht tot 387 KB, een compressie van 32,3% – deze afbeeldingen waren al vrij sterk gecomprimeerd en bieden nog maar beperkte mogelijkheden.
- Het rekenkundig gemiddelde van de compressieverhouding van de 4624 afbeeldingen is 46,44%, dicht bij maar niet identiek aan de 46,8% op basis van het totale volume – het eerste is het eenvoudige gemiddelde van de compressieverhoudingen van alle bestanden, het tweede is “totaal bespaarde bytes ÷ totaal oorspronkelijke bytes”. Het verschil laat zien dat bestanden met verschillende compressieverhoudingen niet symmetrisch bijdragen aan het totale volume; een paar grote bestanden hebben meer invloed op het totaal.
Het is opmerkelijk dat de compressieverhouding van elke afbeelding positief is; er is geen geval van “al minimaal, overgeslagen” – met andere woorden, van deze “door de website gecomprimeerde” afbeeldingen kan ImgZilla bij elke afbeelding daadwerkelijk extra ruimte winnen.
Pixelafmetingen: geen enkel verschil
Als je de pixelafmetingen van alle 4624 afbeeldingen bekijkt, is de meest voorkomende afmeting 1600×2400 (1756 afbeeldingen) en de liggende variant 2400×1600 (500 afbeeldingen); de afmetingen variëren van de kleinste 450×675 (ongeveer 300.000 pixels) tot de grootste 3000×2000 / 2000×3000 (ongeveer 6 miljoen pixels).
Bij steekproeven blijken de pixelafmetingen voor en na compressie volledig identiek, zonder enige verandering:
| Bestand (voorbeeld) | Originele afmeting | Afmeting na compressie |
|---|---|---|
| Voorbeeld 1 | 1600×1066 | 1600×1066 |
| Voorbeeld 2 | 2000×3000 | 2000×3000 |
| Voorbeeld 3 | 1416×2128 | 1416×2128 |
Dit is het vaak over het hoofd geziene andere deel van de definitie van “compressie op de oorspronkelijke locatie”: niet alleen blijven bestandsnaam en pad ongewijzigd, ook de resolutie blijft vast. ImgZilla schaalt niet en cropt niet; al het ruimteverlies komt uitsluitend voort uit hercodering, niet uit het opofferen van pixels.
Taakduur: 4624 afbeeldingen in 51 min 32 sec, gemiddeld 0,669 sec per afbeelding
Testomgeving: Mac mini met Apple M1-chip, 8 GB uniform geheugen; de afbeeldingen stonden op een NAS-harde schijf die via een 2,5G bekabeld netwerk was aangesloten.
De voortgang van de taak is gevolgd aan de hand van de laatste schrijftijd van elke afbeelding (het moment waarop ImgZilla de compressie voltooit en terugschrijft naar de schijf): de eerste werd geschreven om 16:06:09, de laatste om 16:57:41, de totale verwerkingstijd voor de hele batch was 51 min 32 sec, gemiddeld 0,669 sec per afbeelding.
Dit cijfer past bij het “seriële verwerking”-ontwerp van het product – elke afbeelding wordt na elkaar gecomprimeerd, niet parallel in willekeurige volgorde weggeschreven. Omgerekend zijn dat ongeveer 90 afbeeldingen per minuut. De werkelijke snelheid hangt af van de bestandsgrootte van de afbeeldingen en de prestaties van de machine; dit getal is alleen de werkelijke verwerkingstijd voor deze batch met een gemiddelde van ~305 KB per afbeelding in bovengenoemde omgeving, en is geen algemene benchmark.
5. Waarom comprimeren op de oorspronkelijke locatie in plaats van een kopie opslaan?
Als voor deze test een tool was gebruikt die “een gecomprimeerde versie opslaat”, zou het resultaat zijn: origineel bestand 1,41 GB + gecomprimeerde versie 0,75 GB, samen 2,16 GB schijfruimte – dat neemt juist meer ruimte in en zou een groot aantal xxx-min.jpg-bestanden opleveren die handmatig moeten worden opgeruimd en waarvoor de verwijzingen in de database of producttabel moeten worden bijgewerkt.
ImgZilla overschrijft op de oorspronkelijke locatie: het compressieresultaat wordt rechtstreeks teruggeschreven naar het oorspronkelijke pad. De 4624 bestandsnamen in de 78 mappen blijven volledig ongewijzigd – dit is vooral belangrijk voor websites die het afbeeldingspad al in een database, CDN of CMS-referenties hebben opgeslagen; er hoeven na compressie geen koppelingen te worden aangepast. De prijs is dat het originele bestand wordt gewijzigd. Daarom wordt het origineel standaard eerst naar de prullenbak van het systeem verplaatst voordat het compressieresultaat wordt weggeschreven. Wil je het ongedaan maken, dan kun je in de prullenbak met rechtsklik “Zet terug op oorspronkelijke locatie” kiezen.
6. Opbrengstanalyse: van praktijkscenario’s tot de maandelijkse factuur
Voor wie zijn deze gegevens relevant?
- Websites / ontwikkelaars met gebruikersuploads: opslag en CDN-verkeer worden meestal per GB gefactureerd; een halvering van het volume betekent een halvering van de factuur – en verkeerskosten zijn kosten die bij elke keer dat de afbeelding wordt opgevraagd ontstaan. Hoe meer bezoekers, hoe sterker het rente-op-rente-effect. Zelfs als er bij binnenkomst al een reguliere compressie is uitgevoerd, laat deze test zien dat “nog een compressieronde met fijn afgestelde parameters” aanzienlijke winst kan opleveren.
- Servers met weinig opslagruimte / gebruikers met kleine schijven: opschoonprogramma’s verwijderen meestal caches en dubbele bestanden, maar die stapelen zich na een paar maanden opnieuw op; de ruimte die compressie vrijmaakt, komt doordat de bestanden die in gebruik zijn zelf kleiner worden, en dat komt niet terug. Deze 78 mappen leverden na compressie direct 662 MB extra beschikbare ruimte op, en de vrijgave is permanent.
- Gebruikers die vaak gegevens verplaatsen: bij kopiëren, synchroniseren en back-uppen wordt het volume met 46,8% verminderd, waardoor de overdrachtstijd nagenoeg in dezelfde verhouding korter wordt. Eén keer comprimeren, en elke volgende overdracht bespaart tijd.
Vertaald naar de maandelijkse factuur: hoeveel is die 46,8% waard?
Een volumereductie is pas overtuigend als hij op de factuur zichtbaar wordt. Hieronder worden geen statistieken als “compressie verhoogt de conversie” aangehaald; we vermenigvuldigen alleen de 46,8% uit deze praktijktest met de openbare opslag- en verkeerstarieven van grote cloudproviders, voor een zuiver rekenkundige inschatting.
Besparing op opslagkosten = bespaard volume (GB) × eenheidsprijs (yuan of dollar / GB / maand)
Besparing op uitgaand verkeer = bespaard volume (GB) × aantal downloads/bezoeken die maand × eenheidsprijs (yuan of dollar / GB)
Volume halveren betekent dat beide facturen ongeveer ook worden gehalveerd – dat is wiskunde, geen gok.
Opslagkosten: hoe groter de beeldbibliotheek, hoe duidelijker de winst
Chinese aanbieders:
| Originele bibliotheekomvang | Bespaard volume | Alibaba Cloud OSS Standard Storage ¥0,09/GB/maand |
|---|---|---|
| 10 GB | 4,68 GB | ¥0,42/maand |
| 100 GB | 46,8 GB | ¥4,21/maand |
| 1 TB | 479 GB | ¥43,1/maand |
Buitenlandse aanbieders:
| Originele bibliotheekomvang | Bespaard volume | AWS S3 Standard $0,023/GB/maand |
Google Cloud Storage $0,020/GB/maand (VS Regional) |
Azure Blob Storage $0,018/GB/maand (Hot, LRS) |
Cloudflare R2 $0,015/GB/maand |
|---|---|---|---|---|---|
| 10 GB | 4,68 GB | $0,11/maand | $0,09/maand | $0,08/maand | $0,07/maand |
| 100 GB | 46,8 GB | $1,08/maand | $0,94/maand | $0,84/maand | $0,70/maand |
| 1 TB | 479 GB | $11,02/maand | $9,58/maand | $8,62/maand | $7,19/maand |
De opslagprijzen van de grote buitenlandse aanbieders liggen dicht bij elkaar (onderlinge verschillen binnen 30%). Het gaat er niet om wie het goedkoopst is, maar dat – ongeacht de keuze – als het volume halveert, deze kostenpost ook ongeveer halveert, en dat dit maandelijks terugkerend wordt gefactureerd. Eén compressie betekent dat elke volgende maand op basis van het nieuwe volume wordt gefactureerd: een eenmalige investering die langdurig blijft renderen.
Verkeerskosten: de echte kostenpost, die opschaalt met het aantal bezoeken
Verkeerskosten verdienen meer aandacht dan opslagkosten, omdat ze het product zijn van volume × aantal downloads – hoe vaker een afbeelding wordt opgevraagd, hoe groter de compressiewinst. Stel een beeldbibliotheek van 100 GB die in een maand 500 GB aan downloadverkeer via een CDN genereert (dat komt overeen met ongeveer 5 keer de volledige bibliotheek downloaden):
| CDN / uitgaand verkeer (eerste staffeltarief) | Maandelijkse verkeerskosten vóór compressie | Na compressie (volume -46,8%) | Besparing per maand | Besparing per jaar |
|---|---|---|---|---|
| Alibaba Cloud CDN binnen China (laag tarief ¥0,15/GB) | ¥75,0 | ¥39,9 | ¥35,1 | ¥421 |
| AWS CloudFront Azië-Pacific ($0,12/GB) | $60,0 | $31,9 | $28,1 | $337 |
| Google Cloud CDN Noord-Amerika/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 |
Hierboven is voor elke aanbieder het laagste staffeltarief genomen; de werkelijke staffelprijzen zijn vaak hoger (het hoogste staffeltarief voor Alibaba Cloud CDN-verkeer binnen China kan oplopen tot ¥1,31/GB). Hoe hoger de factuur, hoe groter de absolute besparing door compressie. Overigens is de Azure-tier hier momenteel Front Door Standard; naast het per GB gefactureerde uitgaande verkeer is er een basisservicevergoeding van ongeveer $35/maand – die kan door compressie niet worden verlaagd en is niet in de besparing in de tabel opgenomen.
Cloudflare R2 is een uitzondering: het uitgaande verkeer is daar $0 – als de bucket bij R2 staat, komt de compressiewinst vrijwel volledig ten goede aan de opslagkosten; voor het verkeer is er sowieso geen factuur. Dit is een andere kostenstructuur dan de dubbele facturering van “opslag + verkeer” (zoals Alibaba Cloud OSS+CDN, AWS S3+CloudFront) – voordat je een provider kiest, moet je je eigen facturatieposten duidelijk hebben.
Bovenstaande eenheidsprijzen zijn samengesteld uit openbare tarieven van de platforms in 2026; de werkelijke prijzen worden beïnvloed door regio, accountkortingen en staffelniveaus. Raadpleeg altijd de actuele prijzen op de officiële website. De aantallen downloads en bezoeken zijn voorbeeldhypotheses; vervang ze door de werkelijke gegevens uit je eigen factuur voor een schatting.
7. Besparing op overdrachts- en uploadtijd
Volume halveren betekent dat de overdrachtstijd vrijwel in dezelfde verhouding korter wordt – dit geldt onafhankelijk van cloudfacturen, zowel bij lokale kopieën en back-ups als bij het uploaden door gebruikers.
Lokale scenario’s: USB 3 en gigabitnetwerk
- USB 3 externe harde schijf (HDD): de continue lees-/schrijfsnelheid ligt doorgaans tussen 100–150 MB/s; we nemen de mediaan van 120 MB/s.
- USB 3 externe SSD: de doorvoer is aanzienlijk hoger, doorgaans 400–500 MB/s; we nemen 450 MB/s.
- Gigabit bekabeld netwerk (1000 Mbps): theoretische limiet 125 MB/s; na aftrek van protocoloverhead ligt de gemeten continue doorvoer ongeveer op 100–110 MB/s; we nemen 105 MB/s.
Bovenstaande waarden zijn schattingen op basis van gangbare gemeten bereiken; de werkelijke snelheid hangt af van het schijfmedium, de kwaliteit van de interface en de netwerkomgeving en is alleen bedoeld als indicatie voor een schatting.
| Scenario | Bespaard volume | USB 3 HDD @120 MB/s | USB 3 SSD @450 MB/s | Gigabitnetwerk @105 MB/s |
|---|---|---|---|---|
| Deze geteste batch | 662 MB | ≈5,5 sec | ≈1,5 sec | ≈6,3 sec |
| 10 GB bibliotheek | 4,68 GB | ≈40 sec | ≈10 sec | ≈45 sec |
| 100 GB bibliotheek | 46,8 GB | ≈6,5 min | ≈1,7 min | ≈7,4 min |
| 1 TB bibliotheek | 479 GB | ≈66 min | ≈18 min | ≈76 min |
De 662 MB uit deze test lijkt per keer misschien weinig, slechts enkele seconden. Maar net als bij opslagkosten geldt: dit is een eenmalige investering met blijvend rendement. Of je nu bestanden naar een externe schijf kopieert, een NAS synchroniseert, Time Machine draait, naar een nieuwe Mac migreert of bestanden aan een collega doorgeeft – zolang je deze gegevens verplaatst, bespaar je elke keer naar verhouding tijd. Eén keer comprimeren, en elke volgende overdracht bespaart tijd.
Als compressie vóór het uploaden door de gebruiker plaatsvindt: bespaarde wachttijd
Tot nu toe ging het om de voordelen “nadat de afbeeldingen zijn opgeslagen” – opslagkosten, CDN-verkeer, lokale overdracht. Er is echter nog een aspect dat de moeite waard is: de wachttijd tussen het indrukken van de uploadknop en het voltooien van de voortgangsbalk. Die gaat over de eigen uploadbandbreedte van de gebruiker, en upload is meestal de langzaamste bottleneck in de hele keten – bij de meeste consumentenbroadbands is de uploadsnelheid slechts een vijfde tot een tiende van de downloadsnelheid, en bij mobiele netwerken is dat nog sterker. Als de website of app afbeeldingen vóór het uploaden eerst met ImgZilla comprimeert, wordt het bespaarde volume direct omgezet in minder wachttijd voor de gebruiker.
Op basis van de gemiddelde bestandsgrootte in deze test: de door de website al gecomprimeerde originelen zijn gemiddeld 299 KB, na compressie met ImgZilla gemiddeld 159 KB, een besparing van gemiddeld 140 KB per afbeelding.
| Uploadbandbreedte (typische bereiken uit openbare speedtestgegevens, ter indicatie) | Eén afbeelding 299KB→159KB |
Upload 50 foto’s van een album ≈15,0MB→8,0MB |
Upload alle 4624 afbeeldingen uit deze test 1,41GB→0,75GB |
|---|---|---|---|
| Mobiel netwerk (4G/5G gecombineerd; mediaan uit openbare snelheidstests in China circa 10–50 Mbps; we nemen 30 Mbps) | circa 0,04 sec bespaard | circa 1,9 sec bespaard | circa 3 min bespaard |
| Gangbare thuisbreedband-uplink (pakketten met 100 Mb/1 Gb down; upload meestal beperkt tot circa 20–30 Mbps; we nemen 25 Mbps) | circa 0,04 sec bespaard | circa 2,2 sec bespaard | circa 3,5 min bespaard |
| Symmetrische gigabit-uplink (enkele providers/zakelijke lijnen, 1000 Mbps) | circa 0,001 sec bespaard | circa 0,06 sec bespaard | circa 5,3 sec bespaard |
| Buitenlandse referentie: gemiddelde upload van vast internet in de VS (Ookla-data, 2026) | circa 0,02 sec bespaard | circa 1 sec bespaard | circa 1,5 min bespaard |
Als je naar één enkele afbeelding kijkt, lijkt deze tabel misschien betekenisloos – 0,04 sec is vrijwel niet waarneembaar. Dat is een eerlijk resultaat: deze testset was zelf al niet groot (de afbeeldingen waren vóór opname in de bibliotheek al gecomprimeerd, gemiddeld slechts 299 KB per stuk). De scenario’s waarin dit echt waarde oplevert zijn er twee: een bulkactie waarbij een heel album of tientallen afbeeldingen tegelijk worden geüpload, en groter bronmateriaal (zoals JPEG’s rechtstreeks uit de camera of UGC die voor het eerst wordt geüpload zonder websitecompressie; zulke bestanden zijn meestal enkele MB’s in plaats van honderden KB’s) – bij dezelfde compressieverhouding wordt de absolute besparing in seconden evenredig groter. Voor mobiele gebruikers met een van nature langzamere uploadverbinding is de kortere wachttijd nog duidelijker merkbaar.
De bereiken voor mobiele netwerken en thuisbreedband zijn gebaseerd op openbare snelheidsstatistieken in China (4G/5G-mediaan en veelvoorkomende verhoudingen voor breedband-uplink). De werkelijke snelheid wordt sterk beïnvloed door provider, regio, apparaat en netwerkcongestie; de waarden zijn slechts een indicatie van de grootteorde. De uploaddata voor vast internet in de VS zijn afkomstig van berichtgeving over Ookla Speedtest.
Zelf verifiëren? Download ImgZilla rechtstreeks uit de Mac App Store en test het met een paar afbeeldingen die al door je eigen website zijn verwerkt. Beslis daarna pas of je de rest ook comprimeert.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Meer informatie: https://imagetool.app/ImgZilla