2026-10-05
Image compression and mobile data are tied together more closely than most people assume. On a typical news or shopping session, images carry the largest share of transferred bytes, usually somewhere between half and three quarters of the page total. Compressing them is the one change that moves a data bill without touching layout, copy, or function.
The number everyone wants, how much will I save, has no universal answer. It depends on what your images are, how they were produced, and what the page already does. This gives you the measurement method and the ranges seen in practice, so you can produce your own figure rather than borrowing someone else’s.
Before compressing anything, find out what is using the bytes. Guessing here tends to send people after the wrong asset.
These are rough ranges measured on real photographic content at sensible dimensions. Use them for a sense of scale, not as your result.
Three variables explain most of the gap between published figures and your own result.
The arithmetic is simple: monthly sessions, multiplied by average image bytes per session, multiplied by your compression ratio. A site with 20,000 mobile sessions a month and 1.4MB of images per session sits at 28GB. A fifty percent reduction saves 14GB monthly.
Whether that matters depends on the reader’s plan. On a metered 5GB allowance, 14GB across a base of users is a real constraint removed. On unlimited home broadband it is invisible, and the honest argument there is speed rather than cost. Weak-network speed is where compression pays off regardless of the plan.
Reader side, the options are limited but real: turn on data saver mode in the browser, lower the image quality setting in chat apps, and download large galleries over Wi-Fi. Most chat apps default to a quality far above what a phone screen needs.
Site owner side, the leverage is much larger.
Getting the order wrong wastes the effort. Resize before compressing, read the transferred column before deciding whether compression is worth it, and confirm images really are the largest share before spending time on them. After that, write the conclusion from your own measurement. More reads: /blog/compress-jpg-under-100kb covers setting a target size, /blog/image-compression-affects-page-speed covers how bytes relate to load speed.
For photographic content that has not been compressed before, forty to sixty percent of image bytes is the usual range. If the JPEG already went through one compression pass, expect much less, sometimes under ten percent.
Yes, but the benefit shifts from cost to speed. Smaller images finish sooner on weak connections, and that shows up in load time and bounce rate rather than in a data bill.
Resizing. Cutting linear dimensions in half removes about three quarters of the bytes before any quality setting is applied. Compress after resizing, not instead of it.
Only when it is done badly. Serving several format variants without proper negotiation, or preloading images that are never displayed, can add bytes. Generate the variants a browser actually needs and check the transferred column afterwards.