WebP против JPEG: сравнение на основе данных

Ключевые цифры: что говорят тесты

Наиболее часто цитируемые данные взяты из собственных тестов Google, опубликованных при выпуске WebP в 2010 году и впоследствии подтверждённых независимыми исследованиями: при эквивалентном визуальном качестве WebP создаёт файлы на 25–35% меньше, чем JPEG. Этот выигрыш применим к кодированию с потерями, которое используется для фотографического контента в интернете.

В режиме без потерь WebP превосходит PNG на 25–34% в зависимости от типа изображения; но это сравнение выходит за рамки области применения JPEG, поскольку JPEG является исключительно форматом с потерями.

Эти цифры являются средними значениями. Реальные результаты варьируются в зависимости от типа контента, целевого уровня качества и версии кодировщика. В таблице ниже показаны результаты для пяти репрезентативных тестовых изображений, закодированных при визуально эквивалентном качестве (SSIM ≥ 0,95) с использованием cjpeg (MozJPEG 4.1) и cwebp (libwebp 1.4):

Как работает WebP и как работает JPEG

Чтобы понять, почему WebP создаёт файлы меньшего размера, нужно базовое понимание обоих кодеков.

JPEG был стандартизирован в 1992 году. Он делит изображение на блоки 8×8 пикселей, применяет дискретное косинусное преобразование (DCT) для преобразования пространственных данных в частотные, а затем использует кодирование Хаффмана (форма энтропийного кодирования) для сжатия полученных коэффициентов. Этот блочный подход объясняет, почему артефакты JPEG проявляются в виде видимых квадратов 8×8 при низких настройках качества. каждый блок сжимается независимо, без ссылки на соседние блоки.

WebP был разработан Google на основе видеокодека VP8 (выпущен в 2010 году). Для кодирования с потерями используется предсказывающее кодирование. значения каждого блока предсказываются на основе соседних уже закодированных блоков, и сохраняется только остаток (ошибка предсказания). Эта межблочная зависимость позволяет WebP гораздо эффективнее, чем JPEG, представлять плавные градиенты и повторяющиеся текстуры. Остатки затем сжимаются с использованием арифметического кодирования, которое эффективнее кодирования Хаффмана в JPEG за счёт несколько большей сложности кодировщика/декодировщика.

Итоговый результат: блоки WebP могут ссылаться на до трёх соседних ранее декодированных блоков для предсказания, тогда как JPEG не может. На реальном фотографическом контенте этот предсказывающий подход захватывает примерно на 25–35% больше информации на бит.

Метрики качества: SSIM и DSSIM

Сравнение сжатых изображений только по размеру файла вводит в заблуждение, если качество отличается. Две метрики, наиболее широко используемые в профессиональной работе с изображениями:

• SSIM (индекс структурного сходства): измеряет яркость, контраст и структурную информацию одновременно. Значение 1,0 означает идентичность изображений. Значения выше 0,95 указывают на отличное качество; значения ниже 0,85 обычно заметны случайному наблюдателю.
• DSSIM (несходство): просто 1 − SSIM (или его вариант). Меньше значит лучше. DSSIM ниже 0,005 считается отличным; выше 0,02 свидетельствует о видимых артефактах.

При сравнении WebP и JPEG всегда выравнивайте по одинаковому SSIM, а не по одинаковой настройке качества кодировщика. JPEG с качеством 80 и WebP с качеством 80 не дают эквивалентных визуальных результатов. шкала качества WebP не совпадает со шкалой JPEG. Правильное сравнение: кодируйте оба до достижения одинакового значения SSIM, а затем сравнивайте размеры файлов. Именно это отражает таблица тестов выше.

Когда JPEG всё ещё побеждает

Несмотря на преимущество WebP в сжатии, есть сценарии, где JPEG остаётся более практичным выбором:

• Универсальная совместимость: JPEG поддерживается везде. в каждом браузере, каждом почтовом клиенте, каждом инструменте редактирования изображений, каждой системной программе для просмотра. WebP требует iOS 14+, macOS 11+ и не поддерживается старыми Android WebViews или Outlook в Windows. Для любого контекста, где вы не можете использовать запасной вариант с элементом <picture> (email, PDF, документы Word, некоторые экспорты CMS), JPEG является безопасным вариантом по умолчанию.
• Сохранение Exif-данных и метаданных: JPEG имеет многолетнюю поддержку инструментами для работы с Exif, IPTC и XMP метаданными. Авторские права, GPS, настройки камеры и цветовые профили хорошо поддерживаются в рабочих процессах JPEG. WebP поддерживает Exif и XMP, но многие инструменты удаляют или повреждают эти метаданные при циклах кодирования/декодирования.
• Редактирование и повторное кодирование: Если изображение будет редактироваться и повторно сохраняться несколько раз (например, в рабочем процессе контент-команды), потери поколения в JPEG хорошо изучены. Инструменты WebP менее зрелы в профессиональных рабочих процессах редактирования, и неожиданные потери качества могут возникнуть при прохождении через приложения с неполной реализацией спецификации.
• Экосистема инструментов: Lightroom, Photoshop, Capture One и большинство DAM-платформ используют JPEG в качестве основного формата экспорта. Экспорт в WebP доступен, но часто вторичен, с меньшим количеством параметров настройки качества в интерфейсе.

Стратегия миграции: запасной вариант с элементом picture

Рекомендуемый подход для веб-миграции на WebP. подавать WebP для поддерживающих браузеров, прозрачно возвращаясь к JPEG для тех, которые его не поддерживают. HTML-элемент <picture> делает это тривиальным:

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Горный пейзаж на рассвете" width="1200" height="630">
</picture>

Браузеры, поддерживающие WebP, загрузят hero.webp. Все остальные. включая IE11, старые Safari и движок рендеринга Outlook. загрузят hero.jpg. Этот паттерн требует поддержания обоих файлов, что примерно удваивает хранилище, но это управляемо с CDN или сервисом оптимизации изображений, который генерирует оба формата по запросу.

Для серверного согласования содержимого проверьте заголовок запроса Accept: image/webp и динамически подавайте подходящий формат. Это устраняет необходимость в дублирующей HTML-разметке.

AVIF: следующий шаг за WebP

AVIF (AV1 Image File Format). преемник WebP, основанный на видеокодеке AV1. При эквивалентном визуальном качестве AVIF обычно на 20–35% меньше WebP и на 40–60% меньше JPEG. Он также нативно поддерживает HDR, широкий цветовой охват и 12-битную глубину.

По состоянию на начало 2026 года AVIF поддерживается в Chrome (85+), Firefox (93+) и Safari (16+), охватывая около 90% доли браузерного рынка. Кодирование AVIF значительно медленнее, чем WebP (часто в 10–50 раз), что делает его нецелесообразным для кодирования в реальном времени, но отличным для предварительно оптимизированных пайплайнов ресурсов. Элемент <picture> поддерживает трёхуровневый запасной вариант:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Главное изображение" width="1200" height="630">
</picture>

Это обеспечивает максимальное сжатие для современных браузеров при сохранении полной обратной совместимости.