Comments 10
Вообще, background вместо img используют всякие мерзонькие сайты, пытающиеся воспрепятствовать сохранению картинок, чаще всего таким грешат соцсети. Неприятненько, неприятненько. Ещё и пару-тройку слоёв сверху накидывают, чтоб уж наверняка, и там на click ставят preventDefault().
Опять набор вредных советов на эту тему... Да сколько можно?
Во-первых, это семантически разные сущности. background-image может быть и у элемента img. А ещё <img> - по умолчанию строчный элемент, незнание этого факта приводит к разного рода "сюрпризам".
Во-вторых, применимость того или иного метода зависит от вводных - есть "финты", которые можно сделать только через background (не только background-repeat - есть и несколько фоновых изображений, и background-clip и т.п.). А есть и проблемы - "ой, а почему у меня img раздвигает flexbox?". Здесь куча неочевидных моментов, которые, разумеется, не описываются фразой "всегда используйте <img>".
В-третьих, почему все так настойчиво советуют повсеместно использовать loading="lazy"? Допустим, у меня невысокая скорость интернета, я прокручиваю веб-страницу, срабатывает Intersection Observer API и... изображение только начинает загружаться. Т.е. на якобы загруженной странице мне предлагают любоваться неспешной подгрузкой изображений. Очень "отзывчивое" решение...
Ну для этого есть фоллбэк на Base64 инлайн хтмл копию изображения, сжатую в десятки раз и подставляемую через стиль с background-image, который отобразит очень мутную и размытую браузером картинку, и оная будет заменена на актуальное изображение после подгрузки. А по поводу lazy-загрузок, имхо, предъявлять надо браузерам, пусть они сами разбираются, когда подгружать. К примеру, ближнее к вьюпорту изображение предзагружать сразу после загрузки страницы, дальнее - стартовать только если пользователь начал скроллить.
Что-то вы совсем не о том...
и оная будет заменена на актуальное изображение после подгрузки.
Вот спасибо - теперь вместо пустого пространства буду любоваться на мыльную картинку.
А может стоит просто заранее подгрузить необходимые ресурсы, а не городить велосипед с base64?
А по поводу lazy-загрузок, имхо, предъявлять надо браузерам
Замечательный совет! Хорошо, "предъявили браузерам", дальше что? Проблему нашу это как-то решает?
Интересная статья.
К сожалению, на сегодняшний день, атрибут loading="lazy" плохо поддерживается браузерами http://joxi.ru/1A56nMBiwZLMar , в этой связи, приходится использовать дополнительные библиотеки для lazyload.
Обращаю внимание на то, что вышеуказанный атрибут может использоватся как для тега img, так и для iframe. Для отложенной загрузки iframe, на сегодняшний день, считаю целесообразным использовать заглушку. Вот решение, которое я использую для iframe с ютуба https://github.com/fr0st1kk/add-video-youtube , в ближайшее время допишу документацию.
Простое правило(за редким исключением):
-bg для декора,
-img для контента
Ну, мне совершенно не нравится ленивая загрузка. Небольшие изображения и так грузятся быстро. А большие изображения нужно ждать долго, когда прокрутил страницу и хочешь читать. То есть, ленивая загрузка рушит UX.
У фона также можно использовать srcset, sizes и ленивую загрузку — сделал для этого NPM пакет под React. И синтаксис как у тега img:
<LazyBackground src="..." srcSet="..." sizes="...">
content
</LazyBackground>Оно ещё должно асинхронно декодировать изображение. Вообще полный фарш.
Под капотом работает через загрузку виртуального изображения через new Image(). Потом вставляется на страницу в backgroundImage, подтягивая изображение из кэша браузера. Поэтому есть один минус — при разработке с отключённом кэшем фон загружается дважды.
Надеюсь, в тему статьи! Если есть вопросы, буду рад на них ответить в Telegram или в GitHub issues.
Хорошая статья) Стало понятнее
Оптимизируем изображения в HTML