Хабр уже насыщен статьями на тему «нового» формата изображений WebP (описание, сравнение с JPEG2000, сравнение с BPG, использование, подключение на сайте). К сожалению, открытыми остаются вопросы: как правильно подключить WebP на сайте, чтобы «все работало», и насколько он лучше (меньше) PNG/JPEG. В этой заметке я буду отвечать на оба вопроса.Предполагаю, что вы уже в курсе оптимизации изображений, умеете конвертировать изображения в WebP, понимаете разницу между использованием JPEG и PNG на сайте, знаете инструменты ExifTool, jpegtran, mozjpeg, JPEGrescan, optipng, pngcrush, pngwolf, zopflipng и TruePNG, а также различаете пастеризацию молока и постеризацию изображений.
Если все так — то переходим к сути.
Плюсы WebP
Во всех источниках упоминается существенное уменьшение размера изображений, что PNG, что JPEG, если их перекодировать в WebP. При этом перекодирование должно выполняться с сохранением качества. В Айри.рф уже три года используется автоматическая оптимизация изображений без потерь и с незначительными потерями (2 режима). Это позволяет достаточно точно сравнить, когда WebP выигрывает в сравнении с уже оптимизированными PNG (прогоняется через TruePNG, pngwolf и zopflipng) и JPEG (ExifTool, mozjpeg, перевод в png), а когда нет.
На тестовой выборке из 13 тысяч изображений WebP показал выигрыш относительно уже оптимизированных PNG и JPEG файлов на 31% (580 Мб против 837 Мб). WebP-файлы примерно на треть меньше уже оптимизированных аналогов JPEG и PNG. Здесь нужно оговориться, что перевод PNG в WebP выполняется без потерь (lossless), а перевод в JPEG выполняется с минимальными потерями (качество 100), это позволяет в автоматическом режиме отгружать WebP для всех браузеров, которые его понимают, без опасений что-то «поломать» у клиентов.
В подавляющем большинстве случаев выигрыш WebP относительно уже оптимизированных JPEG (mozjpeg) составлял не более 10%. Исключения были в тех случаях, когда из JPEG-файлов нельзя было безопасно вырезать EXIF-данные (в частности, палитру), и перевод их в WebP давал существенный выигрыш. Поэтому если вы создаете JPEG сразу по «нормальному» сценарию, то в большинстве случаев существенного выигрыша не предвидится. PNG-файлы даже после оптимизации относительно неплохо (30%) «теряют в весе», если перевести их в WebP.
Что важнее, относительно всех оптимизированных изображений только в 10% случаев (да, выборка из 13000 изображений — это было только 10% всех оптимизированных изображений) WebP «без потерь» давал выигрыш в размере. Для остальных 90% выигрыша не было (из них 75% — это JPEG файлы). Цифры еще могут быть обусловлены жестким подходом к оптимизации изображений без потерь: возможно, тонкая настройка WebP с «небольшими» потерями качества даст визуально «тот же результат», но будет меньше по размеру. К сожалению, в автоматическом режиме оценить все 130 тысяч изображений, чтобы понять, насколько в каждом конкретном случае сжатие с потерями может быть лучше, не представляется возможным. Сами изображения не представляют какой-либо закономерности: это фоновые картинки и галереи сотен сайтов.
Для справки, перевод PNG в WebP
cwebp -quiet -pass 10 -alpha_method 1 -alpha_filter best -m 6 -mt -lossless -q 100
Перевод JPEG в WebP
cwebp -quiet -pass 10 -alpha_method 1 -alpha_filter best -m 6 -mt -q 100
Отличной иллюстрацией является изображение к статье. Исходный PNG занимал 15,6 Кб. После оптимизации и постеризации — 12,5 Кб. lossless webp из него — 8 Кб.
Реальное использование WebP
Если вы уже научились правильно конвертировать или сохранять изображения в WebP (тема для отдельной статьи), то остается проблема подключения WebP на сайте, которая уже поднималась здесь (игра стоит свеч, ибо Chrome браузеры уже составляют более 2/3 рынка). На стороне браузера возможны варианты с JavaScript (использование тега noscript, ymatuhin):
<script async src="simple-webp.min.js"> <noscript data-webp> <img src="example.png" alt=""> </noscript>
И HTML5 (использование picture, pepelsbey):
<picture> <source srcset="opera.webp" type="image/webp"> <img src="opera.jpg" alt="The Oslo Opera House"> </picture>
Второй вариант, в целом, надежнее (хотя может покрывать меньше браузеров).
Также возможен «пуленепробиваемый» серверный вариант, который читает заголовок
Accept браузера и отгружает соответствующее изображение (все WebP изображения нужно сохранить с расширением .webp к аналогам) браузеру, который их поддерживает (изменения в клиентском коде не нужно). Самый простой вариант для nginx выглядит примерно так:map $http_accept $x_airee_webp {
~*webp '.webp';
default '';
}
...
try_files $uri$x_airee_webp @404Более точные варианты (с правильной поддержкой Vary и Cache-Control) поддерживает в актуальном состоянии Ilya Grigorik в проекте webp-detect (для всех основных веб-серверов).
Мысли к обсуждению
Резюмируя практический опыт использования WebP: это имеет смысл делать, особенно для мобильных браузеров (для них можно отгружать изображения в «плохом» качестве и реально выиграть во времени загрузки страницы). Но для начала нужно настроить весь стек оптимизации изображений «обычными» способами: это даст существенный выигрыш для всех пользователей. После этого поддержка WebP в ваших проектах может быть реализована буквально «в два клика» (конфигурация nginx + конвертация в процессе оптимизации).
Также, на мой взгляд, использование WebP способно «творить чудеса» при точечной оптимизации некоторых типов изображений (с которыми плохо справляются как JPEG, так и PNG) — например, большое количество мелких деталей на фоне больших однородных областей. И если подбирать параметры оптимизации в автоматическом режиме для таких типов изображений — это будет весьма здорово.
Соображения по поводу «удвоения» размера изображений на диске я считая несущественными: если записывать WebP только в тех случаях, когда файл меньше по размеру, и провести оптимизацию всех изображений, то они будут занимать еще меньше места. И перевод PNG изображений в WebP существенно (минимум, на порядок) менее ресурсоемкий, чем оптимизация PNG (с перебором вариантов сжатия).
Буду рад увидеть ваши соображения и прикладной опыт использования изображений в формате WebP.
