Готовим WebP правильно

    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.
    • +10
    • 11,5k
    • 8
    Поделиться публикацией

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

      +1
      Спасибо за статью!
      Добавлю свои 5 копеек: поддержка браузерами формата — в основном это Chromium-подобные браузеры и Android: http://caniuse.com/#feat=webp, что больше половины трафика.
        0
        столкнулся на днях с проблемой: мелкие картинки малоцветные (иконки) сильно замыливаются, даже при loseless + quality 100
          0
          Пример, пожалуйста. Не сталкивались с таким на практике (ежедневно десятки тысяч изображений оптимизируются)
            0
            png
            jpg
            webp

            webp({
                        quality: 100,
                        method: 6,
                        sns: 0,
                        lossless: true
                    })
            
              0
              Скорее всего, проблема в используемом софте. Выкладываю результат работы cwebp с параметрами q=100 sns=0 lossless m=6, ни сконвертированный png, ни сконвертированный jpeg (который в 3 раза больше исходного) не похож на предложенный webp. Стоит уточнить у разработчика, с чем связано такое кодирование.
              img
                0
                С разработчиком связи нет ):
          +1
          Автоматическое измерение (сравнение с качеством оригинала) возможно. Для этого хорошо подходят специально созданные для оценки субъективного изменения качества изображения метрики, такие, как SSIM, MultiScale SSIM, 3-Component SSIM.
            0
            Около года назад начал вводить webp на «своих» проектах ради эксперимента. В среднем — выигрыш около 25% при том же качестве. Где-то может быть и 80%, а где то и 1%, но в среднем около 25. И это заметно увеличивает скорость загрузки страниц. Особенно при использовании «мобильных интернетов». Теперь использую webp везде где только можно!

            P.S. У меня не используется webp lossless, т.к. webp генерируется из пользовательских изображений, а они заведомо плохого качества. Ну и огромное количество картинок генерируется on-demand.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое