В предыдущей статье мы тестировали готовые изображения, которые уже один раз сжал сайт, и ImgZilla сэкономила ещё 46,8%. В этой статье переходим к другой крайности: оригиналы, снятые камерой или телефоном и никогда не обработанные никаким инструментом. Как и прежде, будем опираться не на отраслевую статистику, а только на результаты одного реального прогона и описание методики сравнения.
1. Объект этого теста: настоящие «оригиналы»
В предыдущей выборке была оговорка: изображения при загрузке на сайт уже проходили один цикл сжатия, так что их нельзя было считать исходными. В этот раз убираем эту оговорку и берём JPEG, которые камера или телефон сохранили напрямую после съёмки — без каких-либо инструментов сжатия, без пересохранения и без повторного кодирования.
Объём выборки: 32 188 JPEG-файлов, распределённых по 16 вложенным подкаталогам bucket. Для теста не проводилось никакого отбора или очистки.
Общий объём файлов: 99,9 ГБ (примерно 93 ГиБ).
Характеристики изображений вполне типичны — все это стандартное разрешение на выходе камер или телефонов:
| Разрешение | Количество | Процент |
|---|---|---|
| 4000×3000 (12 Мп) | 19 867 | 61,7% |
| 4032×3024 (12 Мп, iPhone) | 3 529 | 11,0% |
| 3456×4608 (16 Мп, вертикальные) | 2 631 | 8,2% |
| Прочие (3120×4208, 4608×3456, 2448×3264…) | 6 161 | 19,1% |
В среднем: 11,5 мегапикселя и 2,96 МБ на изображение. Самый крупный файл — 18,3 МБ при 30 мегапикселях. Это типичные фотографии, снятые на телефон или камеру и оставленные без вашего вмешательства.
Вопрос: сколько из таких «нетронутых» оригиналов может выжать специализированный инструмент сжатия?
2. Результат: экономия 76,8% — 99,9 ГБ превратились в 23,1 ГБ
Все 32 188 изображений сжаты по одному на месте: имена файлов, структура каталогов и разрешения остались нетронутыми.
| Объём | Относительно оригинала | |
|---|---|---|
| Оригиналы прямо с камеры | 99,9 ГБ | — |
| После сжатия ImgZilla | 23,1 ГБ | -76,8% |
Однократное сжатие экономит около 76,7 ГБ; после сжатия остаётся меньше четверти исходного объёма. Относительные пути, имена файлов и иерархия папок для всех 32 188 файлов полностью совпадают до и после — это можно напрямую подтвердить сравнением реальных данных.
Сравнение с предыдущей статьёй:
| Партия теста | Источник изображений | Сжатие ImgZilla |
|---|---|---|
| Предыдущая статья (4624 изображения) | Готовые изображения, уже один раз сжатые сайтом | −46,8% |
| Эта статья (32 188 изображений) | Оригиналы с камеры или телефона | −76,8% |
Вывод прямой: чем менее обработки прошёл оригинал, тем больше из него можно выжать. Сжатие при загрузке на сайт уже съело часть избыточности, и ImgZilla досталось 46,8%. А в изображениях прямо с камеры эта избыточность не тронута, поэтому ImgZilla одним проходом забирает 76,8%.
3. Почему оригинальные снимки с камеры дают такую экономию
При экспорте JPEG камера и телефон прежде всего стараются «ничего не потерять», а не «ужать файл как можно сильнее». Поэтому в прямых JPEG много объёма, который никак не влияет на качество:
- Консервативные параметры качества: в JPEG с камеры часто используются таблицы квантования уровня качества 90–98. Глаз уже не различает разницу от более высокого качества, а вот количество байтов отличается сильно.
- Универсальное, неоптимальное энтропийное кодирование: прямое кодирование использует фиксированные стандартные таблицы Хаффмана, не подбирает оптимальное кодирование для каждого изображения, не применяет треллис-квантование и не оптимизирует прогрессивное сканирование.
- Множество сопутствующих данных: EXIF, GPS, закрытые поля производителя, встроенная полная превью-копия, цветовые профили — всё вместе это часто занимает десятки и сотни килобайт.
ImgZilla выполняет для JPEG визуально без потерь перекодирование: использует более оптимальную стратегию кодирования, перестраивает энтропийное кодирование, подбирает параметры квантования в неразличимый для глаза диапазон и убирает избыточные сопутствующие данные. На уровне пикселей изменения есть, но параметры выбраны на границе видимого различия. Поэтому на таких «оригиналах» с большим запасом избыточности одним проходом можно убрать три четверти объёма.
Важно пояснить термин, который часто путают: «визуально без потерь» ≠ «без потерь». Без потерь (пиксели полностью не меняются) сжимаются только PNG (oxipng) и SVG; JPEG, WebP, AVIF, HEIC и GIF по своей природе — это перекодирование с потерями, просто параметры выбраны в зоне визуального отсутствия потерь. Не хотите верить на слово? В ImgZilla есть встроенное окно сравнения: до и после можно смотреть бок о бок, масштабировать до реального размера и сравнивать попиксельно — посмотрите сами.
4. Детальный разбор: коэффициенты сжатия по файлам, размер в пикселях, крайние случаи
Приведённые выше 76,8% получены сравнением суммарных объёмов всей партии из 32 188 файлов. Разбивка до уровня отдельных файлов показывает ещё несколько конкретных деталей.
У большинства изображений экономия составляет 70–90%
Сопоставим все 32 188 файлов попарно «байты до сжатия → байты после сжатия» и сгруппируем по доле экономии:
| Доля экономии | Количество файлов | Процент |
|---|---|---|
| 90–100% | 866 | 2,7% |
| 80–90% | 11 375 | 35,3% |
| 70–80% | 15 244 | 47,4% |
| 60–70% | 3 349 | 10,4% |
| 50–60% | 398 | 1,2% |
| Менее 50% | 956 | 3,0% |
82,7% фотографий сэкономили 70–90% объёма. Среднее арифметическое коэффициента сжатия по отдельным файлам — 76,6%, что почти совпадает с 76,8%, полученными по сумме байтов. Это говорит о том, что в партии сильно и слабо сжимаемые файлы распределены равномерно по весу и среднюю не перекашивают отдельные сверхбольшие файлы.
По квантилям: у более чем половины фото экономия превышает 77%; даже у худших 10% по отдаче от сжатия экономия составляет около 68%; лишь примерно у 1% фото (p99) доля экономии ниже 40%.
Размер в пикселях: ни один пиксель не изменился
Статистика по изменению разрешения всех 32 188 изображений: dimensions_changed имеет значение false у всех — 100% разрешений сохранены. ImgZilla не масштабирует и не кадрирует; сэкономленные 76,7 ГБ целиком получены за счёт перекодирования, а не за счёт выкидывания пикселей. Это вторая, часто упускаемая из виду половина определения «сжатия на месте»: не только имена файлов и пути не меняются, но и разрешение остаётся полностью прежним.
Несколько крайних случаев
| Тип | Оригинал | После сжатия | Экономия |
|---|---|---|---|
| Наивысшая степень сжатия | 3,55 МБ (4000×3000) | 100 КБ | 97,2% |
| Максимальная экономия на одном файле | 17,90 МБ (4000×3000) | 1,13 МБ | 16,8 МБ |
| Худшая отдача | 70 КБ (1242×1242) | 68,8 КБ | 2,1% |
Файлы с максимальным сжатием (свыше 95%) — обычно кадры, снятые камерой на максимальных настройках качества и нагруженные метаданными; хуже всего сжимаются давно обработанные и небольшие изображения. В среднем одно изображение экономит 2,38 МБ.
5. Пересчёт в ежемесячный счёт: сколько стоят эти 76,8%
Экономия объёма по-настоящему ощущается в счетах. Здесь не будет статистики вроде «сжатие повышает конверсию», только один арифметический шаг: берём измеренные 76,8% и умножаем их на текущие публичные тарифы нескольких облачных провайдеров.
Экономия на хранении = сэкономленный объём (ГБ) × цена за ГБ в месяц (юань или доллар)
Экономия на исходящем трафике = сэкономленный объём (ГБ) × количество скачиваний за месяц × цена за ГБ (юань или доллар)
Плата за хранение
| Исходный размер библиотеки | Сэкономленный объём | Alibaba Cloud OSS Standard ¥0,09/ГБ/мес |
AWS S3 Standard $0,023/ГБ/мес |
Google Cloud Storage $0,020/ГБ/мес |
Cloudflare R2 $0,015/ГБ/мес |
|---|---|---|---|---|---|
| 10 ГБ | 7,68 ГБ | ¥0,69/мес | $0,18/мес | $0,15/мес | $0,12/мес |
| 100 ГБ | 76,8 ГБ | ¥6,91/мес | $1,77/мес | $1,54/мес | $1,15/мес |
| 1 ТБ | 786 ГБ | ¥70,8/мес | $18,1/мес | $15,7/мес | $11,8/мес |
| Эта тестовая партия (99,9 ГБ) | 76,7 ГБ | ¥6,90/мес | $1,76/мес | $1,53/мес | $1,15/мес |
Это ежемесячно повторяющиеся платежи: сожмите один раз — и дальше каждый месяц объём будет тарифицироваться по-новому. Разовая работа даёт долгосрочный эффект.
Плата за трафик: по-настоящему крупная статья
Плата за трафик — это произведение объёма и количества скачиваний: чем чаще запрашивают изображения, тем больше эффект от сжатия. Например: библиотека на 100 ГБ за месяц генерирует 500 ГБ нисходящего трафика через CDN (то есть полная библиотека скачана примерно 5 раз). Трафик уменьшается пропорционально на 76,8%:
| Тариф CDN (нижняя ступень) | Плата за трафик до сжатия | После сжатия | Экономия в месяц | Экономия за год |
|---|---|---|---|---|
| Alibaba Cloud CDN в Китае (¥0,15/ГБ) | ¥75,0 | ¥17,4 | ¥57,6 | ¥691 |
| AWS CloudFront в Азиатско-Тихоокеанском регионе ($0,12/ГБ) | $60,0 | $13,9 | $46,1 | $553 |
| Google Cloud CDN в Северной Америке / Европе ($0,08/ГБ) | $40,0 | $9,3 | $30,7 | $369 |
Взяты минимальные ступени тарифов; реальные ступени обычно выше, и чем крупнее счёт, тем заметнее абсолютная экономия от сжатия. Cloudflare R2 — исключение: исходящий трафик там $0, поэтому выгода почти полностью сводится к экономии на хранении.
Эти расценки — сводка публичных тарифов платформ на 2026 год. Фактические цены зависят от региона, скидок на аккаунте и тарифной ступени; ориентируйтесь на актуальные цены с официальных сайтов. Количество скачиваний в примере — условная величина, подставьте вместо неё реальные цифры из своих счетов.
6. Локальные сценарии: сколько времени экономят при переносе этих данных
Снижение объёма на 76,8% почти пропорционально сокращает время передачи — это работает и без облака, и напрямую видно при копировании и резервном копировании.
- USB3 внешний жёсткий диск: принимаем устойчивую пропускную способность 120 МБ/с.
- USB3 внешний SSD: принимаем 450 МБ/с.
- Гигабитная проводная сеть: после вычета накладных расходов протокола — 105 МБ/с.
| Сценарий | Сэкономленный объём | USB3 HDD | USB3 SSD | Гигабитная сеть |
|---|---|---|---|---|
| Эта тестовая партия | 76,7 ГБ | ≈11 минут | ≈2,9 минуты | ≈12,5 минуты |
| Библиотека 10 ГБ | 7,68 ГБ | ≈66 секунд | ≈17 секунд | ≈75 секунд |
| Библиотека 100 ГБ | 76,8 ГБ | ≈11 минут | ≈2,9 минуты | ≈12,5 минуты |
| Библиотека 1 ТБ | 786 ГБ | ≈112 минут | ≈30 минут | ≈128 минут |
Как и в случае с платой за хранение, здесь работа разовая, выгода постоянная: копирование на внешний диск и обратно, синхронизация с NAS, Time Machine, переезд на новый Mac, передача коллеге — пока вы переносите эти данные, каждый раз экономится примерно такое же время.
7. Если сжимать до загрузки пользователем
Выше мы считали экономию для изображений, которые уже сохранены. Есть ещё один участок, который стоит просчитать: промежуток между нажатием кнопки «Загрузить» и окончанием прогресс-бара. Здесь задействован исходящий канал пользователя — а он почти всегда самое узкое место во всей цепочке. Оригинальный кадр с камеры весит несколько мегабайт; по сравнению с «уже сжатыми сайтом» изображениями из предыдущей статьи (среднее 299 КБ) это на порядок больше, поэтому разница во времени намного заметнее.
Считаем на среднем файле из этой выборки: оригинал с камеры в среднем 2,96 МБ; после ImgZilla — 0,69 МБ; каждое фото экономит около 2,27 МБ.
| Исходящая скорость (типичный диапазон из публичных тестов, для ориентира) | Один файл 2,96 МБ → 0,69 МБ |
Альбом из 50 снимков ≈148 МБ → 34 МБ |
Вся партия из 32 188 файлов 99,9 ГБ → 23,1 ГБ |
|---|---|---|---|
| Мобильная сеть (4G/5G, в среднем 30 Мбит/с) | ≈0,6 с | ≈30 с | ≈5,7 часа |
| Типичная скорость отдачи домашнего интернета (25 Мбит/с) | ≈0,7 с | ≈36 с | ≈6,8 часа |
| Симметричный гигабитный доступ (1000 Мбит/с) | ≈0,02 с | ≈0,9 с | ≈10 минут |
0,6 секунды на одно фото почти незаметно, но при загрузке целого альбома за один раз или пакетном импорте сотен исходников с камеры сэкономленные минуты уже ощущаются — особенно у пользователей мобильного интернета с медленным аплинком.
Диапазоны взяты из открытых тестов скорости в Китае. Реальная скорость сильно зависит от оператора, региона, устройства и загруженности сети; цифры приведены только для оценки порядка величины.
8. Данные и методика тестирования
- Объём выборки. Данные в этой статье получены из реального прогона на 32 188 JPEG с камеры или телефона и показывают результат именно этой выборки, а не то, что «ImgZilla в среднем сжимает на 76,8%». У разных камер и разных моделей результаты будут отличаться; у уже оптимизированных изображений потенциал сжатия заметно ниже.
- Отбор образцов. Вся партия была сжата как есть, по исходным 16 подкаталогам, без фильтрации или чистки. Ни о каком подборе выгодных примеров речи нет.
- Сопоставимость с предыдущей статьёй. Разница между 46,8% в той статье и 76,8% здесь почти полностью объясняется тем, подвергались ли изображения сжатию раньше. Большинство библиотек окажутся между этими цифрами: если картинки уже сжаты при загрузке — ближе к 46,8%; если это впервые загружаемые исходники — ближе к 76,8%.
- Правила расчёта. В тексте 76,8% — это «суммарно сэкономленные байты ÷ суммарные исходные байты». Среднее арифметическое коэффициента сжатия по файлам — 76,6%, медиана — 77,3%; обе методики указаны в тексте. Единицы объёма переведены по соотношению 1 ГБ = 10⁹ байт.
- Параметры сжатия. Параметры фиксированы, в интерфейсе нет ползунка качества. Это осознанный дизайн-компромисс: для каждого формата настройки приведены к балансной точке визуального отсутствия потерь. Пользователям, привыкшим настраивать вручную, стоит это учесть.
- Среда выполнения. Всё выполняется локально на этом компьютере; изображения не покидают этот Mac. Подключение к интернету не требуется (кроме проверки покупки в App Store).
Источники цен (публичные тарифы 2026 года; актуальные значения — на момент прочтения на официальных сайтах): AWS S3 Pricing, тарифы Alibaba Cloud OSS, Google Cloud Storage Pricing, Cloudflare R2 Pricing, тарифы Alibaba Cloud CDN, AWS CloudFront Pricing, Google Cloud CDN Pricing.
Хотите проверить сами? Скачайте ImgZilla прямо из Mac App Store, прогоните через неё пару уже обработанных изображений со своего сайта и решите, стоит ли сжимать дальше.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Подробнее: https://imagetool.app/ImgZilla
Системные требования: macOS 12.3 или новее.