Полное руководство по сжатию изображений: выбор между JPG, PNG и WebP

Опубликовано 2026-04-13 8 мин чтения

Резюме (TL;DR)

В прошлые выходные я загрузил фотографию своего кота в Squoosh: исходный JPG весом 4,2 МБ превратился в WebP на качестве 80 и ужался до 380 КБ. Сжатие составило 91 %, и на экране смартфона я честно не мог отличить результат от оригинала ни при каком реалистичном масштабе просмотра. Именно так выглядит сжатие с потерями, когда оно работает правильно. Каждый раз, когда я об этом забываю, я открываю какой-нибудь блог и жду три секунды, пока на LTE догрузится 2-мегабайтный hero-JPG, — и урок приходит сам собой.

Выбор формата изображения — это не поиск «самого лучшего», а подбор формата под конкретную задачу. Для фотографий с непрерывными тональными переходами подходят форматы с потерями: JPEG, WebP (с потерями), AVIF. При сопоставимом визуальном качестве WebP обычно даёт файлы на 25–35 % меньше JPEG, а AVIF — примерно на 40–50 % меньше JPEG в зависимости от настроек энкодера. Для логотипов, иконок, скриншотов и всего, где важны чёткие границы и читаемость текста, безопаснее использовать форматы без потерь — PNG, WebP (lossless) или TIFF. Если нужны одновременно прозрачность и анимация, основными вариантами остаются WebP, APNG и AVIF. Поддержка браузеров на начало 2026 года широкая: WebP работает в Chrome 32 (2014), Firefox 65 и Safari 14 (конец 2020-го), а AVIF — в Chrome 85 (август 2020), Firefox 93 (октябрь 2021) и Safari 16 (сентябрь 2022) и новее. Разумная схема по умолчанию: «SVG для векторных логотипов, WebP или AVIF для фотографий, PNG для скриншотов», плюс запасной JPEG внутри элемента <picture> там, где нужно поддерживать устаревшие окружения.

Предыстория и концепции

Форматы с потерями — JPEG, WebP (lossy), AVIF — уменьшают размер файла, отбрасывая информацию, к которой человеческое зрение менее чувствительно. В основе лежат два ключевых приёма. Первый — квантование (quantization): коэффициенты в частотной области грубее округляются, причём высокие пространственные частоты режутся агрессивнее. На фотографии с плавными переходами это почти незаметно, а вот на резких границах могут вылезти «блочные» артефакты. Второй приём — субдискретизация цветности (chroma subsampling): каналы цветности хранятся в более низком разрешении, чем канал яркости. Настройка 4:4:4 сохраняет цветность на полном разрешении, а более распространённая 4:2:0 ужимает цвет по обеим осям вдвое. Для большинства фотографий это работает нормально, но на цветном тексте, особенно красном и синем на тёмном фоне, появляется характерный ореол.

JPEG стандартизован в 1992 году и использует дискретное косинусное преобразование (DCT, Discrete Cosine Transform), применяемое к блокам 8×8 пикселей. WebP построен на внутрикадровой технологии видеокодека VP8, а AVIF — на внутрикадровом наборе инструментов AV1. Благодаря этому оба формата устроены существенно современнее JPEG: более крупные блоки, направленное предсказание и лучшее энтропийное кодирование. PNG — совсем другое животное: это формат без потерь на базе семейства алгоритмов deflate, со встроенной поддержкой альфа-прозрачности и индексированных палитр. PNG никогда не отбрасывает данных, но для фотографического контента эта чистота оборачивается гораздо более увесистыми файлами.

Рядом стоит концепция прогрессивного декодирования. Прогрессивный JPEG и чересстрочный PNG позволяют сразу показать пользователю версию изображения в низком разрешении и постепенно её уточнять. WebP и AVIF сегодня обычно декодируются за один проход; это важно в основном для очень крупных изображений или медленных соединений. SVG, в свою очередь, не является сжатым растровым форматом вовсе — это векторное описание, размер которого определяется числом фигур и сжатием самого текста (gzip и brotli на исходном SVG работают очень хорошо).

Сравнение и данные

ФорматС потерямиБез потерьПрозрачностьАнимацияТипичное сжатие фотоПоддержка браузеров, 2025
JPEGДаНетНетНетоколо 10:1Все браузеры
PNGНетДаДаAPNG-расширениепримерно 2–3:1Все браузеры
WebPДаДаДаДана 25–35 % меньше JPEGSafari 14 (2020) и выше, фактически везде
AVIFДаДаДаДана 40–50 % меньше JPEGChrome 85+, Firefox 93+, Safari 16+
GIFДа (палитра 256 цветов)Нет1-битнаяДаНе подходит для фотоВсе браузеры

Эти числа — общие тенденции, а не гарантии. Реальное сжатие сильно зависит от содержимого, энкодера, пресета и целевого качества. Один и тот же JPEG на качестве 85 и 60 может различаться по размеру в 3–4 раза, а преимущество AVIF уменьшается на быстрых пресетах. Бенчмарки Google и Mozilla 2019–2023 годов показывали экономию WebP около 26–34 % относительно JPEG при равном SSIM, а AVIF — около 40–50 % относительно JPEG, но эти диапазоны предполагают медленные пресеты энкодеров и настроенные цели качества, а не дефолтные значения в редакторах.

Отдельное измерение — стоимость кодирования и декодирования. JPEG декодируется за доли миллисекунды на любом устройстве. WebP близок к нему. Декодирование AVIF заметно тяжелее для CPU, а кодирование AVIF на качественных пресетах может занимать секунды на одно изображение. Такой профиль стоимости отлично подходит для сборочного пайплайна, но неудобен для пользовательского контента, где сервер перекодирует каждую загрузку в «горячем» пути.

Практические сценарии

Сценарий 1 — превью и hero-изображения в блоге. Недавно я аудировал собственный сайт и обнаружил hero-картинку весом 1,8 МБ. Пересборка в WebP на качестве 82 уронила её до 210 КБ, а Largest Contentful Paint страницы опустился с 2,4 с до 1,1 с в Lighthouse на профиле throttled 4G. По умолчанию используйте WebP, а в <picture> отдавайте JPEG как запасной вариант для очень старых окружений. Всегда приводите экспортируемое изображение к ширине фактического CSS-контейнера: отдача 3000-пиксельной фотографии в контейнер шириной 600 px — это бездумная трата трафика независимо от формата.

Сценарий 2 — логотипы и иконки. Если у вас есть векторный исходник, в первую очередь экспортируйте SVG. Однажды я ревьюил лендинг, на котором красный логотип был сохранён как JPEG на качестве 75: красные края расплылись в розовый ореол вокруг каждой буквы. Субдискретизация 4:2:0 разрушает красные границы на тёмном фоне раньше всего остального. Если есть только растр, выбирайте PNG или lossless WebP. Сжатие с потерями на логотипах — это красный флаг, а не оптимизация.

Сценарий 3 — скриншоты и захваты UI. Скриншоты по умолчанию должны быть в PNG. Хром браузера, фрагменты кода и CJK-шрифты сильно страдают от JPEG-артефактов. Я усвоил это, после того как ревьюер документации дважды подряд написал «моноширинный шрифт размытый». Если файл нужно ужать, используйте pngquant (на macOS: brew install pngquant) и сбросьте палитру до 256 цветов — на UI-скриншотах разница почти никогда не видна, а файл часто уменьшается в 4–6 раз. Для docs-сайтов рассмотрите связку PNG и responsive image markup в CSS: экранам с retina пойдёт 2x-вариант, а старым — 1x. Обычно это экономит больше байтов, чем смена формата.

Сценарий 4 — архивирование исходников. Для оригиналов, которые вы, возможно, будете переобрабатывать (мастер-файлы фотосъёмки, сырые сканы, предметные снимки), храните копию без потерь — TIFF или lossless WebP — в «холодном» хранилище, а варианты с потерями стройте по требованию. Повторное пересжатие JPEG каждый раз деградирует качество (generation loss), поэтому важно иметь чистый исходник, к которому можно вернуться.

Распространённые заблуждения

«PNG всегда даёт максимальное качество». Он действительно без потерь, то есть воспроизводит изображение точно, но для фотографий эта чистота оборачивается файлами в несколько раз крупнее необходимого. На мобильных устройствах многомегабайтные фото ухудшают воспринимаемое время загрузки и метрики Core Web Vitals.

«WebP не работает во всех браузерах». С момента выхода Safari 14 в конце 2020 года WebP поддерживается всеми основными браузерами. Если действительно нужна поддержка легаси, аккуратное решение — элемент <picture> с JPEG-запасом.

«AVIF — это магия». Эффективность сжатия у него отличная, но кодирование существенно медленнее, чем у JPEG или WebP. На моём M2 MacBook Air avifenc --speed 4 работает 5–9 секунд на одну фотографию 2400×1600, а на --speed 0 — 30 секунд и более. Декодирование на старых мобильных устройствах тоже может быть проблемой. AVIF лучше ложится на пакетные пайплайны и сборочную оптимизацию, чем на перекодирование каждой пользовательской загрузки «на лету».

«Просто используйте JPEG». До примерно 2015 года это было разумно, но современные WebP и AVIF, как правило, дают меньшие файлы при сопоставимом качестве с универсальной или почти универсальной поддержкой. В новых пайплайнах базовым форматом стоит делать WebP, а не JPEG.

«Чем выше качество, тем лучше». Выше примерно 85 для JPEG или WebP размер файла растёт быстрее, чем воспринимаемое качество. Между качеством 85 и 95 зритель редко видит разницу, а файл может оказаться вдвое больше. Измеряйте с помощью перцептивных метрик (SSIM, butteraugli), а не полагайтесь на ползунок качества как на линейную шкалу.

«Если хорошо сжать, размер уже не важен». Самый большой выигрыш в доставке изображений чаще всего даёт отдача картинок подходящего размера, а не тюнинг сжатия. WebP шириной 800 px почти всегда легче WebP шириной 3000 px независимо от качества, потому что вы убираете пиксели, а не аппроксимируете их.

Чек-лист

  1. Исходник векторный? Если да — сохраняем в SVG.
  2. Нужна ли прозрачность?
    • Да и контент фотографический: lossy WebP с альфа-каналом или AVIF.
    • Да и это логотип/иконка: PNG или lossless WebP.
  3. Нужна анимация? Animated WebP, APNG или AVIF. Палитра GIF в 256 цветов плохо подходит для фото.
  4. Контент фотографический или с плавными градиентами? По умолчанию lossy WebP, для важного трафика добавляем AVIF.
  5. Контент — скриншот или текстовый UI? PNG или lossless WebP.
  6. Нужна максимальная совместимость? <picture> с источниками AVIF → WebP → JPEG в этом порядке.

Связанный инструмент

Опробовать все эти компромиссы на практике можно в компрессоре изображений Patrache Studio, указанном в relatedToolUrl. Изображения обычно живут внутри более крупного пайплайна ассетов, поэтому полезно прочитать сопутствующие руководства. Слияние и разделение PDF в браузере рассказывает, что происходит, когда ваши изображения попадают в договоры и сканированные подборки, а Безопасность QR-кодов пригодится, если на упаковке или постерах вместе с картинками печатаются сканируемые QR-коды.

Источники

Связанный инструмент

tools.patrache.studio/image/compress/