WebP скоро захватит веб, но век будет не долгим


    Стандарт кодирования изображений 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 для изображений выглядит вполне хорошей альтернативой.


    Смотреть поддержку WebP на CanIUse

    Поделиться публикацией
    Комментарии 70
      +1
      Жаль что BPG не взлетел, но будет интересно его сравнить с AVIF, когда последний выйдет.
        +1
        Но не взлетел же из-за тех же проблем с лицензией
          +3
          BPG — это тот же HEIF, просто в другом контейнере.
          +7

          Устарел не устарел, но результаты перехода на webp впечатляют. Вот буквально вчера допилили сервер который на лету трансформирует jpg в webp, сегодня грубую оценку проводили на стенде с копией прода. Минимум!!! -25%, а в среднем под 30..35% уменьшение трафика, плюс оптимизация хром-движка под декодинг webp впечатляет

            0
            То есть пользователь вам загружает jpg, а вы его конвертируете и храните в webp?
              +5

              Если грубо то да. На деле у нас свой cdn которому можно сказать "дай картинку с шириной 200", или дай jpg вместо этого png. И куча слоев кешерования, так как больше 50% медиа — это сгенеренные картинки на базе 2...3..4 других. И вот сейчас можно сказать cdn-у "а дай ка братец мне вот такой webp!".
              Ну и ессно выходной html поток пока что фильтруется подменой .jpg на .webp если в accept у клиента указана поддержка webp

            0
            Мне кажется, что webp сможет взлететь только когда любой графический просмотрщик его будет понимать. А каждый фоторедактор сможет сохранять в webp. К слову в GIMP добавили поддержку webp считанные месяцы назад. :(
              0
              Тут такой процесс взаимосвязанный. Начнут повсеместно внедрять в веб, добавят в просмотрщики, а там уже и через пару лет и железо подтянется. Другой вопрос что учитывая активную разработку другого формата всеми участниками альянса, а не только гуглом, скорее всего webp так и останется внутри веба.
                +3
                Не всегда это работает. Например, тот же вездесущий SVG до сих пор просмотрщиками не поддерживается, а для отображения миниатюр в Windows приходится использовать сторонний svg-explorer-extension, работу которого сложно назвать идеальной (особенно, если используется clipping mask).
              +1

              Заголовок чистой воды кликбейт. Никакой конкретики — кто разрабатывает новый формат, на какой стадии разработка, какие приложения поддерживают его, примеры использования нового формата.
              Я может тоже разрабатываю "свой" формат — так что avif уже устарел.


              Во-вторых, в активной разработке формат AVIF, который гораздо современнее, чем WebP.

              И когда появится поддежка конвертации в этот формат? Когда он станет доступным повсеместно в браузерах?
              Не будет ли Firefox (или любой другой браузер) так же тянуть с вводом поддержки этого формата?
              А когда наконец новый формат будет поддерживаться хотя бы 70% браузеров (как сейчас), не появится ли новый "прорывной" формат, которые на момент написания очередной статьи о нём будет "в активной разработке"?

                +3
                Ситуация с продвижением WebP и Avif кардинально разная. Если WebP двигал по сути только гугл, не имея поддержки ни со стороны других браузеров, ни со стороны производителей железа. Тут ситуация диаметрально противоположная.
                Кто разрабатывает — указано в статье. Есть сайт альянса, где есть вся информация по участникам и роадмапам.
                Тестовая поддержка видео av1 уже есть в firefox и chrome. Так же есть большие обещания со стороны других участников и сервисов внедрить новый формат после фиксации.
                  +1
                  70% мало зависит от Firefox и любого другого бразуера, потому что 62% из этих 72% — это хром и… мобильный хром. То есть захочет гугл — будет 70, не захочет — не будет.
                    0
                    Этим летом был зафиксирован формат bitstream в AV1, с этого момента производителям SoC нужно примерно 1.5-2 года, чтобы реализовать декодер в кремнии, после этого можно будет аккуратно начинать внедрять на практике. Представители netflix говорят, что они будут пробовать раньше, декодируя софтово, но только на низких разрешениях — чтобы сэкономить битрейт у пользователей с очень плохим интернетом.

                    AV1 в хроме конечно же будет, потому что это в том числе и гугловая разработка, и в youtube обязательно будет использоваться.
                    +6
                    Картинка врёт, не даёт JPEG таких жутких артефактов. В 7 кб сжимается примерно так:
                    image
                      +4
                      К сожалению реальный пример, тут есть исходники.
                      Такой jpeg выдают множество библиотек, в частности данный пример выдал jpegoptim:
                      jpegoptim -q --max=85 --strip-all file.jpg
                      По опыту JPEG очень не любит красные однородные цвета.
                      Photoshop я знаю лучше справляется с кодированием jpeg, но его в автоматическом режиме к сайту сложновато подцепить.
                        +1
                        Такой jpeg выдают множество библиотек,
                        Значит, не надо использовать такие библиотеки.
                          +3
                          Посоветуйте что, чтобы на сайте можно было автоматически сохранять. ImageMagick и jpegoptim — не катят.
                        +1
                        Таки артефакты JPEG на монотонном красном фоне издавна были жизненым мемом.
                          +1
                          MozJPEG даже лучше результат выдал, при размере чуть меньше 7 килобайт:


                          Вот всегда в таких сравнениях против JPEG для последнего берут самый плохой кодер, вместо лучших представителей. Противный маркетинг.

                          PaulZi, просьба исправить картинку с сравнением в статье на что-то более правдоподобное.

                          А вообще такие изображения шикарно жмутся и в PNG, с сохранением высокой чёткости. Вот, 7 килобайт:


                          Ждём AVIF. Может быть, он действительно покажет радикальное улучшение качества.
                            0
                            В png8 у меня меньше 13 kb не получалось, видимо опять какую-то магическую библиотечку применили)
                            MozJPEG не особо популярна, придётся компилить из сырцов чтобы потестить, тем не менее даже он выдал мыло-мыльное, это вино по тёмным дыркам. То что WebP лучше жмёт чем JPEG — это факт.
                              +1
                              Лучше, но не так сильно, как это показано. Суть в том, что сегодня 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 не используется массово, хоть и существует уже много лет, говорит о многом.
                                0
                                для 7 кб нужно 64 цвета. Поскольку тут только красный и белый — хватает.
                                  +1
                                  В том то и дело, что это уже начинается предобработка. Так можно и шумы убирать, чтобы лучше сжималось.
                                  0
                                  у mozjpeg можно просто сделать rpm:

                                  autoreconf -fiv
                                  ./configure
                                  make rpm
                                  –1

                                  png 5.72 кб против вашего 6.88

                                  WebP уже устарел

                                  хм… кто-то его применяет на полном серьёзе? Я что-то упустил
                                    0
                                    Ны вы бы хоть написали, как изготовили подобный png, какими инструментами. Вообще речь об автоконверсии, то есть на входе есть png, нужно автоматически его сжать. Понятное дело если химичить над одним файлом можно впечатляющих результатов добиться.
                                      +3
                                      Пакетный оптимизатор FileOptimizer
                                      Кидаешь пикчу/пачку нажимаешь старт. Всё. Я ничего не «химичил» сам. Ничего долго не настраивал — просто закинул файлы, получил результат. Это автоконверсия? Руками то я только файлы закидываю и старт жму.
                                      Вот тут в 2013-м году о нем писали habr.com/post/168251
                                        0
                                        Для данной картинки, путём ужатия палитры до 48 цветов действительно получилось компактно. Но это частные случаи. С таким же успехом можно сохранить в gif с той же палитрой, будет тоже компактно, но это не значит что gif лучше webp. Понятное дело что для различного содержимого один формат может быть лучше чем другой, однако ко статье это имеет мало отношения, т. к. если речь пойдёт больше о фотографическом материале большого разрешения, там png врядли будет лучше. Тут больше речь о jpeg vs webp, да может конечно не всё так фатально как в картинке к статье, но даже mozjpeg не даёт такого же качества как как webp, это видно по чёткости границ.
                                          0
                                          webp, не спорю хорош. Но тут его кто-то хоронит, но только после захвата веба:
                                          WebP уже устарел

                                          А поддержка браузерами еще слаба: caniuse.com/#feat=webp
                                          Как так то?
                                          И название заметки: «WebP скоро захватит веб»
                                          С 2010-го захватывает и никак не захватит и вдруг: раз, и скоро захватил, и умер?

                                          Поэтому я и не комментировал вашу заметку совсем по теме.
                                +3
                                Уже полгода перехватываю и Accept: image/webp и подменяю картинки на месте.
                                Никаких проблем и жизнь прекрасна, только Content-Type в ответе нужно указать image/webp.
                                И никаких правок в html, забыли про пункт «оптимизируй картинки» совсем.
                                  0
                                  вы перехватываете юзерагент а потом решаете подменить стандартный ответ в test.jpg на на test.jpg (который по факту webp но переименованый в jpg ) с правильным Content-Type?
                                    +2
                                    Не глядя на User-Agent, просто по Accept заголовку, по факту оказывается вполне достаточно.
                                    Браузеру важен какой Content-Type, он доступен по ссылке *.png или *.jpg значения не имеет.
                                    И не тратит такие ценные миллисекунды на обработку html.
                                      0
                                      >по факту оказывается вполне достаточно.
                                      Достаточно, чтобы не париться с браузерами не поддерживающими webp? Не догоняю.
                                      Accept скажет что это запрос на картинку, но только юзерагент о том, поддерживает ли клиет webp. Сам подход отличный.
                                        +2
                                        Все браузеры с поддержкой webp явно его указывают наряду с */*

                                        Именно чтобы User-Agent не трогать
                                          +2

                                          https://alexey.detr.us/en/posts/2018/2018-08-20-webp-nginx-with-fallback/


                                          Брузер отправляет в заголовках, какие форматы он принимает. Если там есть webp, то можно вместо запрошенного jpg/png отправлять webp, только дополнительно нужно указать в заголовках, что это webp.
                                          Так же, браузер отправляет в заголовках, например, поддерживаемые форматы сжатия (архивировния): "gzip, deflate, br", чтобы сервер мог сжимать отдаваемый контент наиболее эффективным способом. Например, gzip не всеми браузерами поддерживается и сервер может выбрать формат сжатия.

                                            0
                                            gzip-то считай что всеми поддерживается (у пользователей IE размер ресурсов точно не самая большая проблема), а вот какой-нибудь brotli к сожалению не многими.
                                              +1
                                              brotli уже пару лет как поддерживается всеми основными браузерами (считаю IE == Edge в данном случае). Даже если бы он поддерживался только Хромом, то это уже 50%+ пользователей.
                                              0
                                              (ваша ссылочка «не всеми» ведёт не на gzip, а на brotli, если что)
                                          0
                                          Окончание «.jpg» не имеет никакого значения. Браузеры не могут и не должны на него ориентироваться. Формат указывается в Content-type и только там.
                                            0
                                            да это ясно, ясно)
                                          0
                                          Спорное решение имхо. Например ajax запрос часто отдает Accept вида "*/*"
                                          Так что, все равно придется в сессию писать признак для webp.
                                            0
                                            Если все запросы за картинками идут простыми GET запросами.
                                            Простой запрос GET, простой ответ, в зависимости от заголовка.
                                            Хром и все приличные браузеры добавляют заголовок Accept:… image/webp…
                                            Что сомнительного если браузер получит ответ с заголовком Content-Type: image/webp и WebP картинкой внутри?
                                              0

                                              Тоже не понимаю, что спорного — кто может смотреть webp — пусть смотрит, не можешь — на старый формат. И все довольны

                                                0
                                                То есть расширение у картинок не указывается?
                                                  0
                                                  Обычно указывается, но оно ни разу не обязано совпадать с тем, в каком формате картинка, на самом деле, отдаётся.
                                                    –1
                                                    Технически «так тоже можно», но это достаточно плохая практика на мой взгляд.
                                                      0
                                                      Это повсеместная практика. Точной статистики я не вёл (может у кого-то она и есть), но видел на массе сайтов PNG, лежащие в файлах с расширением .jpg и наоборот.

                                                      Добавление сюда ещё и webp принципиально ничего не изменит.
                                                    0

                                                    Расширение в URL это условность. По сути в URL вы можете увидеть что-нибудь напоминающее путь по файловой системе или просто имя файла. По факту это всего лишь условности, удобства для. Нет никакой необходимости для /some.png указывать возвращать png-файл. Можно вернуть всё что угодно, даже не картинку вовсе. URL это просто строка, адрес. Любой смысл её частям мы придаём сами в своей голове и, скажем, в nginx-конфиге. Правда если запрос сделан из недр <img/> то надеяться, что она пережуёт какой-нибудь HTML, конечно, нет :)

                                                      0
                                                      надеяться, что она пережуёт какой-нибудь HTML, конечно, нет
                                                      Да легко. Только нужно его вставить в SVG.
                                                  0
                                                  Как часто в аяксом запрашиваете картинку?
                                                    0
                                                    Список адресов картинок отдается часто. Если соблюдать правила хорошего тона «один URL однозначно определяет один ресурс», то расширение у image должно быть и тогда это проблема.
                                                      +1
                                                      Текстовая часть после последней точки никакое не расширение и может быть какая угодно. Так что напишите там, что хочется, а формат выдавайте по заголовку запроса от браузера.
                                                        0
                                                        В данной ситуации, вопрос в том, что при 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;
                                                        .....

                                                        и если забыть переопределить такой ключ, можно получить кучу веселых часов в поисках проблемы
                                                          0
                                                          Вы выдумали проблему, её не существует.

                                                          Во-первых, URL и URI вещи разные.
                                                          Во-вторых, нигде не гарантируется и не подразумевается, что в общем случае на одном урле всегда живёт один и тот же набор информации. Попробуйте зайти два раза на «Хабр» с разницей в час, например.
                                                          В-третьих, есть ряд заголовков, управляющих кешированием, в данном случае полезен будет «Vary»
                                                            0
                                                            Попробуйте зайти два раза на «Хабр» с разницей в час, например.

                                                            Это плохая аналогия, надеюсь сами понимаете почему.
                                                              0
                                                              Никогда так не пишите, я тоже так умею: это прекрасная аналогия, надеюсь вы сумеет понять почему.

                                                              Если вас не устраивает такой пример, то представьте, что вы зашли тремя браузерами: один поддерживает сжатие gzip, второй brotli, а третий не поддерживает никакого.
                                                                0
                                                                Во-первых, указывать другому участнику дискуссии, что ему делать, а что нет — это еще более худшие манеры.

                                                                Во-вторых, в случае с Хабром, он отдает явные директивы no-cache, поэтому разный контент, при одном и том же контент-тайпе, но в разное время — это как раз нормально.

                                                                Речь шла о том, что если мы на запрос одного и того же url отдаем разный контент-тайп, то придется об этом помнить и выставлять заголовки для кэширующих прокси, одновременно решая вопрос: какой именно контент-тайп мы будем отдавать при заголовке в реквесте accept "*/*"

                                                                И все это, замечу, взамен простого и явного разделения на jpg/png и webp в адресе url, которое не требует практически никаких лишних телодвижений и надежно как молоток
                                                                  0
                                                                  Ну давайте ещё манерами будем меряться.

                                                                  Нет ничего страшного в том, чтобы отдавать разный content-type на один урл. Ровно для этой цели этот заголовок и придуман — чтобы браузер сообщал что он по этому урлу может принять.
                                                                    0
                                                                    Коллега, мы (все IT) решаем одну единственную задачу, но разными способами.
                                                                    Уменьшить затраты времени для человека. Точное выражение которой:
                                                                    T = посетители*(время загрузки)+(время сжатия)+(время интеграции решения)
                                                                    Если использовать ваш «молоток», то время интеграции решения с обработкой всех ссылок на картинки и его поддержка может обойтись дороже, чем «топор» обработки Accept.
                                                                    Я просто вкрутил это дело в свое время за часов 20 от идеи до боевого.
                                                                    Pagespeed, который работает как ваш молоток, жрет немало памяти и медленней отдает html из-за отсутствующей картинки. Использовал сам.

                                                          0
                                                          Content negotiation — это часть HTTP, так что тут всё в соответствии со стандартом.
                                                      0
                                                      забыли про пункт «оптимизируй картинки» совсем.

                                                      вам лучи ненависти от пользователей не-хромированных браузеров.
                                                        0
                                                        Не все так печально, все картинки оптимизируются по запросу на месте.
                                                        Так даже pagespeed умеет, рекомендую для начала.
                                                          0
                                                          Согласитесь, между «забыли совсем» и «оптимизируются на месте» есть некоторая разница, вам не кажется?
                                                            0
                                                            Ты прав, я забыл настолько, что даже написать забыл. :)
                                                      –1

                                                      До тех пор пока webp (любой другой новый формат) не поддерживается Apple, ситуация не изменится.

                                                        –1

                                                        До тех пор пока webp (любой другой новый формат) не поддерживается Apple, ситуация не изменится.

                                                          +1

                                                          И какая доля браузеров приходится на Apple? Судя по caniuse — всего 13,35%. Ну раз эти 13% не в состоянии скачать webp и получить картинку лучше качества и меньшего размера, то и остальным нельзя пользоваться этим форматом? Особенно учитывая то, что webp отдаётся с fallback на обычный jpg/png — т.е. увидят все, но владельцы техники apple — чуть позже:)

                                                            +1
                                                            Это большая доля. Если же взять долю среди мобильных браузеров в США, то будет >50%. Никто в своём уме не будет отсекать ни 13%, ни тем более 50%, тем более самую платежеспособную. Отдавать таким jpeg? Тогда нужно перекодировать в jpeg. Перекодирование с потерей только ухудшает качество. Если уменьшать степень сжатия, то теряем выигрыш в размере. В png? Большая вероятность, что размер также увеличится.
                                                            Пользователь вообще не увидит разницы в качестве картинки, всё это делается для уменьшения размера при сохранении того же качества. А если размер не меняется, или даже увеличивается, то зачем всё это нужно — непонятно.
                                                              0
                                                              А если размер не меняется, или даже увеличивается, то зачем всё это нужно — непонятно.
                                                              Размер уменьшается для 90% посетителей, а увеличивается для 10%. Счета за траффик для web-сайта уменьшаются, а «платежеспособная часть» может за это платить, если хочет — на то она и «платежеспособная».
                                                                +2

                                                                Что-то не понимаю, откуда взялось отверджение, что кто-то собирается "отсекать ни 13%"? Если браузер поддерживает webp — вернётся webp, если не поддерживает — fallback до jpg или png. Никто не отдаёт пользователям apple — no-photo.jpg
                                                                И никто не конвертит из маленькой webp маленькую jpg — всё генерится из исходной, а в этом случае webp на 25-30% меньше.

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

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