This article does not cite any "industry average" figures. The compression data cited are from our own tests, and the cost calculations provided are formulas that you can apply to the unit prices on your own bill.
When looking at your cloud bill every month, most people just look at the total: it's a bit higher than last month, but still within the budget, and that's that.
But if you break down the bill by product, many websites, mini-programs, and content platforms will find that the items at the top are usually just two:
- Object Storage: Charged per GB·month for storage
- CDN / Public Network Traffic: Charged per GB for downstream traffic
And within these two, the items that usually take up the most space are typically images.
The problem is that a significant portion of the bytes in these images are invisible to users, yet you are paying for them every month.
I. "Compressed at Upload" Doesn't Mean "Compressed Enough"
Many teams will say: "We compress at upload."
We specifically tested this scenario. The sample was a website that allows users to upload images, which had already undergone a round of conventional compression before being stored: 78 folders, 4624 images, totaling 1.41 GB.
| Size | Relative to Original | |
|---|---|---|
| Website's pre-compressed original file | 1.41 GB | — |
| Packaged into zip | 1.41 GB | -0.2% |
| ImgZilla re-compression | 0.75 GB | -46.8% |
On top of "already compressed", we saved nearly half. Moreover, every single one of the 4624 images could be compressed further; none of them were "compressed to the limit and skipped directly".
The reason isn't complicated: most storage compression simply sets a uniform quality parameter or limits the size, which is a conservative one-time treatment that far from exhausts the encoding space of each format.
If your image library consists of camera-raw shots, exported design drafts, or images uploaded directly by operations without processing, the space is even larger. We tested this on 32,188 camera-raw JPEGs and found the total size reduced by 76.8%.
II. Storage Fees are Addition, Traffic Fees are Multiplication
This is the point most easily overlooked.
- Storage Fees: A single image stored in a bucket is charged once per month based on its size
- Traffic Fees: A single image is charged again per month every time it is accessed, based on its size
So if a homepage banner has 300 KB of invalid bytes extra, it's barely noticeable on the storage bill, but if it is opened 100,000 times a day, that's about 29 GB extra on the traffic bill every day.
The more popular an image is, the more money you pay for nothing. And the most popular images are precisely those in positions most likely to be "uploaded in original format casually" – such as homepage banners, main product images, and article headers.
III. Do the Math for Your Own Bill
Don't trust anyone's estimates. Take out last month's bill and plug it into the following two formulas:
Monthly Storage Savings ≈ Total Image Storage (GB) × Compression Rate × Storage Unit Price (CNY/GB·month)
Monthly Traffic Savings ≈ Image Monthly Downstream Traffic (GB) × Compression Rate × Traffic Unit Price (CNY/GB)
You can estimate the compression rate conservatively at 40% first (lower than the 46.8% we measured on the "already compressed" sample), and switch to the actual numbers once you've run your own images.
Here is a demonstration example (the unit prices are hypothetical, please replace them with the numbers from your bill):
| Item | Value |
|---|---|
| Image Storage | 500 GB |
| Image Monthly Downstream Traffic | 10 TB |
| Storage Unit Price (Hypothetical) | 0.12 CNY/GB·month |
| Traffic Unit Price (Hypothetical) | 0.20 CNY/GB |
- Storage: 500 × 40% × 0.12 ≈ 24 CNY/month
- Traffic: 10240 × 40% × 0.20 ≈ 819 CNY/month
You can see that the real big chunk is traffic. Savings on storage are just a rounding error; the savings from traffic are the real money. Moreover, this money is paid every month; if the images aren't processed, it continues indefinitely.
There are also benefits not visible on the bill: faster page loading, less data usage for mobile users, better LCP metrics, and mini-program main packages being easier to squeeze under the limit.
IV. Why Do We Know We Should Compress, Yet No One Does It?
We asked quite a few developers and site owners, and the answers basically fall into three categories:
1. Fear of changing paths.
Traditional online compression tools require "upload → download → rename → replace → update references in code". For projects with thousands of images, no one dares to touch them.
2. Fear of quality issues.
If the image looks blurry after compression and is criticized by designers, operations, or management, no one wants to take the blame.
3. It's too troublesome.
Directories are nested layer upon layer; processing images one by one is unrealistic, and writing scripts requires tuning parameters and handling various formats.
ImgZilla was created to solve these three issues:
- In-place Compression: Compressed files directly replace the originals. File names and directory structure remain completely unchanged, so no lines of code need to be updated.
- Visually Lossless: PNG and SVG are truly lossless. For JPEG, WebP, AVIF, and HEIC, parameters are tuned individually per format to be within the range undetectable to the naked eye. It includes a built-in side-by-side comparison that allows you to zoom in to actual pixels for inspection.
- Just Drag a Folder: Recursively processes all subdirectories; no need to select files or adjust sliders.
- All Processing is Local: Internal assets and unpublished product images don't need to be uploaded to third-party servers.
V. Practical Workflow to "Slim Down" Your Bucket
If your images are already stored in object storage, the process is roughly as follows:
- Sync to Local: Use tools like
rclone,ossutil,coscmd, oraws s3 syncto pull the image directory to your Mac. - Backup First: It's a good habit; don't worry, it's not because the tool is unreliable.
- Drag into ImgZilla: Drag the entire directory in and wait for it to finish.
- Sync Back to Bucket: Use the same tool to overwrite and upload, keeping paths unchanged.
- Refresh CDN Cache: Perform a directory refresh on the image directory so edge nodes get the new files.
Don't miss step 5. If you don't refresh, CDN nodes will continue to distribute the old files, and the traffic bill won't drop until the cache expires.
VI. Honest Disclaimer
- ImgZilla currently only has a macOS version (requires macOS 12.3 or later); there is no Windows version.
- Except for PNG and SVG, other formats are visually lossless, not pixel-perfect lossless. If your business requires pixel-perfect integrity (e.g., medical imaging or assets that require pixel ratio comparison), please do not re-encode these file types.
- Compression rates vary by image. Our measured single-image compression ratios ranged from 32% to 86%. It is recommended to select a directory to test first, check the actual numbers, and then decide.
Conclusion
Cloud providers won't remind you that images can be made smaller, and they won't list a separate line item for "invalid bytes" on your bill.
But it's there, charging you per GB every month, and charging you again every time it's accessed.
Drag your image directory into ImgZilla and run it. Compare your bill next month.
👉 Download ImgZilla: https://imagetool.app/ImgZilla