Denne artikel citerer ikke nogen "gennemsnitstal" i branchen. De komprimerede data, der nævnes, er fra egne tester. Prisberegningen viser formler, som du blot skal indsætte dine egne enhedspriser i for at få resultatet.
Når man ser sin cloud-regning månedligt, ser de fleste kun totalen: lidt mere end for måned siden, men stadig inden budgettet, og så går det videre.
Men hvis man uddyber regningen og ser på produkterne, vil mange websites, miniprogrammer og indholdsplatforme opdage, at de to ting, der oftest dominerer, er:
- Objektlagring: Lageromkostninger pr. GB·måned
- CDN / Offentlig netværkstrafik: Faldende trafikomkostninger pr. GB
Og i disse to er det typisk billeder, der fylder mest.
Problemet er, at en betydelig del af disse bytes egentlig ikke er synlige for brugeren, men du betaler for dem hver måned.
1. "Komprimeret ved upload" betyder ikke, at det er nok
Mange teams siger: "Vi komprimerer ved upload."
Vi har specialiseret os i at teste dette. Prøvepopulationen var et website, der tillader brugere at uploade billeder. Da de blev indsat, var der allerede foretaget en række almindelige komprimeringer: 78 mapper, 4624 billeder, i alt 1,41 GB.
| Størrelse | Forhold til original | |
|---|---|---|
| Originalet, allerede komprimeret af website | 1,41 GB | — |
| Pakket ind i zip | 1,41 GB | -0,2% |
| Yderligere komprimeret med ImgZilla | 0,75 GB | -46,8% |
På et "allerede komprimeret" fundament sparer man næsten halvdelen. Og af de 4624 billeder kan hver enkelt fortsætte med at komprimeres; intet af dem er "komprimeret til bunden og direkte sprunget over".
Årsagen er ikke kompleks: de fleste indlæsningskompressioner sætter blot en ensartet kvalitetsparameter eller begrænser størrelsen, hvilket er en relativt konservativ engangshåndtering, langt fra at udnytte kodingsrummet for hver type format fuldt ud.
Hvis billedbiblioteket består af direkte kamerabilleder, designudgivelser eller billeder uploadet direkte af operationer, er pladsen endnu større. Vi testede på 32.188 direkte kamerabilleder i JPEG og reducerede den samlede størrelse med 76,8 %.
2. Lageromkostninger er addition, trafikomkostninger er multiplikation
Dette er det punkt, der oftest overses.
- Lageromkostninger: Et billede lagres i bøtten, og man tager betaling for dets størrelse én gang om måneden
- Trafikomkostninger: Et billede betales for hver gang det åbnes, og man tager betaling for dets størrelse igen
Så hvis et banner på forsiden har 300 KB ubrugelige bytes ekstra, bliver det næsten ikke set i lageregningen, men hvis det åbnes 100.000 gange om dagen, bliver det omkring 29 GB ekstra i trafikregningen om dagen.
Jo mere populært et billede er, jo mere penge betaler man for ingenting. Og de mest populære billeder er netop de, der placeres på forsiden, som hovedbilleder til varer og overskrifter til artikler – steder hvor det ofte sker, at "tilfældigt" uploades råfiler.
3. Beregn din egen regning
Tro ikke på nogen estimering, tag din forrige måneds faktura og indsæt den i følgende to formler:
Månedligt sparedt lagerområde (GB) ≈ Samlet billedlager (GB) × Komprimeringsgrad × Lagerenhedspris (yuan/GB·måned)
Månedligt sparedt trafikområde (GB) ≈ Månedlig nedstrømsbilledtrafik (GB) × Komprimeringsgrad × Trafikenhedspris (yuan/GB)
Komprimeringsgraden kan først estimeres konservativt med 40 % (lavere end de 46,8 %, vi målte på prøvesættet "allerede komprimeret"), indtil du har kørt dit eget billedbibliotek igennem og kan bruge de faktiske tal.
Et eksempel til illustration (priserne er hypotetiske, brug dine egne tal fra fakturaen):
| Projekt | Værdi |
|---|---|
| Billedlager | 500 GB |
| Månedlig nedstrømsbilledtrafik | 10 TB |
| Lagerenhedspris (hypotetisk) | 0,12 yuan/GB·måned |
| Trafikenhedspris (hypotetisk) | 0,20 yuan/GB |
- Lager: 500 × 40 % × 0,12 ≈ 24 yuan/måned
- Trafik: 10240 × 40 % × 0,20 ≈ 819 yuan/måned
Det kan ses, at den egentlige store del ligger i trafikken. Det sparede lager er en lille del, det er den virkelige penge, man sparer i trafik. Og denne penge betales hver måned; indtil billederne behandles, fortsætter betalingen.
Der er også nogle gevinster, man ikke kan se på regningen: hurtigere indlæsning af sider, mindre datamængde for brugere på mobil, bedre LCP-måling og det er lettere at presse hovedpakken til et miniprogram ind under grænsen.
4. Hvorfor ved man godt, at det skal komprimeres, men det bliver aldrig gjort?
Vi har spurgt mange udviklere og webmastere, og svarene er stort set tre:
1. Frygt for at ændre stier.
Traditionelle værktøjer til online-komprimering kræver "upload → download → omdøb → erstat → ret referencer i koden", og i projekter med tusindvis af billeder er ingen klar til at røre ved det.
2. Frygt for kvalitet.
Hvis det komprimerede billede bliver kaldt "sløret" af designere, operatører eller chefen, vil ingen gerne bære ansvaret.
3. Det er for besværligt.
Mapper, der ligger et lag over det andet, og at behandle billede for billede er ikke realistisk, og at skrive scripts kræver parametertilpasning og håndtering af forskellige formater.
ImgZilla er lavet til at løse disse tre problemer:
- Komprimering på stedet: Efter komprimeringen erstattes filen direkte, filnavnet og mappestrukturen forbliver intakte, og man behøver ikke at rette en eneste reference i koden
- Visuel uden tab: PNG og SVG er ægte uden tab; JPEG, WebP, AVIF og HEIC justeres individuelt for hver type format for at holde det inden for det område, som det menneskelige øje ikke kan skelne. Der er en indbygget side-til-side-kontrol, hvor man kan zoome ind til de faktiske pixels for at tjekke selv
- Træk blot en mappe ind: Håndterer alle undermapper rekursivt, behøver ikke at udvælge filer eller justere glidere
- Helt lokal behandling: Intern materiale, ikke udgivne produktbilleder behøver ikke uploades til tredjepartsservere
5. Den faktiske proces til at "gøre slankere" på bøtten
Hvis dine billeder allerede ligger i objektlagringen, er processen sandsynligvis denne:
- Synkroniser til lokalt: Brug værktøjer som
rclone,ossutil,coscmd,aws s3 synctil at trække billedmappen ned til Mac - Sikkerhedskopier en kopi: Det er en god vane; gør det, fordi værktøjerne er pålidelige
- Træk ind i ImgZilla: Træk hele mappen ind, vent på, at den er færdig
- Synkroniser tilbage til bøtten: Brug det samme værktøj til at overskrive og uploade, stien forbliver den samme
- Tøm CDN-cache: Gør en mappe-genopfriskning for billedmappen, så de kantnoder kan få de nye filer
Pas på at springe trin 5 over. Uden at tømme cachen vil CDN-kantnoderne fortsætte med at sprede de gamle filer, og det tager tid før trafikomkostningerne falder igen.
6. Ærlig forklaring
- ImgZilla er i øjeblikket kun til macOS (kræver macOS 12.3 eller nyere), der er ikke en Windows-version
- Udover PNG og SVG er andre formater visuel uden tab, ikke pixel-præcis uden tab. Hvis din forretning kræver, at pixels er helt uforandrede (f.eks. medicinske billeder eller materiale, der kræver pixelsammenligning), bør du ikke genkode disse filer
- Komprimeringsgraden varierer fra billede til billede. Vores målte komprimeringsforhold pr. billede ligger mellem 32 % og 86 %. Anbefalet fremgangsmåde er at vælge en mappe og køre et test først for at se de faktiske tal, før du beslutter dig
Afslutning
Cloud-leverandører vil ikke minde dig om, at billeder kan gøres endnu mindre, og det bliver ikke listet som en separat linje på regningen "ubrugelige bytes".
Men det er der, og det faktureres månedligt pr. GB, og hver gang det besøges, tages der igen betaling for det.
Træk din billedmappe ind i ImgZilla og kør den igennem. Sammenlign regningen næste måned.
👉 Download ImgZilla: https://imagetool.app/ImgZilla