Comments 15
Webp уже неактуально добавлять, пришла пора avif
По мне так это надо переложить на сторону сервера раздающего картинки, если к нему пришел браузер с поддержкой, отдаем ему наилучший формат.
Н-да... Вот в этом и проблема современного IT.
Вас не смущает, что вы предлагаете image-set для решения проблемы совместимости с webp при том, что поддержка image-set хуже поддержки webp, и если у вас поддерживается image-set, то у вас поддерживается и webp?
Более того, если посмотреть на поддержку picture, то... :)))
Извиняюсь, а что не так с поддержкой picture? Вроде лет десять как почти во всех браузерах поддерживается, кроме совсем уж допотопных (IE и Opera Mini).
А с поддержкой WEBP всё настолько плохо?
Да вроде всё отлично. Оказывается, у меня детектор сарказма в очередной раз поломался...
Кстати, по моему скромному опыту, конвертация фотографий с большими перепадами яркости в формат WEBP может приводить к появлению неприятных артефактов. Например, вокруг предметов могут возникнуть ореолы. К сожалению, от таких артефактов не всегда получается избавиться путем снижения степени сжатия. Поэтому, как мне кажется, старый добрый JPEG рано отправлять в утиль.
P.S. Дабы не быть голословным, сошлюсь на примеры артефактов, подмеченные пользователями поопытнее меня:
WebP Images | WideRange Galleries
ЦИТАТА:
If we look closely at the images above we can start to see how WebP images struggle with soft gradients, with some subtle blockiness in the sky and some noticeable banding artifacts in the reflection. The WebP file is a mere 41% of the size of the JPG, but is it worth the quality loss? Tough call - probably most people wouldn't notice the difference, but I'd probably opt for the JPG here.
ЦИТАТА:
Finally, with the dawn images above I wanted to show you the Achilles' heel of WebP compression: soft gradients with darker colors. The WebP file is a mere 21% the size of the JPG, but the compression artifacts are obvious enough that I would definitely display the JPG instead of WebP.
Именно поэтому в статье и предлагается фолбек. Если браузер не поддерживает image-set и webp, он загрузит понятный ему jpeg или png с помощью свойства background-image. Но при этом данный подход не лишает пользователей прогрессивных браузеров всех плюсов и фишек новых решений. Так что никакой проблемы IT тут не вижу :)
А есть такая проблема с поддержкой WEBP, что fallback на picture и image-set её решает?
Перед тем как решать проблему нужно убедиться, что она существует. Действительно существуют пользователи, у которых есть поддержка image-set и picture, но нет поддержки webp? Я не могут себе такого реального кейса представить.
Как я понимаю picture устроен так что внутри него img в котором по дефолту стоит jpeg картинка и если в браузере нет поддержки webp и даже нет поддержки picture то img с jpeg будет отображен. За счёт этой механики будет работать фолбэк
Да. Здесь подробнее про picture: https://www.youtube.com/live/tTn36NWCpMI?feature=share
imgproxy или подобное?
и никакого webpack )
Минусы:
Без интернета в приложеньке картинки работать не будут и UI весь повалится =(
Зависимость от стороннего сервера =(
Плюс платить надо вдруг что не так =(
Плюс:
imgproxy и прочие серверные решения хороши для динамично загружаемых картинок
(загружаемые авы, фотки от юзеров) которые никак не засунешь в билд
Итог: для статичных интерфейсных элементов лучше использовать решение, которое подарил на Автор! Спасибо тебе автор! Я всегда буду тебя любить ?
Webpack. Создание WebP вместе с Jpeg и Png