Как стать автором
Обновить

Комментарии 13

Появление этого атрибута прекрасная иллюстрация к поговорке — хотели как лучше, а получилось как всегда.

В текущей его реализации, это абсолютно бесполезная технология и вот почему:
  1. Атрибут не работает с любым изображением содержащим srcset и sizes — а это сейчас стандарт по умолчанию.
  2. Атрибут не дает возможности контролировать свою работу. СОВСЕМ. Он вещь в себе, которая делает то, что ему хочется. Параметры активации прибиты гвоздями в коде браузера
  3. В текущей реализации, вне зависимости от того где изображение, браузер все равно создаст запрос к серверу и скачает около 2 килобайт, для того чтобы определить его размеры. И повлиять на это нельзя


Как итог, выпускается обрубок, который не работает даже со всеми валидными вариантами верстки того же IMG, не говоря уже о том, чтобы послушать людей которые работают с подобной технологией по 15 лет, для которых она как бы и должна была быть создана.

Обрубок, который кардинально НИКАК не повлияет на производительности страницы, потому что в любом случае создает соединение на каждое изображение и нагружает канал.

Полезен будет только той категории людей, которые до сих пор изображения верстают как
<IMG src=  >

и по каким то своим причинами использовать чужой код не хотят, а свой написать не могут, но при этом доросли до того, чтобы перевестать до
<IMG src=  loading="lazy">


Все же, кто использовал Lazyload не как игрушку, как использовали свой код, так и будут продолжать использовать.

Полностью и абсолютно с вами согласен — свой lazyload код в разы более гибкий, да и реализаций немало. Вряд ли сий тег будет кто импользовать кроме начинающих.

Спасибо, ценная информация. Но я не люблю сторонние библиотеки lazyload, по таким причинам:


  • они не обратно-совместимы, то есть старый браузер (если инвалиды-авторы библиотеки используют ES6 или ES5) или браузер без JS ничего не покажет с ними
  • они могут использовать события вроде scroll, что негативно влияет на производительность
  • они могут быть не совместимы с опцией отмены загрузки страницы по нажатию Esc
  • они раздувают объем JS-кода
  • они часто используют анимации, которые сильно нагружают браузер при одновременной загрузке нескольких картинок

Зависит от задач. Если нужно гибкое управление ленивой загрузкой, то использовать библиотеку — это нормально. В большей части моих проектах хватит стандартного поведения.

Атрибут не дает возможности контролировать свою работу. СОВСЕМ. Он вещь в себе, которая делает то, что ему хочется. Параметры активации прибиты гвоздями в коде браузера

Так Хром потихоньку стал новым осликом) Двигает свои стандарты не советуясь ни с кем, шантажирует владельцев сайтов несовместимостью с их браузером и тд… Думаю, лет через 5-10 история с IE6 повторится

Новый ослик — это, скорее, Сафари, который плохо поддерживает стандарты и в целом медленно развивается.

Сегодня проверял scrset — работает, правда у меня он реализован через picture. Лишний запрос к серверу и минимальные размеры картинок действительно нивелирут преимущества. Например для 100к картинки, первые 2кб грузятся столько же по таймингу как все 100 при хорошем коннекте, при плохом несколько секунд TTFB на первый запрос. В целом поддерживаю — атрибут бесполезен.

Есть еще один интересный еффект — для больших картинок, первый заброс на 2к при плохом соединении иногда отменяется. Кто-то понял почему?
Атрибут не дает возможности контролировать свою работу. СОВСЕМ.

Не дают контроллировать свою работу программисту, но добавляют возможность (хотя бы теоретическую) управлять этим пользователю.

Все же, кто использовал Lazyload не как игрушку, как использовали свой код, так и будут продолжать использовать.

И в итоге те, кому этот lazyload нахрен не впился будут страдать, и обходить каждую из подобных «своих кодов» по разному: где-то по быстрому прокрутив страницу, где-то открыв диалог печати…
Для далеких от фронтенда — а что не так с тегом img?
Как-то все тут уперлись в loading=«lazy». Ребята, а как же значение eager? Это же должно быть очень круто, лично я замахался на первом экране, когда ставишь большее фоновое изображение сначала понижать его качество, а потом колдовать что б из какахи делать конфету… надо тестить
Меня одного lazy loading бесит как таковой? Как пользователь, я ожидаю, что любая не интерактивная по своей природе страница полностью загружена на момент пропадания прогрессбара в интерфейсе браузера. Lazy loading это ломает. У меня было слишком много случаев, когда я что-то прогрузил заранее, чтобы прочитать при плохом/отсутствующем интернете, а потом оказывалось, что не прогрузил и вместо картинок размазня. Спасибо, что сэкономили мне мой безлимитный трафик, чёрт возьми.

Вынести это в браузер — идеологически очень правильное решение, потому что тогда либо в самом браузере можно будет сделать настройку, либо кто-нибудь сделает расширение, чтобы пользователь мог этим поведением управлять для всех сайтов в соответствии со своими предпочтениями. В конце концов, браузер не просто так называется user agent.

Если отбросить все минусы и представить, что атрибут работает идеально и его прямо стоит использовать, то не приведёт ли это к ситуации, когда просто у каждого изображения будет ставиться loading="lazy"?
Тогда смысла в атрибуте совсем пропадает. Возможность управления поведением можно оставить только пользователю на случай, если кому-то уж нужно получать всё при первой загрузке. Например, для поездок через границу

Те кто понимает как работает данный атрибут, такой фигни творить не будут, а ленивые и так его ставить не будут. В вэбе уже и так достаточно свойств и атрибутов что б ускорить работу или сделать загрузку оптимальной (will-change, link rel=«preload», тег picture… ) Кто знает, тот использует, кто не знает, не париться
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории