Comments 23
Про AVIF надо еще добавить, что это пипец какой медленный для декодинга формат.
Может легко получиться, что страница будет тормозить с ним больше, чем WEBP с учетом скачивания дополнительных байт. Особенно это актуально для встроек.
Если у вас 10-20 картинок на странице, стоит подумать и протестировать и то и то, желательно не на топовом компе разработчика.
Угу, а то получится "скачалось быстро, а показать не смогло" на каком-нибудь телефоне за условные 10к
Проблема в том, что разрабы браузеров почему-то не хотят использовать быстрый декодер (dav1d), который декодирует avif в 2-3 раза быстрее чем это делает референсный декодер aom. dav1d на ПК декодирует avif с такой же скорость, с которой декодируется heic/heif, а на arm скорее всего даже быстрее.
Да, согласен, про это я в статье не указал, ограничился ссылками на источники, где все форматы протестированы. Там можно подробнее поизучать графики/таблицы и изображения разных видов в сравнении:
https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4
В статье крайне не хватает следующих бенчмарков:
Скорость кодирования/декодирования. Сжать на 20% не сложно. Сложно не потратить при этом на порядок больше ресурсов.
Оценка качества при том же размере. Вы говорите про уменьшение размера при перекодировании, но ни слова о том, что было бы при перекодировании в тот же JPEG до такого же размер. В том числе слепое рандомизированное тестирование человеческим глазом
Я не стал перегружать статью этими цифрами, с ними можно ознакомиться в исследовании Джейка Арчибальда и в статье из блога Netflix. Там много всего интересного, есть и визуальное сравнение изображений в разных форматах одного и того же размера/степени сжатия.
1) Сейчас скорость кодирования можно сказать не учитывается, потому-что 1 раз закодировал, а посмотрели эту картинку например 10000 раз.
2) Тут согласен, жепег визуально может казаться лучше при слепом тестировании из-за добавления своего шума, тогда как webp и тем более avif не добавляют шума, а наоборот избавляются от того шума, что есть в исходнике. Например если фотка сильно пошарплена, тогда жепег 100% будет казаться лучше при слепом тестировании. Но если жепег такой, что видна блочность, тогда avif 100% лучше, ну а webp как повезёт (в зависимости от контента). Так же жепег сильно блочит градиенты, например небо на фотках.
Так же, слепое сравнение жепега и avif без сравнения с исходником такое себе занятие. А если сравнивать именно с исходником, то avif сохраняет куда больше инфы, тогда как при сравнении между собой без сравнения с исходником avif может показаться хуже жепега.
Привыкли мы уже к жепегу так сильно, что остальное кажется плохим, а оно не плохое, оно просто работает по другому. Например avif (av1) делает упор на мелкие детали и заметно мылит что-то слабо контрастное, но мы наоборот лучше видим потери в слабо контрастных участках, чем в мелких деталях, поэтому нужно использовать адаптивную квантизацию, чтобы выделять больше бит на слабо контрастные участки, тогда можно избежать "мыльца" при том что мелкие детали всё равно будут лучше чем у жепега.
Для среднестатистического пользователя на 1000 загруженных картинок хорошо если 10 просмотров наберётся, ибо сейчас "контент" генерируется много быстрее, чем его успевают "потреблять". Но это всё не важно. Сервера тоже не бесконечные, так что их лучше потратить на что-то более полезное (например, на кодирование видео).
Пользователь всё-равно не видит оригинала, так что сравнивать надо именно визуальное восприятие того, что вы ему показываете.
Зачем какому-то среднестатистическому пользователю использовать avif? В статье косвенно говорится кому это нужно, тем чьи сайты на первых местах в поисковиках.
Ну раз пользователь не видит оригинала, то значит ему можно подсовывать вообще какую-то дичь сгенерированную нейросетями, которая только отдалённо напоминает оригинал, но за то визуально круто выглядит, так что-ли? Будет весить такая картинка сгенерированная нейросетями 2кб например, хорошо же.
Я абсолютно против такого, пусть выглядит хуже, не важно как, главное чтобы было максимальное сходство с оригиналом, как бы весь смысл сжатия с потерями, как ни странно, сделать минимальные потери при максимальном сжатии.
В случае же простых изображений, созданных в графических редакторах, может оказаться, что лучший выбор там — PNG, и по размеру, и по качеству.
В кодеке AV1 (AVIF — производный от него формат) так перестарались со сжатием в ущерб скорости, что без аппаратной поддержки декодирования лучше это и не пробовать.
av1 (avif) на ПК декодируется с такой же скоростью что и hevc (h265) (heic/heif) при возможном лучшем качестве. На arm скорее всего декодируется быстрее чем hevc, я это пока не тестировал (протестирую). Аппаратная поддержка av1 уже есть.
Просто не нужно использовать на странице фотки 12мп, тогда проблем быть не должно, такие фотки использовать только в галереях, где они показываются по 1 штуке за раз.
А вот перестарались со сжатием в vvc (h266), говорят он в 2 раза медленее декодируется чем hevc. А vp9/av1 ориентированы на веб, поэтому ориентировались на быстрое декодирование. Для av1 просто нужно использовать декодер dav1d и всё.
Расскажите, а что по статистике? Какой процент пользователей всё ещё откатываются к jpeg?
Уже какое-то время есть плагин avif для фотошопа, с открытым исходным кодом от какого-то разраба. Минус этого плагина - нету предпросмотра, но с такой то скоростью кодирования возможно это и не минус.
<picture>
<source srcset="/path/to/image.avif" type="image/avif">
<source srcset="/path/to/image.webp" type="image/webp">
<source srcset="/path/to/image.jpg">
<img src="/path/to/fallback-image.jpg" alt="">
</picture>
Это хорошо, но получается, что теперь надо хранить не 1 картинку в jpg, а 3 (jpg, webp и avif). А место то на сервере не резиновое. Получается, что реально это использовать только для каких-нибудь изображений в шаблоне сайта, но никак не для динамического контента (например, изображения товаров), так как их может быть ну уж очень много, если каталог на сайте здоровенный. Ну или для лендингов есть смысл это использовать.
Странно видеть в статье про avif и webp картинки в png
Вот смотрю на рабочем проекте, проверка на поддержку форматов лежит в бандле общем, не в head, и там не загружает ничего кроме avif. Вы уверены что именно хэд надо скрипт ложить
страницы открываются быстрее, что положительно влияет как на впечатление пользователя, так и на позиции в поиске: сайты, которые быстро загружаются, получают более высокие позиции в выдаче Яндекса и Google. При этом качество графических материалов остаётся по-прежнему высоким
Это не так.
Если страница откроется на 2 секунды быстрее, но при этом юзер будет видеть на странице мутные картинки с искажениями, это никак не доставит ему удовольствие.
Webp с потерями, которые видны. Он всё равно хуже, чем jpeg того же качества.
Актуальные форматы изображений в вебе