Является ли WebP действительно меньше, чем JPG для изображений на сайте?

Мы сравнили JPG, WebP и AVIF на одной и той же фотографии размером 538.6 KB на одном и том же ползунке, и JPG победил. Вот почему это происходит и что показывает справедливое сравнение.

August 9, 2026

Каждое руководство говорит, что WebP примерно на 30% меньше, чем JPG при сопоставимом качестве. Собственное исследование Google является источником этой цифры. Мы провели сравнение на нашем компрессоре с одной фотографией 3840x2160, texture.jpg размером 538.6 KB, и на той же позиции ползунка JPEG победил: 286.1 KB против 290.3 KB для WebP. AVIF, формат, который должен обойти оба, оказался на уровне 312.7 KB.

Ничего не было сломано. Три формата по-разному читают этот ползунок, и один из них делает это намеренно. Как только вы узнаете, какой именно, результат переворачивается обратно так, как вы ожидаете, и у вас появляется привычка, которую стоит перенести в любой инструмент, который вы уже используете.

Почему WebP оказался больше, чем JPG на том же ползунке?

Наш компрессор имеет особенность, которую разделяют многие инструменты, но почти никто из них не упоминает. Когда выходной формат - JPEG, а входной уже был JPEG, он считывает таблицы квантования из исходного файла, оценивает качество, с которым этот файл был сохранен, а затем умножает ваш ползунок на эту оценку. Исходный файл с оценкой 60 при ползунке на 80 кодируется на 48. WebP и AVIF не получают такого обращения, поэтому 80 означает 80, и кодировщик делает то, что ему говорят. Это значение вверху было JPEG с эффективным значением 48 против WebP с буквальным значением 80. Файл, сжатый сильнее, меньше.

Переоценка оправдывает свое место. Пере кодирование уже сжатого JPEG на 80, когда он был записан на 60, добавляет байты, не добавляя никаких деталей обратно, поэтому мы рассматриваем ползунок как долю того, что осталось в файле. Глубокая проблема принадлежит самому JPEG: спецификация хранит сырые таблицы квантования и никогда не хранит число качества, поэтому 75 в Photoshop, 75 в MozJPEG и 75 в каком-то PHP-скрипте - это три разных файла. Сопоставление чисел на двух ползунках и называние этого справедливым тестом не работает.

Как выглядят размеры, когда вы сравниваете их правильно?

При 63 WebP записывает 200.6 KB из этого исходного 538.6 KB. AVIF при том же значении составляет 186.9 KB, и 63 - это то, что наш умный режим выбирает для AVIF в любом случае, так что это не число, которое мы выбрали, чтобы польстить формату. Сначала сопоставьте размеры выходных файлов, затем откройте оба файла в полном размере и решите, с каким из них вы можете смириться. Вот сравнение, которое стоит провести.

Должен ли я просто использовать AVIF тогда?

По байтам AVIF выигрывает. По терпению он проигрывает. Кодирование этого кадра 3840x2160 в AVIF заняло примерно 10-11 секунд в браузере, в то время как JPEG и WebP вернулись мгновенно. Все это выполняется с помощью WebAssembly на вашем собственном компьютере, так что это ваш ноутбук выполняет кодирование AV1, и стоимость увеличивается с количеством пикселей. Есть еще одна уловка, которую стоит знать: если кодировщик WASM не сработает, мы возвращаемся к кодировщику канваса браузера, и канвас может записывать JPEG, PNG и WebP, но не имеет пути для AVIF вообще. Для большой партии Google рекомендует родной инструмент avifenc вместо сборок WebAssembly, и что стоит десять кодировок AVIF в одной вкладке также измеряется.

Что я теряю, когда превращаю JPG в WebP?

Три конкретные вещи. Сначала уходит метаданные: сжатие или конвертация декодирует изображение в сырые пиксели и перекодирует его, так что EXIF, GPS-координаты, ICC-профиль и встроенный миниатюра исчезают из выходного файла. Ориентация сохраняется, потому что браузер применяет ее во время декодирования. Если вам нужна дата захвата, сохраните оригинальный файл. А lossy JPG, перекодированный в lossy WebP, является вторым поколением потерь, наложенных на первое, так что сделайте это один раз из лучшего источника, который у вас есть.

Хрома - это вторая потеря. Lossy WebP привязан к субдискретизации 4:2:0, без варианта 4:4:4 где-либо в формате, так что скриншот синтаксически выделенного кода или логотипа на насыщенном красном фоне может выглядеть хуже в WebP, чем в JPEG того же веса. Фотографии не беспокоят. Рендеринг - это третье: прогрессивный JPEG рисует грубый полный кадр рано и уточняет по мере поступления байтов, а WebP не имеет прогрессивного режима, так что большой файл ничего не показывает, пока не поступит достаточно его. На изображении героя при слабом соединении это меняет то, как быстро ощущается страница, даже когда файл меньше.

Выигрывает ли WebP, если изображение имеет прозрачность?

JPEG не может делать прозрачность. В любом режиме JPEG нет альфа-канала, поэтому для логотипа или выреза реальное соревнование - это PNG против WebP, и аргументы для каждого из этих двух форматов измеряются на этих же файлах. Наши числа PNG устанавливают планку, которую вам нужно преодолеть: alpha.png размером 900x606 и 942.4 KB уменьшился до 383.9 KB с помощью безубыточного oxipng на уровне 3 и до 98.3 KB, как только imagequant уменьшил его до палитры, что составляет 90% с учетом сохраненной прозрачности. WebP хранит свою альфа-прозрачность без потерь даже внутри lossy файла, так что края выреза остаются чистыми в любом случае. Если вы делаете вырез в первую очередь, наш инструмент для удаления фона всегда записывает PNG с альфа-прозрачностью, и этот PNG может быть сразу отправлен в компрессор после этого.

Какой из них мне действительно следует разместить на сайте?

Используйте WebP для фотографий. Каждый современный браузер декодирует его, включая Safari, и экономия реальна, как только вы перестанете сравнивать числа ползунка. Держите JPG там, где файл должен открываться в старом программном обеспечении, или где большой герой выигрывает от прогрессивного рендеринга больше, чем от 30 KB. Руководство по форматам изображений MDN является справочным материалом, который стоит проверить, прежде чем вы посвятите целую библиотеку одному формату.

Сначала проверьте пиксели. Фотография 3840px в четыре раза шире, чем контентная колонка 960px когда-либо отобразит, и ни один кодек не вернет вам то, что передача размера передает бесплатно, так что изменение размера с его предустановками 25/50/75 - это один клик и обычно полностью обходит аргумент формата. Лестница качества важнее, чем формат. Тот же texture.jpg стал 212.4 KB при 60 и 131 KB при 30, и умный режим остановился на 286.1 KB, 47% от, не задавая вам никаких вопросов.

Как мне провести этот тест на своем изображении?

Откройте компрессор, загрузите свою фотографию и переключитесь на ручной режим. Выберите JPG, запомните размер. Переключите выпадающий список формата на WebP на том же ползунке и запомните его. Затем опустите ползунок WebP, пока два файла не окажутся в пределах нескольких КБ друг от друга, и посмотрите на них рядом друг с другом в полном размере, потому что это единственное сравнение, которое что-то говорит вам. Партии ограничены 10 файлами и 50 MB. Если вы предпочитаете полностью пропустить ползунок, JPG в WebP кодирует с фиксированным качеством 80 без переоценки, WebP в JPG возвращается обратно с прозрачностью, наложенной на белый, и PDF-руководство охватывает одно преобразование, которое делает файлы больше.