In dit artikel worden geen "industriële gemiddelden" aangehaald. De gedecomprimeerde gegevens zijn afkomstig van onze eigen tests; bij de kostenberekeningen geven we formules op die je met je eigen factuurprijzen kunt invullen.
Elke maand de cloudfactuur bekijken, kijken de meeste mensen alleen naar het totaal: een beetje hoger dan vorige maand, binnen het budget, en dan gaat het voorbij.
Maar als je de factuur uitklapt en per product bekijkt, ontdekken veel websites, mini-apps en contentplatforms dat de eerste twee posten meestal zijn:
- Objectopslag: opslagkosten per GB·maand
- CDN / openbare netwerkverkeer: kosten voor downloadverkeer per GB
En in beide categorieën zijn het meestal de afbeeldingen die het grootste deel innemen.
Het probleem is dat een groot deel van de bytes in deze afbeeldingen door gebruikers nauwelijks te zien is, terwijl je ze elke maand toch betaalt.
1. "Gecomprimeerd tijdens het uploaden" betekent nog niet genoeg gecomprimeerd
Veel teams zeggen: "Wij comprimeren al tijdens het uploaden."
We hebben deze situatie specifiek getest. Het monster was een website waarbij gebruikers afbeeldingen kunnen uploaden, die al een standaard compressierunde hadden ondergaan bij het inladen: 78 mappen, 4624 afbeeldingen, totaal 1,41 GB.
| Volume | Ten opzichte van origineel | |
|---|---|---|
| Oorspronkelijke bestanden (al gecomprimeerd door de website) | 1,41 GB | — |
| Gepakt in zip | 1,41 GB | -0,2% |
| ImgZilla opnieuw comprimeren | 0,75 GB | -46,8% |
Op basis van "al gecomprimeerd" hebben we nog eens bijna de helft bespaard. En bij alle 4624 afbeeldingen kon er nog verder worden gecomprimeerd; geen enkele was "volledig uitgeput" en kon worden overgeslagen.
De reden is niet ingewikkeld: de meeste inlaadcompressies stellen gewoon een kwaliteitparameter, of beperken de afmetingen; dit is een relatief conservatieve eenmalige verwerking die de codec-ruimte voor elke formaatstijl nog lang niet volledig uitput.
Als je beeldbibliotheek bestaat uit directe camera-uitvoer, ontwerpteksten of door operationeel personeel geüploade originele bestanden, is de ruimte nog groter. We hebben dit getest bij 32.188 directe camera-uitvoer JPEG's en de totale grootte is met 76,8% verminderd.
2. Opslagkosten zijn optellen, verkeerskosten zijn vermenigvuldigen
Dit is het punt dat het vaakst wordt vergeten.
- Opslagkosten: een afbeelding opslaan in de bucket kost elke maand eenmalig per zijn volume
- Verkeerskosten: elke keer dat een afbeelding wordt geopend, wordt er opnieuw per volume een vergoeding berekend
Dus als een banner op de homepage 300 KB onnodige bytes extra bevat, is dit bijna onzichtbaar op de opslagfactuur, maar wordt er elke dag 100.000 keer geopend, wat op de verkeersfactuur ongeveer 29 GB extra per dag is.
Hoe populairder een afbeelding, hoe meer onnodig betaald wordt. En de populairste afbeeldingen zijn juist die op de homepage, de hoofdafbeeldingen van producten en de kopafbeeldingen van artikelen – plekken waar vaak "zomaar de origineel geüpload wordt".
3. Reken uw eigen rekening uit
Geloof geen enkele schatting; pak je factuur van afgelopen maand en voer de volgende twee formules in:
Maandelijkse opslagbesparing ≈ Totaal opslagvolume afbeeldingen (GB) × Compressieverhouding × Opslagprijs (€/GB·maand)
Maandelijkse verkeersbesparing ≈ Maandelijks downloadverkeer afbeeldingen (GB) × Compressieverhouding × Verkeersprijs (€/GB)
De compressieverhouding kun je eerst conservatief inschatten op 40% (lager dan de 46,8% die we bij het monster "al gecomprimeerd" hebben gemeten), en vervolgens vervangen door de werkelijke cijfers nadat je eigen afbeeldingen zijn verwerkt.
Een voorbeeld voor demonstratie (de prijzen zijn hypothetisch, vervang deze door de getallen uit je factuur):
| Project | Waarde |
|---|---|
| Opslagvolume afbeeldingen | 500 GB |
| Maandelijks downloadverkeer afbeeldingen | 10 TB |
| Opslagprijs (hypothetisch) | 0,12 €/GB·maand |
| Verkeersprijs (hypothetisch) | 0,20 €/GB |
- Opslag: 500 × 40% × 0,12 ≈ 24 €/maand
- Verkeer: 10.240 × 40% × 0,20 ≈ 819 €/maand
Het is duidelijk dat het grootste deel in het verkeer zit. De opslagbesparing is een nuk, de verkeersbesparing is het serieuze geld. En dit bedrag wordt elke maand betaald; zolang de afbeeldingen niet worden verwerkt, blijft het elke maand doorgaan.
Er zijn ook baten die niet direct op de factuur verschijnen: snellere paginalaadtijden, minder mobielverkeer voor gebruikers, betere LCP-waarden en het is makkelijker om de hoofdmodule van een mini-app binnen de limieten te houden.
4. Waarom weten we dat het gecomprimeerd moet worden, maar doen we het toch nooit?
We hebben veel ontwikkelaars en site-eigenaren gevraagd, en het antwoord is bijna altijd drie dingen:
1. Angst voor het aanpassen van paden.
Traditionele online compressietools vereisen "uploaden → downloaden → hernoemen → vervangen → verwijzingen in code aanpassen". Voor projecten met duizenden afbeeldingen durven niemand dit aan te raken.
2. Angst voor beeldkwaliteit.
Als na het comprimeren wordt gezegd dat het beeld onscherp is door een designer, operationeel persoon of baas, wil niemand de verantwoordelijkheid dragen.
3. Te veel gedoe.
Mappen in mappen, afbeelding voor afbeelding verwerken is niet realistisch, en scripts schrijven vereist het afstellen van parameters en het afhandelen van verschillende formaten.
ImgZilla is gemaakt om deze drie problemen op te lossen:
- Direct comprimeren: na het comprimeren worden de originele bestanden direct vervangen; bestandsnamen en mappenstructuur veranderen niet, en er hoeft geen enkele verwijzing in de code aangepast te worden
- Visueel zonder verlies: PNG en SVG zijn echt zonder verlies; JPEG, WebP, AVIF en HEIC worden per formaat afzonderlijk afgesteld om binnen het bereik te blijven dat voor het menselijk oog onderscheidbaar is. Er is een ingebouwde vergelijking met twee zijden, zodat je kunt zoomen naar pixelniveau om het zelf te controleren
- Sleep een map erin: recursieve verwerking van alle submappen, zonder dat je bestanden hoeft te selecteren of schuifregelaars hoeft te draaien
- Volledig lokaal verwerken: interne bronnen en ongepubliceerde productafbeeldingen hoeven niet geüpload te worden naar externe servers
5. Praktische stappen om uw bucket "in slim formaat te brengen"
Als uw afbeeldingen al op objectopslag staan, ziet het proces er ongeveer als volgt uit:
- Synchroniseer naar lokaal: gebruik tools zoals
rclone,ossutil,coscmd,aws s3 syncom de afbeeldingenmap naar uw Mac te halen - Maak eerst een back-up: dit is een goede gewoonte, niet omdat de tools onbetrouwbaar zijn
- Sleep in ImgZilla: sleep de hele map erin en wacht tot het klaar is
- Synchroniseer terug naar de bucket: gebruik dezelfde tool om te overschrijven en te uploaden; de paden blijven hetzelfde
- Ververs CDN-cache: doe een mapverversing voor de afbeeldingenmap zodat de edge-nodes de nieuwe bestanden krijgen
Negeer stap 5 niet. Als je dit overslaat, blijven de CDN-nodes oude bestanden verdelen, en de verkeersfactuur daalt pas nadat de cache is verlopen.
6. Eerlijke vermelding
- ImgZilla is momenteel alleen beschikbaar voor macOS (macOS 12.3 of hoger nodig), er is nog geen Windows-versie
- Behalve PNG en SVG zijn andere formaten visueel zonder verlies, niet pixel-perfect zonder verlies. Als uw zakelijke vereisten zijn dat pixels exact hetzelfde moeten blijven (bijvoorbeeld medische beelden of bronnen waarvoor pixelvergelijking nodig is), doe dit alstublieft niet voor deze bestanden
- De compressieverhouding varieert per afbeelding. Onze gemeten individuele compressieverhoudingen liggen tussen de 32% en 86%; we adviseren om eerst een map te kiezen en te testen om te zien wat de werkelijke cijfers zijn voordat u besluit
Conclusie
Cloudproviders zullen u niet vertellen dat uw afbeeldingen kleiner kunnen zijn, en op de factuur staat er ook geen aparte regel "onnodige bytes".
Maar het zit er wel, elke maand berekend per GB, elke keer dat het wordt bezocht.
Sleep uw afbeeldingenmap in ImgZilla en draai het een keer door; vergelijk de factuur van de volgende maand.
👉 Download ImgZilla: https://imagetool.app/ImgZilla