Comments 74
Жаль что BPG не взлетел, но будет интересно его сравнить с AVIF, когда последний выйдет.
Устарел не устарел, но результаты перехода на webp впечатляют. Вот буквально вчера допилили сервер который на лету трансформирует jpg в webp, сегодня грубую оценку проводили на стенде с копией прода. Минимум!!! -25%, а в среднем под 30..35% уменьшение трафика, плюс оптимизация хром-движка под декодинг webp впечатляет
То есть пользователь вам загружает jpg, а вы его конвертируете и храните в webp?
Если грубо то да. На деле у нас свой cdn которому можно сказать "дай картинку с шириной 200", или дай jpg вместо этого png. И куча слоев кешерования, так как больше 50% медиа — это сгенеренные картинки на базе 2...3..4 других. И вот сейчас можно сказать cdn-у "а дай ка братец мне вот такой webp!".
Ну и ессно выходной html поток пока что фильтруется подменой .jpg на .webp если в accept у клиента указана поддержка webp
Мне кажется, что webp сможет взлететь только когда любой графический просмотрщик его будет понимать. А каждый фоторедактор сможет сохранять в webp. К слову в GIMP добавили поддержку webp считанные месяцы назад. :(
Тут такой процесс взаимосвязанный. Начнут повсеместно внедрять в веб, добавят в просмотрщики, а там уже и через пару лет и железо подтянется. Другой вопрос что учитывая активную разработку другого формата всеми участниками альянса, а не только гуглом, скорее всего webp так и останется внутри веба.
Не всегда это работает. Например, тот же вездесущий SVG до сих пор просмотрщиками не поддерживается, а для отображения миниатюр в Windows приходится использовать сторонний svg-explorer-extension, работу которого сложно назвать идеальной (особенно, если используется clipping mask).
Svg очень тяжело поддержать, для этого нужно встроить в просмотрщик движок от браузера или сам браузер. Возможно, можно попытаться написать свой движок, но это, во-первых, непростая задача, а во-вторых, вряд ли он будет корректно отображать 100% документов.
В общем проблема в том, что, во-первых, тут используется векторная графика, а не растровая, а во-вторых, svg-формат имеет много фич, которые для браузера не являются сложными, т. к. уже итак реализованы в нём, а для небольшого приложения реализовать всё это сложно. Но, думаю, и не предполагалось, что его кто-то будет поддерживать, это чисто формат для веба и браузера. Даже графические редакторы могут обойтись экспортом в svg.
В общем проблема в том, что, во-первых, тут используется векторная графика, а не растровая, а во-вторых, svg-формат имеет много фич, которые для браузера не являются сложными, т. к. уже итак реализованы в нём, а для небольшого приложения реализовать всё это сложно. Но, думаю, и не предполагалось, что его кто-то будет поддерживать, это чисто формат для веба и браузера. Даже графические редакторы могут обойтись экспортом в svg.
Наоборот — изначально SVG был реализован в плагине и никакого отношения к кишкам браузера не имел.
Есть хорошие новости. XnViewMP (именно версия с MP на конце) научилась работать с SVG, причем работает очень хорошо (гораздо лучше svg-explorer-extension). Правда по умолчанию миниатюры для SVG не строятся почему-то. Tools → Settings → File list → Custom filter. И или в строке Exclude снимаем галочки, или в этой же строке Exclude убираем формат SVG. После этого видим миниатюры всех SVG файлов.
Заголовок чистой воды кликбейт. Никакой конкретики — кто разрабатывает новый формат, на какой стадии разработка, какие приложения поддерживают его, примеры использования нового формата.
Я может тоже разрабатываю "свой" формат — так что avif уже устарел.
Во-вторых, в активной разработке формат AVIF, который гораздо современнее, чем WebP.
И когда появится поддежка конвертации в этот формат? Когда он станет доступным повсеместно в браузерах?
Не будет ли Firefox (или любой другой браузер) так же тянуть с вводом поддержки этого формата?
А когда наконец новый формат будет поддерживаться хотя бы 70% браузеров (как сейчас), не появится ли новый "прорывной" формат, которые на момент написания очередной статьи о нём будет "в активной разработке"?
Ситуация с продвижением WebP и Avif кардинально разная. Если WebP двигал по сути только гугл, не имея поддержки ни со стороны других браузеров, ни со стороны производителей железа. Тут ситуация диаметрально противоположная.
Кто разрабатывает — указано в статье. Есть сайт альянса, где есть вся информация по участникам и роадмапам.
Тестовая поддержка видео av1 уже есть в firefox и chrome. Так же есть большие обещания со стороны других участников и сервисов внедрить новый формат после фиксации.
Кто разрабатывает — указано в статье. Есть сайт альянса, где есть вся информация по участникам и роадмапам.
Тестовая поддержка видео av1 уже есть в firefox и chrome. Так же есть большие обещания со стороны других участников и сервисов внедрить новый формат после фиксации.
70% мало зависит от Firefox и любого другого бразуера, потому что 62% из этих 72% — это хром и… мобильный хром. То есть захочет гугл — будет 70, не захочет — не будет.
Этим летом был зафиксирован формат bitstream в AV1, с этого момента производителям SoC нужно примерно 1.5-2 года, чтобы реализовать декодер в кремнии, после этого можно будет аккуратно начинать внедрять на практике. Представители netflix говорят, что они будут пробовать раньше, декодируя софтово, но только на низких разрешениях — чтобы сэкономить битрейт у пользователей с очень плохим интернетом.
AV1 в хроме конечно же будет, потому что это в том числе и гугловая разработка, и в youtube обязательно будет использоваться.
AV1 в хроме конечно же будет, потому что это в том числе и гугловая разработка, и в youtube обязательно будет использоваться.
Картинка врёт, не даёт JPEG таких жутких артефактов. В 7 кб сжимается примерно так:
К сожалению реальный пример, тут есть исходники.
Такой jpeg выдают множество библиотек, в частности данный пример выдал jpegoptim:
По опыту JPEG очень не любит красные однородные цвета.
Photoshop я знаю лучше справляется с кодированием jpeg, но его в автоматическом режиме к сайту сложновато подцепить.
Такой jpeg выдают множество библиотек, в частности данный пример выдал jpegoptim:
jpegoptim -q --max=85 --strip-all file.jpgПо опыту JPEG очень не любит красные однородные цвета.
Photoshop я знаю лучше справляется с кодированием jpeg, но его в автоматическом режиме к сайту сложновато подцепить.
Таки артефакты JPEG на монотонном красном фоне издавна были жизненым мемом.
MozJPEG даже лучше результат выдал, при размере чуть меньше 7 килобайт:
Вот всегда в таких сравнениях против JPEG для последнего берут самый плохой кодер, вместо лучших представителей. Противный маркетинг.
PaulZi, просьба исправить картинку с сравнением в статье на что-то более правдоподобное.
А вообще такие изображения шикарно жмутся и в PNG, с сохранением высокой чёткости. Вот, 7 килобайт:
Ждём AVIF. Может быть, он действительно покажет радикальное улучшение качества.
Вот всегда в таких сравнениях против JPEG для последнего берут самый плохой кодер, вместо лучших представителей. Противный маркетинг.
PaulZi, просьба исправить картинку с сравнением в статье на что-то более правдоподобное.
А вообще такие изображения шикарно жмутся и в PNG, с сохранением высокой чёткости. Вот, 7 килобайт:
Ждём AVIF. Может быть, он действительно покажет радикальное улучшение качества.
В png8 у меня меньше 13 kb не получалось, видимо опять какую-то магическую библиотечку применили)
MozJPEG не особо популярна, придётся компилить из сырцов чтобы потестить, тем не менее даже он выдал мыло-мыльное, это вино по тёмным дыркам. То что WebP лучше жмёт чем JPEG — это факт.
MozJPEG не особо популярна, придётся компилить из сырцов чтобы потестить, тем не менее даже он выдал мыло-мыльное, это вино по тёмным дыркам. То что WebP лучше жмёт чем JPEG — это факт.
Лучше, но не так сильно, как это показано. Суть в том, что сегодня 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 не используется массово, хоть и существует уже много лет, говорит о многом.
На самом деле, 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 не используется массово, хоть и существует уже много лет, говорит о многом.
для 7 кб нужно 64 цвета. Поскольку тут только красный и белый — хватает.
у mozjpeg можно просто сделать rpm:
autoreconf -fiv
./configure
make rpm
png 5.72 кб против вашего 6.88
WebP уже устарел
хм… кто-то его применяет на полном серьёзе? Я что-то упустил
Ны вы бы хоть написали, как изготовили подобный png, какими инструментами. Вообще речь об автоконверсии, то есть на входе есть png, нужно автоматически его сжать. Понятное дело если химичить над одним файлом можно впечатляющих результатов добиться.
Пакетный оптимизатор FileOptimizer
Кидаешь пикчу/пачку нажимаешь старт. Всё. Я ничего не «химичил» сам. Ничего долго не настраивал — просто закинул файлы, получил результат. Это автоконверсия? Руками то я только файлы закидываю и старт жму.
Вот тут в 2013-м году о нем писали habr.com/post/168251
Кидаешь пикчу/пачку нажимаешь старт. Всё. Я ничего не «химичил» сам. Ничего долго не настраивал — просто закинул файлы, получил результат. Это автоконверсия? Руками то я только файлы закидываю и старт жму.
Вот тут в 2013-м году о нем писали habr.com/post/168251
Для данной картинки, путём ужатия палитры до 48 цветов действительно получилось компактно. Но это частные случаи. С таким же успехом можно сохранить в gif с той же палитрой, будет тоже компактно, но это не значит что gif лучше webp. Понятное дело что для различного содержимого один формат может быть лучше чем другой, однако ко статье это имеет мало отношения, т. к. если речь пойдёт больше о фотографическом материале большого разрешения, там png врядли будет лучше. Тут больше речь о jpeg vs webp, да может конечно не всё так фатально как в картинке к статье, но даже mozjpeg не даёт такого же качества как как webp, это видно по чёткости границ.
webp, не спорю хорош. Но тут его кто-то хоронит, но только после захвата веба:
А поддержка браузерами еще слаба: caniuse.com/#feat=webp
Как так то?
И название заметки: «WebP скоро захватит веб»
С 2010-го захватывает и никак не захватит и вдруг: раз, и скоро захватил, и умер?
Поэтому я и не комментировал вашу заметку совсем по теме.
WebP уже устарел
А поддержка браузерами еще слаба: caniuse.com/#feat=webp
Как так то?
И название заметки: «WebP скоро захватит веб»
С 2010-го захватывает и никак не захватит и вдруг: раз, и скоро захватил, и умер?
Поэтому я и не комментировал вашу заметку совсем по теме.
Уже полгода перехватываю и Accept: image/webp и подменяю картинки на месте.
Никаких проблем и жизнь прекрасна, только Content-Type в ответе нужно указать image/webp.
И никаких правок в html, забыли про пункт «оптимизируй картинки» совсем.
Никаких проблем и жизнь прекрасна, только Content-Type в ответе нужно указать image/webp.
И никаких правок в html, забыли про пункт «оптимизируй картинки» совсем.
вы перехватываете юзерагент а потом решаете подменить стандартный ответ в test.jpg на на test.jpg (который по факту webp но переименованый в jpg ) с правильным Content-Type?
Не глядя на User-Agent, просто по Accept заголовку, по факту оказывается вполне достаточно.
Браузеру важен какой Content-Type, он доступен по ссылке *.png или *.jpg значения не имеет.
И не тратит такие ценные миллисекунды на обработку html.
Браузеру важен какой Content-Type, он доступен по ссылке *.png или *.jpg значения не имеет.
И не тратит такие ценные миллисекунды на обработку html.
>по факту оказывается вполне достаточно.
Достаточно, чтобы не париться с браузерами не поддерживающими webp? Не догоняю.
Accept скажет что это запрос на картинку, но только юзерагент о том, поддерживает ли клиет webp. Сам подход отличный.
Достаточно, чтобы не париться с браузерами не поддерживающими webp? Не догоняю.
Accept скажет что это запрос на картинку, но только юзерагент о том, поддерживает ли клиет webp. Сам подход отличный.
Все браузеры с поддержкой webp явно его указывают наряду с */*
Именно чтобы User-Agent не трогать
Именно чтобы User-Agent не трогать
https://alexey.detr.us/en/posts/2018/2018-08-20-webp-nginx-with-fallback/
Брузер отправляет в заголовках, какие форматы он принимает. Если там есть webp, то можно вместо запрошенного jpg/png отправлять webp, только дополнительно нужно указать в заголовках, что это webp.
Так же, браузер отправляет в заголовках, например, поддерживаемые форматы сжатия (архивировния): "gzip, deflate, br", чтобы сервер мог сжимать отдаваемый контент наиболее эффективным способом. Например, gzip не всеми браузерами поддерживается и сервер может выбрать формат сжатия.
Окончание «.jpg» не имеет никакого значения. Браузеры не могут и не должны на него ориентироваться. Формат указывается в Content-type и только там.
Спорное решение имхо. Например ajax запрос часто отдает Accept вида "*/*"
Так что, все равно придется в сессию писать признак для webp.
Так что, все равно придется в сессию писать признак для webp.
Если все запросы за картинками идут простыми GET запросами.
Простой запрос GET, простой ответ, в зависимости от заголовка.
Хром и все приличные браузеры добавляют заголовок Accept:… image/webp…
Что сомнительного если браузер получит ответ с заголовком Content-Type: image/webp и WebP картинкой внутри?
Простой запрос GET, простой ответ, в зависимости от заголовка.
Хром и все приличные браузеры добавляют заголовок Accept:… image/webp…
Что сомнительного если браузер получит ответ с заголовком Content-Type: image/webp и WebP картинкой внутри?
Тоже не понимаю, что спорного — кто может смотреть webp — пусть смотрит, не можешь — на старый формат. И все довольны
То есть расширение у картинок не указывается?
Обычно указывается, но оно ни разу не обязано совпадать с тем, в каком формате картинка, на самом деле, отдаётся.
Расширение в URL это условность. По сути в URL вы можете увидеть что-нибудь напоминающее путь по файловой системе или просто имя файла. По факту это всего лишь условности, удобства для. Нет никакой необходимости для /some.png указывать возвращать png-файл. Можно вернуть всё что угодно, даже не картинку вовсе. URL это просто строка, адрес. Любой смысл её частям мы придаём сами в своей голове и, скажем, в nginx-конфиге. Правда если запрос сделан из недр <img/> то надеяться, что она пережуёт какой-нибудь HTML, конечно, нет :)
Как часто в аяксом запрашиваете картинку?
Список адресов картинок отдается часто. Если соблюдать правила хорошего тона «один URL однозначно определяет один ресурс», то расширение у image должно быть и тогда это проблема.
Текстовая часть после последней точки никакое не расширение и может быть какая угодно. Так что напишите там, что хочется, а формат выдавайте по заголовку запроса от браузера.
В данной ситуации, вопрос в том, что при uri
Это может выйти боком не только в SEO, но и даже при банальном использовании стандартного механизма кеширования, например в том же nginx согласно документации
и если забыть переопределить такой ключ, можно получить кучу веселых часов в поисках проблемы
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;
.....
и если забыть переопределить такой ключ, можно получить кучу веселых часов в поисках проблемы
Вы выдумали проблему, её не существует.
Во-первых, URL и URI вещи разные.
Во-вторых, нигде не гарантируется и не подразумевается, что в общем случае на одном урле всегда живёт один и тот же набор информации. Попробуйте зайти два раза на «Хабр» с разницей в час, например.
В-третьих, есть ряд заголовков, управляющих кешированием, в данном случае полезен будет «Vary»
Во-первых, URL и URI вещи разные.
Во-вторых, нигде не гарантируется и не подразумевается, что в общем случае на одном урле всегда живёт один и тот же набор информации. Попробуйте зайти два раза на «Хабр» с разницей в час, например.
В-третьих, есть ряд заголовков, управляющих кешированием, в данном случае полезен будет «Vary»
Попробуйте зайти два раза на «Хабр» с разницей в час, например.
Это плохая аналогия, надеюсь сами понимаете почему.
Никогда так не пишите, я тоже так умею: это прекрасная аналогия, надеюсь вы сумеет понять почему.
Если вас не устраивает такой пример, то представьте, что вы зашли тремя браузерами: один поддерживает сжатие gzip, второй brotli, а третий не поддерживает никакого.
Если вас не устраивает такой пример, то представьте, что вы зашли тремя браузерами: один поддерживает сжатие gzip, второй brotli, а третий не поддерживает никакого.
Во-первых, указывать другому участнику дискуссии, что ему делать, а что нет — это еще более худшие манеры.
Во-вторых, в случае с Хабром, он отдает явные директивы no-cache, поэтому разный контент, при одном и том же контент-тайпе, но в разное время — это как раз нормально.
Речь шла о том, что если мы на запрос одного и того же url отдаем разный контент-тайп, то придется об этом помнить и выставлять заголовки для кэширующих прокси, одновременно решая вопрос: какой именно контент-тайп мы будем отдавать при заголовке в реквесте accept "*/*"
И все это, замечу, взамен простого и явного разделения на jpg/png и webp в адресе url, которое не требует практически никаких лишних телодвижений и надежно как молоток
Во-вторых, в случае с Хабром, он отдает явные директивы no-cache, поэтому разный контент, при одном и том же контент-тайпе, но в разное время — это как раз нормально.
Речь шла о том, что если мы на запрос одного и того же url отдаем разный контент-тайп, то придется об этом помнить и выставлять заголовки для кэширующих прокси, одновременно решая вопрос: какой именно контент-тайп мы будем отдавать при заголовке в реквесте accept "*/*"
И все это, замечу, взамен простого и явного разделения на jpg/png и webp в адресе url, которое не требует практически никаких лишних телодвижений и надежно как молоток
Ну давайте ещё манерами будем меряться.
Нет ничего страшного в том, чтобы отдавать разный content-type на один урл. Ровно для этой цели этот заголовок и придуман — чтобы браузер сообщал что он по этому урлу может принять.
Нет ничего страшного в том, чтобы отдавать разный content-type на один урл. Ровно для этой цели этот заголовок и придуман — чтобы браузер сообщал что он по этому урлу может принять.
Коллега, мы (все IT) решаем одну единственную задачу, но разными способами.
Уменьшить затраты времени для человека. Точное выражение которой:
T = посетители*(время загрузки)+(время сжатия)+(время интеграции решения)
Если использовать ваш «молоток», то время интеграции решения с обработкой всех ссылок на картинки и его поддержка может обойтись дороже, чем «топор» обработки Accept.
Я просто вкрутил это дело в свое время за часов 20 от идеи до боевого.
Pagespeed, который работает как ваш молоток, жрет немало памяти и медленней отдает html из-за отсутствующей картинки. Использовал сам.
Уменьшить затраты времени для человека. Точное выражение которой:
T = посетители*(время загрузки)+(время сжатия)+(время интеграции решения)
Если использовать ваш «молоток», то время интеграции решения с обработкой всех ссылок на картинки и его поддержка может обойтись дороже, чем «топор» обработки Accept.
Я просто вкрутил это дело в свое время за часов 20 от идеи до боевого.
Pagespeed, который работает как ваш молоток, жрет немало памяти и медленней отдает html из-за отсутствующей картинки. Использовал сам.
Content negotiation — это часть HTTP, так что тут всё в соответствии со стандартом.
забыли про пункт «оптимизируй картинки» совсем.
вам лучи ненависти от пользователей не-хромированных браузеров.
До тех пор пока webp (любой другой новый формат) не поддерживается Apple, ситуация не изменится.
До тех пор пока webp (любой другой новый формат) не поддерживается Apple, ситуация не изменится.
И какая доля браузеров приходится на Apple? Судя по caniuse — всего 13,35%. Ну раз эти 13% не в состоянии скачать webp и получить картинку лучше качества и меньшего размера, то и остальным нельзя пользоваться этим форматом? Особенно учитывая то, что webp отдаётся с fallback на обычный jpg/png — т.е. увидят все, но владельцы техники apple — чуть позже:)
Это большая доля. Если же взять долю среди мобильных браузеров в США, то будет >50%. Никто в своём уме не будет отсекать ни 13%, ни тем более 50%, тем более самую платежеспособную. Отдавать таким jpeg? Тогда нужно перекодировать в jpeg. Перекодирование с потерей только ухудшает качество. Если уменьшать степень сжатия, то теряем выигрыш в размере. В png? Большая вероятность, что размер также увеличится.
Пользователь вообще не увидит разницы в качестве картинки, всё это делается для уменьшения размера при сохранении того же качества. А если размер не меняется, или даже увеличивается, то зачем всё это нужно — непонятно.
Пользователь вообще не увидит разницы в качестве картинки, всё это делается для уменьшения размера при сохранении того же качества. А если размер не меняется, или даже увеличивается, то зачем всё это нужно — непонятно.
А если размер не меняется, или даже увеличивается, то зачем всё это нужно — непонятно.Размер уменьшается для 90% посетителей, а увеличивается для 10%. Счета за траффик для web-сайта уменьшаются, а «платежеспособная часть» может за это платить, если хочет — на то она и «платежеспособная».
Что-то не понимаю, откуда взялось отверджение, что кто-то собирается "отсекать ни 13%"? Если браузер поддерживает webp — вернётся webp, если не поддерживает — fallback до jpg или png. Никто не отдаёт пользователям apple — no-photo.jpg
И никто не конвертит из маленькой webp маленькую jpg — всё генерится из исходной, а в этом случае webp на 25-30% меньше.
Спустя 9 лет Apple добавила поддержку WebP. Немного поздновато, другие производители уже поддерживают AVIF в ранних сборках браузеров.
Sign up to leave a comment.
WebP скоро захватит веб, но век будет не долгим