Комментарии 74
Устарел не устарел, но результаты перехода на webp впечатляют. Вот буквально вчера допилили сервер который на лету трансформирует jpg в webp, сегодня грубую оценку проводили на стенде с копией прода. Минимум!!! -25%, а в среднем под 30..35% уменьшение трафика, плюс оптимизация хром-движка под декодинг webp впечатляет
Если грубо то да. На деле у нас свой cdn которому можно сказать "дай картинку с шириной 200", или дай jpg вместо этого png. И куча слоев кешерования, так как больше 50% медиа — это сгенеренные картинки на базе 2...3..4 других. И вот сейчас можно сказать cdn-у "а дай ка братец мне вот такой webp!".
Ну и ессно выходной html поток пока что фильтруется подменой .jpg на .webp если в accept у клиента указана поддержка webp
В общем проблема в том, что, во-первых, тут используется векторная графика, а не растровая, а во-вторых, svg-формат имеет много фич, которые для браузера не являются сложными, т. к. уже итак реализованы в нём, а для небольшого приложения реализовать всё это сложно. Но, думаю, и не предполагалось, что его кто-то будет поддерживать, это чисто формат для веба и браузера. Даже графические редакторы могут обойтись экспортом в svg.
Заголовок чистой воды кликбейт. Никакой конкретики — кто разрабатывает новый формат, на какой стадии разработка, какие приложения поддерживают его, примеры использования нового формата.
Я может тоже разрабатываю "свой" формат — так что avif уже устарел.
Во-вторых, в активной разработке формат AVIF, который гораздо современнее, чем WebP.
И когда появится поддежка конвертации в этот формат? Когда он станет доступным повсеместно в браузерах?
Не будет ли Firefox (или любой другой браузер) так же тянуть с вводом поддержки этого формата?
А когда наконец новый формат будет поддерживаться хотя бы 70% браузеров (как сейчас), не появится ли новый "прорывной" формат, которые на момент написания очередной статьи о нём будет "в активной разработке"?
Кто разрабатывает — указано в статье. Есть сайт альянса, где есть вся информация по участникам и роадмапам.
Тестовая поддержка видео av1 уже есть в firefox и chrome. Так же есть большие обещания со стороны других участников и сервисов внедрить новый формат после фиксации.
AV1 в хроме конечно же будет, потому что это в том числе и гугловая разработка, и в youtube обязательно будет использоваться.
Такой jpeg выдают множество библиотек, в частности данный пример выдал jpegoptim:
jpegoptim -q --max=85 --strip-all file.jpg
По опыту JPEG очень не любит красные однородные цвета.
Photoshop я знаю лучше справляется с кодированием jpeg, но его в автоматическом режиме к сайту сложновато подцепить.
Вот всегда в таких сравнениях против JPEG для последнего берут самый плохой кодер, вместо лучших представителей. Противный маркетинг.
PaulZi, просьба исправить картинку с сравнением в статье на что-то более правдоподобное.
А вообще такие изображения шикарно жмутся и в PNG, с сохранением высокой чёткости. Вот, 7 килобайт:
Ждём AVIF. Может быть, он действительно покажет радикальное улучшение качества.
MozJPEG не особо популярна, придётся компилить из сырцов чтобы потестить, тем не менее даже он выдал мыло-мыльное, это вино по тёмным дыркам. То что WebP лучше жмёт чем JPEG — это факт.
На самом деле, 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 не используется массово, хоть и существует уже много лет, говорит о многом.
autoreconf -fiv
./configure
make rpm
png 5.72 кб против вашего 6.88
WebP уже устарел
хм… кто-то его применяет на полном серьёзе? Я что-то упустил
Кидаешь пикчу/пачку нажимаешь старт. Всё. Я ничего не «химичил» сам. Ничего долго не настраивал — просто закинул файлы, получил результат. Это автоконверсия? Руками то я только файлы закидываю и старт жму.
Вот тут в 2013-м году о нем писали habr.com/post/168251
WebP уже устарел
А поддержка браузерами еще слаба: caniuse.com/#feat=webp
Как так то?
И название заметки: «WebP скоро захватит веб»
С 2010-го захватывает и никак не захватит и вдруг: раз, и скоро захватил, и умер?
Поэтому я и не комментировал вашу заметку совсем по теме.
Никаких проблем и жизнь прекрасна, только Content-Type в ответе нужно указать image/webp.
И никаких правок в html, забыли про пункт «оптимизируй картинки» совсем.
Браузеру важен какой Content-Type, он доступен по ссылке *.png или *.jpg значения не имеет.
И не тратит такие ценные миллисекунды на обработку html.
Достаточно, чтобы не париться с браузерами не поддерживающими webp? Не догоняю.
Accept скажет что это запрос на картинку, но только юзерагент о том, поддерживает ли клиет webp. Сам подход отличный.
Именно чтобы 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 не всеми браузерами поддерживается и сервер может выбрать формат сжатия.
Так что, все равно придется в сессию писать признак для webp.
Простой запрос GET, простой ответ, в зависимости от заголовка.
Хром и все приличные браузеры добавляют заголовок Accept:… image/webp…
Что сомнительного если браузер получит ответ с заголовком Content-Type: image/webp и WebP картинкой внутри?
Тоже не понимаю, что спорного — кто может смотреть webp — пусть смотрит, не можешь — на старый формат. И все довольны
Расширение в URL это условность. По сути в URL вы можете увидеть что-нибудь напоминающее путь по файловой системе или просто имя файла. По факту это всего лишь условности, удобства для. Нет никакой необходимости для /some.png
указывать возвращать png
-файл. Можно вернуть всё что угодно, даже не картинку вовсе. URL это просто строка, адрес. Любой смысл её частям мы придаём сами в своей голове и, скажем, в nginx-конфиге. Правда если запрос сделан из недр <img/>
то надеяться, что она пережуёт какой-нибудь HTML, конечно, нет :)
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»
Попробуйте зайти два раза на «Хабр» с разницей в час, например.
Это плохая аналогия, надеюсь сами понимаете почему.
Если вас не устраивает такой пример, то представьте, что вы зашли тремя браузерами: один поддерживает сжатие gzip, второй brotli, а третий не поддерживает никакого.
Во-вторых, в случае с Хабром, он отдает явные директивы no-cache, поэтому разный контент, при одном и том же контент-тайпе, но в разное время — это как раз нормально.
Речь шла о том, что если мы на запрос одного и того же url отдаем разный контент-тайп, то придется об этом помнить и выставлять заголовки для кэширующих прокси, одновременно решая вопрос: какой именно контент-тайп мы будем отдавать при заголовке в реквесте accept "*/*"
И все это, замечу, взамен простого и явного разделения на jpg/png и webp в адресе url, которое не требует практически никаких лишних телодвижений и надежно как молоток
Нет ничего страшного в том, чтобы отдавать разный content-type на один урл. Ровно для этой цели этот заголовок и придуман — чтобы браузер сообщал что он по этому урлу может принять.
Уменьшить затраты времени для человека. Точное выражение которой:
T = посетители*(время загрузки)+(время сжатия)+(время интеграции решения)
Если использовать ваш «молоток», то время интеграции решения с обработкой всех ссылок на картинки и его поддержка может обойтись дороже, чем «топор» обработки Accept.
Я просто вкрутил это дело в свое время за часов 20 от идеи до боевого.
Pagespeed, который работает как ваш молоток, жрет немало памяти и медленней отдает html из-за отсутствующей картинки. Использовал сам.
забыли про пункт «оптимизируй картинки» совсем.
вам лучи ненависти от пользователей не-хромированных браузеров.
До тех пор пока webp (любой другой новый формат) не поддерживается Apple, ситуация не изменится.
До тех пор пока webp (любой другой новый формат) не поддерживается Apple, ситуация не изменится.
И какая доля браузеров приходится на Apple? Судя по caniuse — всего 13,35%. Ну раз эти 13% не в состоянии скачать webp и получить картинку лучше качества и меньшего размера, то и остальным нельзя пользоваться этим форматом? Особенно учитывая то, что webp отдаётся с fallback на обычный jpg/png — т.е. увидят все, но владельцы техники apple — чуть позже:)
Пользователь вообще не увидит разницы в качестве картинки, всё это делается для уменьшения размера при сохранении того же качества. А если размер не меняется, или даже увеличивается, то зачем всё это нужно — непонятно.
А если размер не меняется, или даже увеличивается, то зачем всё это нужно — непонятно.Размер уменьшается для 90% посетителей, а увеличивается для 10%. Счета за траффик для web-сайта уменьшаются, а «платежеспособная часть» может за это платить, если хочет — на то она и «платежеспособная».
Что-то не понимаю, откуда взялось отверджение, что кто-то собирается "отсекать ни 13%"? Если браузер поддерживает webp — вернётся webp, если не поддерживает — fallback до jpg или png. Никто не отдаёт пользователям apple — no-photo.jpg
И никто не конвертит из маленькой webp маленькую jpg — всё генерится из исходной, а в этом случае webp на 25-30% меньше.
WebP скоро захватит веб, но век будет не долгим