Самый распространённый маркетинговый приём инструментов сжатия — утверждения вроде «уменьшение объёма на 70%», которые невозможно проверить. В этой статье я не ссылаюсь на отраслевую статистику, а привожу реальные результаты теста с подробным описанием методики — любой может повторить его самостоятельно.
1. Объект теста: не оригиналы, а изображения, уже прошедшие одно сжатие
Большинство тестов сжатия используют исходники прямо с камеры — условия слишком идеальные. Этот тест сознательно приближен к реальной задаче: сайт, позволяющий пользователям загружать изображения, уже выполняет обычное сжатие при сохранении файлов — то есть мы тестируем не необработанные изображения, а готовые файлы, которые уже «сжали один раз».
Объём выборки: 78 папок, всего 4624 изображения (в основном JPG). Структура каталогов — типичная архивная схема «один альбом — одна папка», без фильтрации и очистки.
Общий исходный объём этих файлов на сервере: 1.41 GB.
Главный вопрос: какой объём можно дополнительно выжать из изображения, уже обработанного одним инструментом сжатия, передав его другому? Многие пользователи интуитивно думают: «раз уж сжато, то сжато — вторичное сжатие бессмысленно».
2. Контрольная группа: сколько экономит упаковка в zip?
Перед запуском ImgZilla мы упаковали ту же партию файлов как есть в zip и посмотрели на эффект универсального алгоритма сжатия:
| Объём | Относительно исходного | |
|---|---|---|
| Исходные файлы после сжатия сайтом | 1.41 GB | — |
| Упаковка в zip | 1.41 GB | -0.2% |
Почти никакой разницы. Причина проста: JPEG сам по себе — сжатый формат, его данные уже прошли энтропийное кодирование, поэтому универсальный алгоритм (zip использует DEFLATE) вряд ли сможет сжать уже сжатые данные. Независимо от того, обрабатывались ли исходники сайтом, zip здесь бессилен.
3. Реальный тест повторного сжатия ImgZilla
Мы перетащили эти файлы в ImgZilla и сжали их на месте. Все 78 папок и 4624 изображения полностью сохранили структуру каталогов и имена файлов:
| Объём | Относительно исходного | |
|---|---|---|
| Исходные файлы после сжатия сайтом | 1.41 GB | — |
| Упаковка в zip | 1.41 GB | -0.2% |
| После повторного сжатия ImgZilla | 0.75 GB | -46.8% |
Поверх уже выполненного сайтом сжатия ImgZilla дополнительно сохранила около 662 MB — объём сократился почти вдвое. Пути ко всем папкам, имена файлов и уровни вложенности остались прежними — это проверяемые фактические данные, а не рекламные обещания.
Это подтверждает важный факт: «сжатие при загрузке на сайт» и «аккуратное кодирование со специально подобранными для формата параметрами» — разные вещи. Большинство сайтов при сохранении выполняет разовое, консервативное сжатие (обычно ограничивая лишь качество или размер), далеко не исчерпывающее возможности кодека. ImgZilla настраивает параметры отдельно для каждого формата и выполняет для JPEG визуально без потерь перекодирование — на уровне пикселей изменения есть, но они укладываются в порог, практически неразличимый глазом. Поэтому даже в «уже сжатых» файлах находится дополнительное пространство.
Нужно уточнить часто смешиваемые понятия: «визуально без потерь» ≠ «без потерь». Настоящее сжатие без потерь (пиксели не меняются) применимо только к PNG (oxipng) и SVG; JPEG, WebP, AVIF, HEIC и GIF в принципе перекодируются с потерями, просто параметры выбираются так, чтобы потери были визуально незаметны. В ImgZilla есть встроенное окно сравнения: можно расположить исходное и сжатое изображение рядом, приблизить до фактического размера и сверять попиксельно.
4. Детальный анализ: коэффициенты сжатия по файлам, размеры в пикселях и длительность
Общий показатель 46.8% — это сводный результат по 4624 изображениям. На уровне отдельных файлов видно ещё больше деталей.
Степень сжатия распределена неравномерно
Для каждого изображения мы вычислили коэффициент сжатия (размер после / размер до). Диапазон — от 32.3% до 85.8%:
- Максимальный коэффициент: около 765 KB → 109 KB, то есть 85.8% от исходного. Обычно такие файлы изначально сжимались недостаточно интенсивно, и у них есть большой резерв для перекодирования.
- Минимальный коэффициент: около 572 KB → 387 KB, то есть 32.3% от исходного. Эти изображения были сжаты раньше довольно плотно, и выжать из них дополнительное место сложно.
- Среднее арифметическое коэффициентов для 4624 файлов — 46.44%, что близко к показателю 46.8%, рассчитанному по суммарному объёму, но не совпадает с ним. Первое — это простое усреднение коэффициентов всех файлов, второе — «сумма сэкономленных байт ÷ суммарный исходный объём». Разница говорит о том, что вклад файлов с разными коэффициентами в общий объём неодинаков: несколько крупных файлов влияют на итог сильнее.
Примечательно: у всех изображений коэффициент положительный, случаев «уже минимальный размер, пропуск» не было — каждый из «сжатых сайтом» файлов удалось дополнительно сократить.
Размеры в пикселях: без изменений
Мы посчитали размеры всех 4624 изображений. Самый распространённый — 1600×2400 (1756 шт.) и его горизонтальная версия 2400×1600 (500 шт.). Диапазон — от минимальных 450×675 (примерно 300 000 пикселей) до максимальных 3000×2000 / 2000×3000 (примерно 6 млн пикселей).
Выборочная сверка размеров до и после сжатия: полностью совпадают, изменений нет:
| Файл (пример) | Исходный размер | Размер после сжатия |
|---|---|---|
| Образец 1 | 1600×1066 | 1600×1066 |
| Образец 2 | 2000×3000 | 2000×3000 |
| Образец 3 | 1416×2128 | 1416×2128 |
Здесь видна вторая половина определения «сжатие на месте», которую легко упустить: не меняются не только имена и пути, но и разрешение. ImgZilla не масштабирует и не кадрирует — всё уменьшение объёма достигается исключительно перекодированием, а не отбрасыванием пикселей.
Время выполнения: 4624 файла за 51 мин 32 сек, в среднем 0.669 сек на файл
Условия: Mac mini с чипом Apple M1, 8 ГБ унифицированной памяти; изображения находятся на жёстком диске NAS, подключённом по проводной сети 2.5G.
Ход выполнения отслеживался по времени последней записи каждого файла (момент завершения сжатия и записи ImgZilla на диск). Первый файл записан в 16:06:09, последний — в 16:57:41. Общее время обработки — 51 мин 32 сек, в среднем 0.669 сек на файл.
Эти данные соответствуют принципу «последовательной обработки»: файлы сжимаются один за другим, без параллельной и неупорядоченной записи. Если пересчитать, получается около 90 файлов в минуту. Фактическая скорость зависит от размера изображений и мощности машины; приведённое число — это просто реальная длительность для партии со средним размером ~305 KB в описанных условиях, и его не стоит считать универсальным ориентиром.
5. Почему выбрано сжатие «на месте», а не создание копий?
Если бы в тесте использовался инструмент с «сохранением сжатой версии отдельно», получилось бы: исходники 1.41 GB + сжатая копия 0.75 GB — в сумме 2.16 GB, то есть даже больше места, плюс появились бы файлы с суффиксами xxx-min.jpg, которые нужно вручную переносить и обновлять ссылки в базе данных или каталоге.
ImgZilla перезаписывает файлы на месте: результат сжатия записывается обратно в тот же путь. Все 4624 имени файлов в 78 папках остаются прежними. Это особенно важно для сайтов, которые уже сохранили пути к изображениям в базе, CDN или CMS, — не придётся менять ни одну ссылку. Оборотная сторона — изменение исходных файлов, поэтому по умолчанию оригиналы сначала перемещаются в системную корзину, а затем записывается сжатый результат; если нужно откатить изменение, в корзине можно щёлкнуть правой кнопкой и выбрать «Вернуть на место».
6. Анализ выгоды: от реальных сценариев до месячных счетов
Кому эти данные действительно полезны
- Сайтам и разработчикам с пользовательской загрузкой изображений: хранение и CDN-трафик обычно тарифицируются за гигабайт. Уменьшение объёма вдвое примерно вдвое сокращает счёт. Причём трафик оплачивается при каждом обращении; чем больше посещаемость, тем ярче эффект сложных процентов. Даже если при загрузке сайт уже выполняет обычное сжатие, этот тест показывает: дополнительный прогон со специально подобранными параметрами даёт существенную выгоду.
- Тем, у кого на сервере мало места / небольшой диск: утилиты очистки обычно удаляют кэш и дубликаты, но через несколько месяцев они появляются снова. Сжатие же освобождает место за счёт того, что сами используемые файлы уменьшаются, и оно не «отрастает» обратно. В нашем случае 78 папок после сжатия дали 662 MB свободного пространства — и это постоянное освобождение.
- Тем, кто часто переносит данные: при копировании, синхронизации и резервном копировании сокращение объёма на 46.8% почти пропорционально сокращает время передачи. Достаточно сжать один раз — каждая будущая операция переноса станет быстрее.
Сколько стоят эти 46.8% в пересчёте на месячные счета?
Сокращение объёма по-настоящему убедительно, когда оно отражается в счетах. Ниже никакой статистики вроде «компрессия повышает конверсию» — только умножение реальных 46.8% на публичные тарифы крупнейших облачных провайдеров за хранение и трафик. Чистая арифметика.
Экономия на хранении = сэкономленный объём (GB) × тариф (¥ или $ / GB / мес.)
Экономия на исходящем трафике = сэкономленный объём (GB) × число загрузок/обращений за месяц × тариф (¥ или $ / GB)
Объём уменьшился вдвое — обе статьи расходов также сокращаются примерно вдвое. Это математика, а не гадание.
Плата за хранение: чем больше архив, тем заметнее выгода
Китайские провайдеры:
| Исходный размер архива | Сэкономлено | Alibaba Cloud OSS (стандартное хранение) ¥0.09/GB/мес |
|---|---|---|
| 10 GB | 4.68 GB | ¥0.42/мес |
| 100 GB | 46.8 GB | ¥4.21/мес |
| 1 TB | 479 GB | ¥43.1/мес |
Зарубежные провайдеры:
| Исходный размер архива | Сэкономлено | AWS S3 Standard $0.023/GB/мес |
Google Cloud Storage $0.020/GB/мес (Regional, US) |
Azure Blob Storage $0.018/GB/мес (Hot, LRS) |
Cloudflare R2 $0.015/GB/мес |
|---|---|---|---|---|---|
| 10 GB | 4.68 GB | $0.11/мес | $0.09/мес | $0.08/мес | $0.07/мес |
| 100 GB | 46.8 GB | $1.08/мес | $0.94/мес | $0.84/мес | $0.70/мес |
| 1 TB | 479 GB | $11.02/мес | $9.58/мес | $8.62/мес | $7.19/мес |
Цены крупнейших зарубежных провайдеров на хранение очень близки (разница в пределах 30%). Важно не то, у кого дешевле, а то, что у любого из них объём вдвое — значит, и счёт почти вдвое меньше. Оплата повторяется ежемесячно. Один раз сжали — а затем каждый месяц тарификация идёт от меньшего объёма. Это разовая работа и постоянная долгосрочная выгода.
Плата за трафик: самая значимая часть, она масштабируется с посещаемостью
Плата за трафик заслуживает большего внимания, чем хранение, потому что это произведение объём × количество скачиваний. Чем чаще открывают изображения, тем выше выгода от сжатия. Предположим, архив изображений занимает 100 GB, а за месяц через CDN передано 500 GB вниз (это примерно пять полных скачиваний архива):
| CDN / тариф за исходящий трафик (первая ступень) | Счёт за трафик до сжатия | После сжатия (трафик -46.8%) | Экономия в месяц | Экономия за год |
|---|---|---|---|---|
| Alibaba Cloud CDN, Китай (низкая ступень ¥0.15/GB) | ¥75.0 | ¥39.9 | ¥35.1 | ¥421 |
| AWS CloudFront, Азиатско-Тихоокеанский регион ($0.12/GB) | $60.0 | $31.9 | $28.1 | $337 |
| Google Cloud CDN, Северная Америка/Европа ($0.08/GB) | $40.0 | $21.3 | $18.7 | $224 |
| Azure Front Door Standard, Zone 1 ($0.08/GB) | $40.0 | $21.3 | $18.7 | $224 |
Здесь указаны минимальные ступени тарифов. Реальные ступени часто выше (например, у Alibaba Cloud CDN верхняя ступень для китайского трафика может достигать ¥1.31/GB) — чем больше счёт, тем больше абсолютная экономия. У Azure в таблице — уровень Front Door Standard: кроме трафика с оплатой за гигабайт, в него входит базовая плата около $35/мес, которую сжатие не уменьшает; в экономию она не включена.
Cloudflare R2 — исключение: исходящий трафик у него по сути $0. Если у вас бакет в R2, выгода от сжатия почти целиком реализуется в строке хранения, а счёта за трафик нет вовсе. Это иная модель, чем двойная архитектура «хранение + трафик» (например, Alibaba Cloud OSS+CDN, AWS S3+CloudFront). Перед выбором провайдера нужно точно понимать, из чего складывается ваш счёт.
Приведённые расценки собраны из открытых прайс-листов платформ на 2026 год. Фактические цены зависят от региона, скидок на аккаунте и ступеней тарифа — уточняйте актуальные на официальном сайте. Число загрузок и обращений — это примерные допущения; для своей оценки подставьте реальные данные из счетов.
7. Экономия времени на передачу и загрузку
Объём уменьшается вдвое — время передачи почти пропорционально сокращается. Это правило не связано с облачными счетами: оно работает и при локальном копировании, резервном копировании, и в момент пользовательской загрузки.
Локальные сценарии: USB 3 и гигабитная сеть
- USB 3 HDD: типичная скорость последовательного чтения/записи 100–150 MB/s, возьмём медиану 120 MB/s.
- USB 3 SSD: скорость заметно выше, обычно 400–500 MB/s, возьмём 450 MB/s.
- Гигабитная проводная сеть (1000 Mbps): теоретический предел 125 MB/s, с учётом накладных расходов реальная непрерывная скорость составляет около 100–110 MB/s, возьмём 105 MB/s.
Это оценочные типовые значения; фактическая скорость зависит от типа носителя, качества интерфейса и сети. Нужны только для приблизительных прикидок.
| Сценарий | Сэкономлено | USB 3 HDD @120 MB/s | USB 3 SSD @450 MB/s | Гигабитная сеть @105 MB/s |
|---|---|---|---|---|
| Наша тестовая партия | 662 MB | ≈5.5 с | ≈1.5 с | ≈6.3 с |
| Архив 10 GB | 4.68 GB | ≈40 с | ≈10 с | ≈45 с |
| Архив 100 GB | 46.8 GB | ≈6.5 мин | ≈1.7 мин | ≈7.4 мин |
| Архив 1 TB | 479 GB | ≈66 мин | ≈18 мин | ≈76 мин |
Сэкономленные 662 MB в одной операции выглядят скромно — всего несколько секунд. Но, как и с хранением, это разовая работа и постоянная выгода: перемещаете ли вы данные на внешний диск или с него, синхронизируете NAS, запускаете Time Machine, переносите данные на новый Mac или отправляете коллеге — пока вы продолжаете работать с этим массивом, каждая операция будет быстрее на один и тот же процент. Сжали один раз — и любая последующая передача экономит время.
Если сжимать перед загрузкой пользователем: меньше ожидания
Выше речь шла о выгоде «после того как файлы уже сохранены» — хранение, CDN, локальная передача. Но есть ещё одно звено: время ожидания от нажатия «Загрузить» до завершения прогресс-бара. Здесь используется исходящий канал пользователя, а он обычно самое узкое место во всей цепочке. У большинства домашних тарифов аплоад составляет примерно одну десятую — одну пятую от входящей скорости; в мобильных сетях ещё меньше. Если сайт или приложение сожмёт изображение с помощью ImgZilla до отправки, сэкономленный объём напрямую превратится в уменьшение времени ожидания.
По средним файлам из теста: «сжатые сайтом» оригиналы имели в среднем 299 KB, после ImgZilla — 159 KB, экономия около 140 KB на файл.
| Скорость загрузки (публичные замеры, типичный диапазон; ориентир) | Одно фото 299KB→159KB |
Альбом из 50 фото ≈15.0MB→8.0MB |
Все 4624 фото из теста 1.41GB→0.75GB |
|---|---|---|---|
| Мобильная сеть (4G/5G; медианные открытые замеры ~10–50 Mbps, берём 30 Mbps) | экономия ≈0.04 с | ≈1.9 с | ≈3 мин |
| Обычный домашний аплоад (тарифы 100/1000 Mbps вниз, аплоад обычно 20–30 Mbps, берём 25) | ≈0.04 с | ≈2.2 с | ≈3.5 мин |
| Симметричный гигабитный аплоад (редкие операторы/корпоративные линии, 1000 Mbps) | ≈0.001 с | ≈0.06 с | ≈5.3 с |
| Справка: средний фиксированный аплоад в США (Ookla, 2026) | ≈0.02 с | ≈1 с | ≈1.5 мин |
Для одного файла таблица может показаться бессмысленной — 0.04 с почти не ощущается. Это честный результат: сами файлы в тесте небольшие (сайт уже сжал их перед хранением, в среднем всего 299 KB). Ценность появляется в двух сценариях: массовая загрузка целого альбома или десятков файлов разом и более крупные исходники (например, JPEG с камеры или пользовательский контент без предварительного сжатия — там файлы занимают мегабайты, а не сотни килобайт). При одинаковом проценте сжатия абсолютная экономия секунд возрастает пропорционально. А для мобильных пользователей с медленным аплоадом сокращение ожидания будет ещё заметнее.
Диапазоны по мобильным и домашним сетям основаны на открытых статистиках замеров (медианы 4G/5G, типичные соотношения аплоада). Фактические скорости сильно зависят от оператора, региона, устройства и загруженности сети; воспринимайте их как порядок величин. Данные по аплоаду в США взяты из публикаций Ookla Speedtest.
Хотите проверить сами? Скачайте 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