WebPХабр уже насыщен статьями на тему «нового» формата изображений 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.

Комментарии (8)


  1. Nickmob
    07.04.2016 10:56
    +1

    Спасибо за статью!
    Добавлю свои 5 копеек: поддержка браузерами формата — в основном это Chromium-подобные браузеры и Android: http://caniuse.com/#feat=webp, что больше половины трафика.


  1. seokirill
    07.04.2016 14:25

    столкнулся на днях с проблемой: мелкие картинки малоцветные (иконки) сильно замыливаются, даже при loseless + quality 100


    1. sunnybear
      07.04.2016 15:17

      Пример, пожалуйста. Не сталкивались с таким на практике (ежедневно десятки тысяч изображений оптимизируются)


      1. seokirill
        08.04.2016 09:38

        png
        jpg
        webp

        webp({
                    quality: 100,
                    method: 6,
                    sns: 0,
                    lossless: true
                })
        


        1. sunnybear
          09.04.2016 09:48

          Скорее всего, проблема в используемом софте. Выкладываю результат работы cwebp с параметрами q=100 sns=0 lossless m=6, ни сконвертированный png, ни сконвертированный jpeg (который в 3 раза больше исходного) не похож на предложенный webp. Стоит уточнить у разработчика, с чем связано такое кодирование.
          img


          1. seokirill
            09.04.2016 10:44

            С разработчиком связи нет ):


  1. alekseyefremov
    07.04.2016 15:16
    +1

    Автоматическое измерение (сравнение с качеством оригинала) возможно. Для этого хорошо подходят специально созданные для оценки субъективного изменения качества изображения метрики, такие, как SSIM, MultiScale SSIM, 3-Component SSIM.


  1. anonymous
    00.00.0000 00:00