Den här artikeln citerar inga "branschsnittstal". De komprimerade data som nämns härifrån kommer från våra egna tester. Kostnadsberäkningen ges som formler, och genom att sätta in dina egna enhetspriser på fakturan får du resultatet.
Varje månad när man tittar på molnfakturan, ser de flesta bara totalen: lite mer än förra månaden, fortfarande inom budget, så går det över.
Men om man utvecklar fakturan och delar upp den efter produkt, kommer många webbplatser, små appar och innehållsplattformar att upptäcka att de två som ofta ligger högst upp är:
- Objektlagring: Lagringsavgift baserad på GB·månad
- CDN / Internettrafik: Avgift för nedströmsdata baserad på GB
Och av dessa två är det oftast bilder som tar upp mest plats.
Problemet är att en betydande del av byten i dessa bilder är helt onödiga för användarna, men du betalar för dem varje månad.
1. "Komprimerad vid uppladdning" betyder inte att det är tillräckligt
Många team säger: "Vi komprimerar vid uppladdning."
Vi har testat detta specifikt. Provet var en webbplats som tillåter användare att ladda upp bilder, där vi gjorde en vanlig komprimering vid införandet: 78 mappar, 4624 bilder, totalt 1,41 GB.
| Volym | Relativt original | |
|---|---|---|
| Originalet som redan komprimerats av webbplatsen | 1,41 GB | — |
| Paketerad som zip | 1,41 GB | -0,2% |
| Ytterligare komprimering med ImgZilla | 0,75 GB | -46,8% |
På "redan komprimerad"-basis sparade vi nästan hälften. Och av 4624 bilder kunde varje enskild bild komprimeras ytterligare, ingen bild var "redan tillbaka till botten och kunde hoppas över".
Orsaken är inte komplex: de flesta införandekompressioner är bara inställning av en kvalitetsparameter eller begränsning av storlek, vilket är en relativt konservativ engångshantering som inte heller använder kodningsutrymmet för varje format fullt ut.
Om din bildbibliotek består av kamerakvalitetsbilder, utdata från designfiler eller direkt uppladdade originalbilder är utrymmet ännu större. Vi testerade detta på 32 188 kamerakvalitets-JPEG och upptäckte att den totala volymen minskade med 76,8%.
2. Lagringsavgift är en addition, trafikavgift är en multiplikation
Detta är den punkt som oftast missas.
- Lagringsavgift: En bild lagras i bucketen, och du betalar månadsvis för dess volym.
- Trafikavgift: Varje gång en bild öppnas betalar du för dess volym igen.
Så om en banner på startsidan har 300 KB onödiga byter, är det nästan osynligt på lagringsfakturan, men om den öppnas 100 000 gånger om dagen blir det 29 GB extra trafik på trafikfakturan per dag.
Desto mer populär bilden är, desto mer onödigt betalt pengar läggs ner. Och de mest populära bilderna är just de som ligger på startsidan, produkthuvudbilder, artikelsammanfattningar – positioner som ofta är "lätt att ladda upp originalbilder".
3. Räkna ut din egen faktura
Lita inte på någon annans uppskattning, ta din faktura från förra månaden och sätt in de två formlerna nedan:
Månadvis sparad lagringskostnad ≈ Bildtotallagring (GB) × Kompressionsgrad × Lagringsenhet (¥/GB·månad)
Månadvis sparad trafikkostnad ≈ Bildmånadens nedströmsdata (GB) × Kompressionsgrad × Trafikenhet (¥/GB)
Du kan först använda en 40% för kompressionsgraden (vilket är något lägre än de 46,8% vi upptäckte i "redan komprimerad"-provet), och byt till faktiska siffror efter att ha kört igenom dina egna bilder.
Ett exempel för demonstration (enhetspriserna är fiktiva, byt ut mot dina egna siffror från fakturan):
| Projekt | Värde |
|---|---|
| Bildlagring | 500 GB |
| Bildmånadens nedströmsdata | 10 TB |
| Lagringsenhet (fiktiv) | 0,12 ¥/GB·månad |
| Trafikenhet (fiktiv) | 0,20 ¥/GB |
- Lagring: 500 × 40% × 0,12 ≈ 24 ¥/månad
- Trafik: 10240 × 40% × 0,20 ≈ 819 ¥/månad
Man kan se att den stora summan ligger på trafiken. Att spara på lagring är en marginal, att spara på trafik är det riktiga pengarna. Och dessa pengar betalas varje månad, så länge bilderna inte hanteras fortsätter du att betala.
Det finns även vissa fördelar som inte syns på fakturan: sidor laddas snabbare, användare på mobilen sparar mer datatrafik, LCP-indikatorer ser bättre ut, och små appar kan lättare få huvudpaketet under gränsvärdet.
4. Varför vet man att man borde komprimera, men ingen gör det?
Vi frågade många utvecklare och webbplatsägare, svaret består nästan alltid av tre saker:
1. Rädsla för att ändra sökvägar.
Traditionella onlinekomprimeringsverktyg kräver "uppladdning → nedladdning → byta namn → ersätta → ändra referens i koden", och för projekt med tusentals bilder vågar ingen röra dem.
2. Rädsla för att kvaliteten ska bli sämre.
När design, marknadsförare eller chefer säger "bilden är suddig" efter komprimering, vill ingen bära skulden.
3. För mycket krångel.
Mappar inuti mappar, hantera bild för bild är inte realistiskt, och skriva skript kräver att man justerar parametrar och hanterar olika format.
ImgZilla har skapats för att lösa dessa tre problem:
- Komprimera på plats: Efter komprimering ersätts den ursprungliga filen, filnamn och mappstruktur är helt oförändrade, ingen rad i koden behöver ändras.
- Visuell ingen förlust: PNG, SVG är riktigt förlustfria; JPEG, WebP, AVIF, HEIC justeras separat för varje format så att det är inom det område som är omöjligt att upptäcka med blotta ögat. Det finns en inbyggd jämförelse med delad skärm som kan zoomas in till faktiska pixlar för att kontrollera själv.
- Dra in en mapp: Rekursiv bearbetning av alla undermappar, ingen ansträngning att välja filer eller justera glidare.
- Helt lokal bearbetning: Interna resurser, opublicerade produktbilder behöver inte laddas upp till tredjepartsservrar.
5. Det faktiska processen för att "maga ner" ditt bucket
Om dina bilder redan ligger i objektlagringen ser processen ut ungefär så här:
- Synkronisera till lokal dator: Använd verktyg som
rclone,ossutil,coscmd,aws s3 syncför att hämta bildmappen till Mac. - Ta en säkerhetskopia först: Det är en god vana, inte för att verktyget är opålitligt.
- Dra in i ImgZilla: Dra hela mappen i, vänta tills den är klar.
- Synkronisera tillbaka till bucketen: Använd samma verktyg för att skriva över och ladda upp, sökvägen är densamma.
- Uppdatera CDN-cache: Gör en cache-uppdatering för bildmappen så att de randnoderna får de nya filerna.
Glöm inte steg 5. Uppdaterar du inte kommer CDN-noderna att fortsätta distribuera de gamla filerna, och trafikfakturan kommer inte att gå ner förrän cachen går ut.
6. Ärlig förklaring
- ImgZilla finns för närvarande bara som macOS-version (kräver macOS 12.3 eller högre), det finns ingen Windows-version.
- Förutom PNG och SVG är andra format visuellt förlustfria, inte pixel-förlustfria. Om din verksamhet kräver att pixlarna är helt oförändrade (t.ex. medicinsk bildanalys eller material som kräver pixelförhållanden), bör du inte göra omkodning på dessa filer.
- Kompressionsgraden varierar beroende på bild. Våra tester visade en enskild kompressionsgrad mellan 32% och 86%, så vi rekommenderar att du väljer en mapp att testa först och väljer faktiska siffror för att fatta beslut.
Slutligen
Molnleverantörer kommer inte att påminna dig om att bilder kan göras mindre, och det kommer inte att stå som en separat rad på din faktura: "Onödiga byter".
Men det finns där, beräknat i GB varje månad och debiteras igen varje gång det besöks.
Dra in din bildmapp i ImgZilla och kör igen. Jämför fakturan nästa månad.
👉 Ladda ner ImgZilla: https://imagetool.app/ImgZilla