Стандарт кодирования изображений WebP нельзя назвать новым, его представила Google в уже далёком 2010 году. Однако всё это время использование его было сильно ограничено из-за того, что разработчики браузеров имели собственное мнение по поводу того, какой новый формат изображений должен поддерживать их браузер. Но скоро ситуация изменится, т. к., наконец, поддержка WebP появится на подавляющем большинстве браузеров. Но стандарт WebP рискует стать популярным, будучи уже устаревшим, ведь его конкурент — AVIF, поддерживаемый альянсом большинства разработчиков браузеров, уже в активной разработке.
Поддержка WebP
Несмотря на открытость формата WebP, Firefox долго тянули с внедрением WebP. Разработчики «лисы» долгое время пытались продвинуть формат APNG как замену анимированных Gif, WebP в этом плане мешал продвижению. Кроме того, Mozilla экспериментировала с улучшением алгоритмов сжатия jpeg, и даже представила свой кодировщик MozJpeg. Тем не менее, в кодовую базу Firefox было решено включить, наконец, поддержку WebP, и планируется к релизу в Firefox 65 в первой половине 2019 года.
Microsoft же изначально делала ставку на JPEG XR, и решение не внедрять WebP было скорее политическим. Однако продвижению этого формата помешало то, что этот формат был не свободным от лицензирования, поэтому принятия его сообществом Open Source никогда бы не последовало. Что касательно WebP, взгляд Microsoft на него недавно изменились, и уже внедрила поддержку его в Edge 18.
На данный момент, единственный участник, который пока не планирует включать поддержку WebP в свои браузеры — это Apple, даже несмотря на то, что тестовая поддержка его была в браузере Safari. Причины на то есть, во-первых, у Apple есть собственный формат HEIF, основанный на стандарте видеосжатия HEVC. Во-вторых, в активной разработке формат AVIF, который гораздо современнее, чем WebP. Как будет дальше — покажет время.
WebP уже устарел
Формат WebP основан на алгоритме сжатия ключевых кадров видеокодека VP8. Хотя его эффективность перед JPEG не вызывает сомнений, сам VP8 уже устарел, и есть более эффективные алгоритмы в VP9, HEVC и AV1. Если использование второго не представляется возможным из-за лицензионных составляющих, то последний специально разрабатывается свободным от лицензионных выплат.
На данный момент в альянс Alliance for Open Media который развивает стандарт AV1, входят практически все участники браузеростроения — Google, Microsoft, Mozilla и Apple. Кроме того в альянс входят разработчики чипов, и обещают внедрить аппаратное ускорение, что немаловажно, особенно для мобильных устройств. В целом перспективы AV1/AVIF выглядят радужно, но пока его нет, WebP для изображений выглядит вполне хорошей альтернативой.
Комментарии (60)
tuxi
29.11.2018 17:30Устарел не устарел, но результаты перехода на webp впечатляют. Вот буквально вчера допилили сервер который на лету трансформирует jpg в webp, сегодня грубую оценку проводили на стенде с копией прода. Минимум!!! -25%, а в среднем под 30..35% уменьшение трафика, плюс оптимизация хром-движка под декодинг webp впечатляет
consalt
29.11.2018 17:50То есть пользователь вам загружает jpg, а вы его конвертируете и храните в webp?
tuxi
29.11.2018 18:07+1Если грубо то да. На деле у нас свой cdn которому можно сказать "дай картинку с шириной 200", или дай jpg вместо этого png. И куча слоев кешерования, так как больше 50% медиа — это сгенеренные картинки на базе 2...3..4 других. И вот сейчас можно сказать cdn-у "а дай ка братец мне вот такой webp!".
Ну и ессно выходной html поток пока что фильтруется подменой .jpg на .webp если в accept у клиента указана поддержка webp
consalt
29.11.2018 17:53Мне кажется, что webp сможет взлететь только когда любой графический просмотрщик его будет понимать. А каждый фоторедактор сможет сохранять в webp. К слову в GIMP добавили поддержку webp считанные месяцы назад. :(
PaulZi Автор
29.11.2018 17:58Тут такой процесс взаимосвязанный. Начнут повсеместно внедрять в веб, добавят в просмотрщики, а там уже и через пару лет и железо подтянется. Другой вопрос что учитывая активную разработку другого формата всеми участниками альянса, а не только гуглом, скорее всего webp так и останется внутри веба.
Harrix
29.11.2018 18:48+1Не всегда это работает. Например, тот же вездесущий SVG до сих пор просмотрщиками не поддерживается, а для отображения миниатюр в Windows приходится использовать сторонний svg-explorer-extension, работу которого сложно назвать идеальной (особенно, если используется clipping mask).
t_kanstantsin
29.11.2018 18:00Заголовок чистой воды кликбейт. Никакой конкретики — кто разрабатывает новый формат, на какой стадии разработка, какие приложения поддерживают его, примеры использования нового формата.
Я может тоже разрабатываю "свой" формат — так что avif уже устарел.
Во-вторых, в активной разработке формат AVIF, который гораздо современнее, чем WebP.
И когда появится поддежка конвертации в этот формат? Когда он станет доступным повсеместно в браузерах?
Не будет ли Firefox (или любой другой браузер) так же тянуть с вводом поддержки этого формата?
А когда наконец новый формат будет поддерживаться хотя бы 70% браузеров (как сейчас), не появится ли новый "прорывной" формат, которые на момент написания очередной статьи о нём будет "в активной разработке"?PaulZi Автор
29.11.2018 18:05+1Ситуация с продвижением WebP и Avif кардинально разная. Если WebP двигал по сути только гугл, не имея поддержки ни со стороны других браузеров, ни со стороны производителей железа. Тут ситуация диаметрально противоположная.
Кто разрабатывает — указано в статье. Есть сайт альянса, где есть вся информация по участникам и роадмапам.
Тестовая поддержка видео av1 уже есть в firefox и chrome. Так же есть большие обещания со стороны других участников и сервисов внедрить новый формат после фиксации.
MiXei4
29.11.2018 21:2970% мало зависит от Firefox и любого другого бразуера, потому что 62% из этих 72% — это хром и… мобильный хром. То есть захочет гугл — будет 70, не захочет — не будет.
mistergrim
29.11.2018 22:35+2Картинка врёт, не даёт JPEG таких жутких артефактов. В 7 кб сжимается примерно так:
PaulZi Автор
30.11.2018 10:17К сожалению реальный пример, тут есть исходники.
Такой jpeg выдают множество библиотек, в частности данный пример выдал jpegoptim:
jpegoptim -q --max=85 --strip-all file.jpg
По опыту JPEG очень не любит красные однородные цвета.
Photoshop я знаю лучше справляется с кодированием jpeg, но его в автоматическом режиме к сайту сложновато подцепить.mistergrim
30.11.2018 13:28Такой jpeg выдают множество библиотек,
Значит, не надо использовать такие библиотеки.PaulZi Автор
30.11.2018 13:34Посоветуйте что, чтобы на сайте можно было автоматически сохранять. ImageMagick и jpegoptim — не катят.
VEG
30.11.2018 13:55+1MozJPEG даже лучше результат выдал, при размере чуть меньше 7 килобайт:
Вот всегда в таких сравнениях против JPEG для последнего берут самый плохой кодер, вместо лучших представителей. Противный маркетинг.
PaulZi, просьба исправить картинку с сравнением в статье на что-то более правдоподобное.
А вообще такие изображения шикарно жмутся и в PNG, с сохранением высокой чёткости. Вот, 7 килобайт:
Ждём AVIF. Может быть, он действительно покажет радикальное улучшение качества.PaulZi Автор
30.11.2018 14:33В png8 у меня меньше 13 kb не получалось, видимо опять какую-то магическую библиотечку применили)
MozJPEG не особо популярна, придётся компилить из сырцов чтобы потестить, тем не менее даже он выдал мыло-мыльное, это вино по тёмным дыркам. То что WebP лучше жмёт чем JPEG — это факт.VEG
30.11.2018 15:05Лучше, но не так сильно, как это показано. Суть в том, что сегодня MozJPEG показывает лучший результат для JPEG, сохраняя полную совместимость со всеми браузерами, и с ним и нужно сравнивать, оценивая необходимость внедрения WebP.
На самом деле, JPEG мог бы быть ещё лучше. В стандарт JPEG входит опциональная поддержка арифметического кодирования, которое позволило бы уменьшить объём конечных файлов без потерь. Однако, из-за того, что до ?2010 года на это были патенты — мало кто поддерживал эту фишку, и даже сейчас, когда все соответствующие патенты уже давно истекли, поддержки этой фичи до сих пор нет. То есть арифметическое кодирование хоть и является частью JPEG исходя из спецификации, де-факто это уже другой формат, так как практически ничего из существующего ПО это не поймёт. А ведь внедрение арифметического кодирования JPEG дало бы огромное преимущество перед WebP — можно было бы перекодировать старые JPEG в новые JPEG с арифметическим кодированием без потерь в качестве.
Попытки уговорить разработчиков браузеров поддержать арифметическое кодирование в JPEG пока что не увенчались успехом:
bugs.chromium.org/p/chromium/issues/detail?id=669501
wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/11369337-add-support-for-the-arithmetic-coded-jpeg-which-s
bugzilla.mozilla.org/show_bug.cgi?id=680385
Думаю, если проинформировать веб-разработчиков о такой возможности, собрать группу заинтересованных людей, можно было бы убедить разработчиков браузеров просто поддержать стандарт JPEG на 100%, но я не вижу большой заинтересованности в этом. Большинство файлов JPEG и PNG в интернете крайне не оптимизированы (то есть их можно было бы сделать в 2 и более раз меньше без видимых потерь в качестве), но это мало кого беспокоит, к сожалению. Сам факт что MozJPEG не используется массово, хоть и существует уже много лет, говорит о многом.
OtshelnikFm
30.11.2018 14:54
png 5.72 кб против вашего 6.88
WebP уже устарел
хм… кто-то его применяет на полном серьёзе? Я что-то упустилPaulZi Автор
30.11.2018 15:08Ны вы бы хоть написали, как изготовили подобный png, какими инструментами. Вообще речь об автоконверсии, то есть на входе есть png, нужно автоматически его сжать. Понятное дело если химичить над одним файлом можно впечатляющих результатов добиться.
OtshelnikFm
30.11.2018 17:38Пакетный оптимизатор FileOptimizer
Кидаешь пикчу/пачку нажимаешь старт. Всё. Я ничего не «химичил» сам. Ничего долго не настраивал — просто закинул файлы, получил результат. Это автоконверсия? Руками то я только файлы закидываю и старт жму.
Вот тут в 2013-м году о нем писали habr.com/post/168251PaulZi Автор
30.11.2018 18:26Для данной картинки, путём ужатия палитры до 48 цветов действительно получилось компактно. Но это частные случаи. С таким же успехом можно сохранить в gif с той же палитрой, будет тоже компактно, но это не значит что gif лучше webp. Понятное дело что для различного содержимого один формат может быть лучше чем другой, однако ко статье это имеет мало отношения, т. к. если речь пойдёт больше о фотографическом материале большого разрешения, там png врядли будет лучше. Тут больше речь о jpeg vs webp, да может конечно не всё так фатально как в картинке к статье, но даже mozjpeg не даёт такого же качества как как webp, это видно по чёткости границ.
OtshelnikFm
30.11.2018 18:34webp, не спорю хорош. Но тут его кто-то хоронит, но только после захвата веба:
WebP уже устарел
А поддержка браузерами еще слаба: caniuse.com/#feat=webp
Как так то?
И название заметки: «WebP скоро захватит веб»
С 2010-го захватывает и никак не захватит и вдруг: раз, и скоро захватил, и умер?
Поэтому я и не комментировал вашу заметку совсем по теме.
kirmorozov
29.11.2018 22:52+1Уже полгода перехватываю и Accept: image/webp и подменяю картинки на месте.
Никаких проблем и жизнь прекрасна, только Content-Type в ответе нужно указать image/webp.
И никаких правок в html, забыли про пункт «оптимизируй картинки» совсем.Alexufo
30.11.2018 01:17вы перехватываете юзерагент а потом решаете подменить стандартный ответ в test.jpg на на test.jpg (который по факту webp но переименованый в jpg ) с правильным Content-Type?
kirmorozov
30.11.2018 03:48Не глядя на User-Agent, просто по Accept заголовку, по факту оказывается вполне достаточно.
Браузеру важен какой Content-Type, он доступен по ссылке *.png или *.jpg значения не имеет.
И не тратит такие ценные миллисекунды на обработку html.Alexufo
30.11.2018 04:13>по факту оказывается вполне достаточно.
Достаточно, чтобы не париться с браузерами не поддерживающими webp? Не догоняю.
Accept скажет что это запрос на картинку, но только юзерагент о том, поддерживает ли клиет webp. Сам подход отличный.khim
30.11.2018 04:25+1Все браузеры с поддержкой webp явно его указывают наряду с */*
Именно чтобы User-Agent не трогать
t_kanstantsin
30.11.2018 09:27https://alexey.detr.us/en/posts/2018/2018-08-20-webp-nginx-with-fallback/
Брузер отправляет в заголовках, какие форматы он принимает. Если там есть webp, то можно вместо запрошенного jpg/png отправлять webp, только дополнительно нужно указать в заголовках, что это webp.
Так же, браузер отправляет в заголовках, например, поддерживаемые форматы сжатия (архивировния): "gzip, deflate, br", чтобы сервер мог сжимать отдаваемый контент наиболее эффективным способом. Например, gzip не всеми браузерами поддерживается и сервер может выбрать формат сжатия.domix32
30.11.2018 13:02gzip-то считай что всеми поддерживается (у пользователей IE размер ресурсов точно не самая большая проблема), а вот какой-нибудь brotli к сожалению не многими.
blind_oracle
30.11.2018 15:28brotli уже пару лет как поддерживается всеми основными браузерами (считаю IE == Edge в данном случае). Даже если бы он поддерживался только Хромом, то это уже 50%+ пользователей.
tuxi
01.12.2018 00:24Спорное решение имхо. Например ajax запрос часто отдает Accept вида "*/*"
Так что, все равно придется в сессию писать признак для webp.kirmorozov
01.12.2018 00:47Если все запросы за картинками идут простыми GET запросами.
Простой запрос GET, простой ответ, в зависимости от заголовка.
Хром и все приличные браузеры добавляют заголовок Accept:… image/webp…
Что сомнительного если браузер получит ответ с заголовком Content-Type: image/webp и WebP картинкой внутри?t_kanstantsin
01.12.2018 01:47Тоже не понимаю, что спорного — кто может смотреть webp — пусть смотрит, не можешь — на старый формат. И все довольны
tuxi
01.12.2018 02:09То есть расширение у картинок не указывается?
khim
01.12.2018 03:00Обычно указывается, но оно ни разу не обязано совпадать с тем, в каком формате картинка, на самом деле, отдаётся.
tuxi
01.12.2018 13:03Технически «так тоже можно», но это достаточно плохая практика на мой взгляд.
khim
01.12.2018 17:15Это повсеместная практика. Точной статистики я не вёл (может у кого-то она и есть), но видел на массе сайтов PNG, лежащие в файлах с расширением .jpg и наоборот.
Добавление сюда ещё и webp принципиально ничего не изменит.
faiwer
01.12.2018 07:34Расширение в URL это условность. По сути в URL вы можете увидеть что-нибудь напоминающее путь по файловой системе или просто имя файла. По факту это всего лишь условности, удобства для. Нет никакой необходимости для
/some.pngуказывать возвращатьpng-файл. Можно вернуть всё что угодно, даже не картинку вовсе. URL это просто строка, адрес. Любой смысл её частям мы придаём сами в своей голове и, скажем, в nginx-конфиге. Правда если запрос сделан из недр<img/>то надеяться, что она пережуёт какой-нибудь HTML, конечно, нет :)khim
01.12.2018 17:16надеяться, что она пережуёт какой-нибудь HTML, конечно, нет
Да легко. Только нужно его вставить в SVG.
bolk
01.12.2018 08:14Как часто в аяксом запрашиваете картинку?
tuxi
01.12.2018 12:58Список адресов картинок отдается часто. Если соблюдать правила хорошего тона «один URL однозначно определяет один ресурс», то расширение у image должно быть и тогда это проблема.
bolk
01.12.2018 13:27Текстовая часть после последней точки никакое не расширение и может быть какая угодно. Так что напишите там, что хочется, а формат выдавайте по заголовку запроса от браузера.
tuxi
01.12.2018 15:47В данной ситуации, вопрос в том, что при uri
http://abc.com/foo/abc.jpgиhttp://abc.com/foo/abc.webp— есть явное указание, что это разные ресурсы, а в случае сhttp://abc.com/foo/abcбез обработки заголовка accept — это один и тот же ресурс.
Это может выйти боком не только в SEO, но и даже при банальном использовании стандартного механизма кеширования, например в том же nginx согласно документации
proxy_cache_key строка;
Умолчание: proxy_cache_key $scheme$proxy_host$request_uri;
.....
и если забыть переопределить такой ключ, можно получить кучу веселых часов в поисках проблемыbolk
01.12.2018 16:34Вы выдумали проблему, её не существует.
Во-первых, URL и URI вещи разные.
Во-вторых, нигде не гарантируется и не подразумевается, что в общем случае на одном урле всегда живёт один и тот же набор информации. Попробуйте зайти два раза на «Хабр» с разницей в час, например.
В-третьих, есть ряд заголовков, управляющих кешированием, в данном случае полезен будет «Vary»
mobi
01.12.2018 14:22Content negotiation — это часть HTTP, так что тут всё в соответствии со стандартом.
enabokov
30.11.2018 23:16До тех пор пока webp (любой другой новый формат) не поддерживается Apple, ситуация не изменится.
enabokov
30.11.2018 23:21До тех пор пока webp (любой другой новый формат) не поддерживается Apple, ситуация не изменится.
t_kanstantsin
01.12.2018 01:45И какая доля браузеров приходится на Apple? Судя по caniuse — всего 13,35%. Ну раз эти 13% не в состоянии скачать webp и получить картинку лучше качества и меньшего размера, то и остальным нельзя пользоваться этим форматом? Особенно учитывая то, что webp отдаётся с fallback на обычный jpg/png — т.е. увидят все, но владельцы техники apple — чуть позже:)
enabokov
01.12.2018 02:14Это большая доля. Если же взять долю среди мобильных браузеров в США, то будет >50%. Никто в своём уме не будет отсекать ни 13%, ни тем более 50%, тем более самую платежеспособную. Отдавать таким jpeg? Тогда нужно перекодировать в jpeg. Перекодирование с потерей только ухудшает качество. Если уменьшать степень сжатия, то теряем выигрыш в размере. В png? Большая вероятность, что размер также увеличится.
Пользователь вообще не увидит разницы в качестве картинки, всё это делается для уменьшения размера при сохранении того же качества. А если размер не меняется, или даже увеличивается, то зачем всё это нужно — непонятно.khim
01.12.2018 03:03А если размер не меняется, или даже увеличивается, то зачем всё это нужно — непонятно.
Размер уменьшается для 90% посетителей, а увеличивается для 10%. Счета за траффик для web-сайта уменьшаются, а «платежеспособная часть» может за это платить, если хочет — на то она и «платежеспособная».
t_kanstantsin
01.12.2018 10:51Что-то не понимаю, откуда взялось отверджение, что кто-то собирается "отсекать ни 13%"? Если браузер поддерживает webp — вернётся webp, если не поддерживает — fallback до jpg или png. Никто не отдаёт пользователям apple —
no-photo.jpg
И никто не конвертит из маленькой webp маленькую jpg — всё генерится из исходной, а в этом случае webp на 25-30% меньше.
FreeCX
Жаль что BPG не взлетел, но будет интересно его сравнить с AVIF, когда последний выйдет.
Alexufo
Но не взлетел же из-за тех же проблем с лицензией
VEG
BPG — это тот же HEIF, просто в другом контейнере.