Comments 22
Спасибо за IntersectionObserver!
Дополню поддержкой браузерами:
https://caniuse.com/#search=IntersectionObserver
IntersectionObserver API — штука очень спорной необходимости. На первый взгляд — ну как же, lazy-load картинок, оптимизация, все дела! Я сам писал библиотеку для ленивой загрузки картинок и она даже довольно неплохо работала (не опубликована).
Но! Всё разбивается о скалы picture/source/srcset. Как только нужно делать адаптивность по-взрослому, под все устройства/браузеры/ретины, реализовать ленивую загрузку становится очень-очень сложно.
Вывод прост: полноценная ленивая загрузка должна реализовываться нативно в браузере — и Хром сейчас идет в правильном напрвлении.
Но! Всё разбивается о скалы picture/source/srcset. Как только нужно делать адаптивность по-взрослому, под все устройства/браузеры/ретины, реализовать ленивую загрузку становится очень-очень сложно.
Вывод прост: полноценная ленивая загрузка должна реализовываться нативно в браузере — и Хром сейчас идет в правильном напрвлении.
Вы явно чем то не разобрались.
srcset и sizes + обсервер апи — наоборот сделали лейзилоад возможным в серьезных проектах., которым важен трафик из органического поиска.
picture же совместо с source это баловство, которое не имеет никакого отношения к сложным проектам.
Никто в здравом уме не будет решать проблемы поддержки форматов на стороне клиента, где каждый лишний узел в дом дереве на вес золота. Все это решается на уровне сервера.
Непонятно, что сделал возможным IntersectionObserver? Он ведь не дает ничего принципиально нового, что нельзя было бы реализовать руками. Да, с ним удобнее, надёжнее, меньше возможностей накосячить — это всё верно и хорошо.
Но ведь атрибуты src/data-src всё равно точно так же меняются местами. В отличие от нативного варианта. (Хотя справедливости ради, библиотеки дают шире возможности).
По поводу source. Даже если не вступать в спор, на чьей стороне лучше решать вопрос с форматами, у него есть другой интересный атрибут — media. И он бывает даже более важен для нрмальной адаптивности, чем srcset/sizes.
Но ведь атрибуты src/data-src всё равно точно так же меняются местами. В отличие от нативного варианта. (Хотя справедливости ради, библиотеки дают шире возможности).
По поводу source. Даже если не вступать в спор, на чьей стороне лучше решать вопрос с форматами, у него есть другой интересный атрибут — media. И он бывает даже более важен для нрмальной адаптивности, чем srcset/sizes.
Непонятно, что сделал возможным IntersectionObserver? Он ведь не дает ничего принципиально нового, что нельзя было бы реализовать руками. Да, с ним удобнее, надёжнее, меньше возможностей накосячить — это всё верно и хорошо.
Тем что раньше, делая это руками, Вы нагружали CPU тысячами срабатываний вашего обработчика который висел на scroll, resize, и кучи других событий. Вплоть до таймера.
Сейчас все это делает сам браузер на своем уровне. И делает это на 99.9% хорошо. Покажите мне программиста который не хочет избавиться от лишней логики при этом еще и разгружая ЦП.
Но ведь атрибуты src/data-src всё равно точно так же меняются местами.
Не меняются. То что написано в статье это из раздела вредных советов. Так делать ни в коем случае нельзя. Сейчас правильный лейзилоад оперирует исключительно атрибутом srcset
Важно понимать, что в случае если указан атрибут srcset то браузер показывает то, что в этом атрибуте, вне зависимости от того, что находится в атрибуте src. Именно этот факт сделал LazyLoad применимым. Теперь есть гарантии, что поисковый робот проиндексирует изображения, а не заглушки. (в src всегда находится ссылка на изображение отвечающее контенту)
В отличие от нативного варианта.
Нативный вариант это безусловно прекрасно. При условии если дадут контролировать логику его работы. Сейчас это жалкая подделка для тех, кто может только прописать лишний атрибут в теге.
lazyload не ограничивается работой только с изображениями. Это инструмент который позволяет решать массу задач.
Даже если не вступать в спор, на чьей стороне лучше решать вопрос с форматами,
Здесь нет перемета спора. Если сервер, обеспечивающий отдачу статики, находится под вашим контролем, то именно он должен принимать решение какую именно статику нужно отдать на запрос бразуера. Браузеры давно научились передавать в заголовках
достаточно информации для того, чтобы сервер мог однозначно принять решение о том, какой формат того же изображения будет выгоднее всего.
Исключением является только тот редкий случай, когда статику подгружают с чужого сервера, поведением которого невозможно управлять.
у него есть другой интересный атрибут — media. И он бывает даже более важен для нормальной адаптивности, чем srcset/sizes.
Каким это образом атрибут media вдруг оказался важнее sizes, когда в sizes можно указывать media запросы да еще и под каждый конкретный файл?
Но даже если есть какая то особая миссия именно у одного глобального медиа запроса на это изображение, тоже самое можно сделать через медиа запрос привязанный к стилю этого изображения.
Вы нагружали CPU тысячами срабатываний вашего обработчикаРазумеется, нужно делать тротлинг, и нормальные библиотеки его делают. Это несколько строк кода, есть готовые реализации.
Я ж не спорю, что с новым апи удобнее. Но ничего принципиально нового, что раньше ну вот никак не получалось, он не дал.
Сейчас правильный лейзилоад оперирует исключительно атрибутом srcsetСмысл абзаца я понял. Но не очень понятно, а что раньше мешало в атрибуте src держать не какую-то формальную заглушку, а LQIP-версию той же контентной картинки? Я именно так и делал. Опять же ничего принципиально нового.
lazyload не ограничивается работой только с изображениями.Это да. Например, моя реализация умела лениво навешивать стили или вводить дополнительные временнЫе задержки.
Здесь нет перемета спора.Его действительно нет в том смысле, что оба подхода вполне имеют право на существование в зависимости от ситуации. Ни про какой нельзя однозначно сказать, что он плох.
в sizes можно указывать media запросы да еще и под каждый конкретный файл?Можно, но это верный способ взорвать мозг даже себе :) Не говоря уж о тех, кто будет читать код впоследствии. Проблема атрибутов srcset/sizes в том, что между файлами и размерами не устанавливается взаимно-однозначного соответствия.
Пример из блога Оперы
Что сейчас должно загрузиться?! Да черт его знает.
Возможно, пример переусложнён, но потенциал для «творчества» демонстрирует.
dev.opera.com/articles/native-responsive-images
Удобно там решается только простые вопросы типа «фикс размеры + плотность пикселей» (1x/2x). А когда в дело вступают сложные комбинации размеров/пропорций/кадрирования и тп. — получается всё очень запутанно и непонятно (во всяком случае для меня). И ко всему прочему, браузер имеет некоторую свободу при интерпретации атрибута sizes.<img
sizes="(max-width: 30em) 100vw, (max-width: 50em) 50vw, calc(33vw - 100px)"
srcset="swing-200.jpg 200w, swing-400.jpg 400w, swing-800.jpg 800w, swing-1600.jpg 1600w"
src="swing-400.jpg" alt="Kettlebell Swing">Что сейчас должно загрузиться?! Да черт его знает.
Возможно, пример переусложнён, но потенциал для «творчества» демонстрирует.
dev.opera.com/articles/native-responsive-images
Смысл абзаца я понял. Но не очень понятно, а что раньше мешало в атрибуте src держать не какую-то формальную заглушку, а LQIP-версию той же контентной картинки? Я именно так и делал. Опять же ничего принципиально нового.
Тем что Бот должен видеть картинку в максимальном качестве.
Вы как и большинство верстальщиков/веб-программистов забываете, что тег IMG это семантический тег, который наряду с другими семантическими тегами вводили для того чтобы описывать суть контента на странице.
Он несет смысловую нагрузку (изображение отвечающее контексту), и прямо влияет на ранжирование проекта в поисковой выдаче.
Это да. Например, моя реализация умела лениво навешивать стили или вводить дополнительные временнЫе задержки.
Какая бы у Вас не была реализация, ее применение ограничено тем кругом задач, где не важна работа поисковых роботов, или любых других роботов опирающихся на семантику по причине того, что ваш src равный пустоте или заглушке, будет интерпретирован роботом именно как пустота и заглушка.
Его действительно нет в том смысле, что оба подхода вполне имеют право на существование в зависимости от ситуации. Ни про какой нельзя однозначно сказать, что он плох.
Неверно. Десятки source это всегда плохо. В силу двух критически важных факторов: создание лишней нагрузки на браузер и раздувания ДОМ дерева, прямо влияющего как на работу JS в случае оперирования с ДОМ так и на обобьем потребления памяти. Не говоря уже о рендере.
Можно, но это верный способ взорвать мозг даже себе :) Не говоря уж о тех, кто будет читать код впоследствии. Проблема атрибутов srcset/sizes в том, что между файлами и размерами не устанавливается взаимно-однозначного соответствия.
Это уже вопрос квалификации.
А когда в дело вступают сложные комбинации размеров/пропорций/кадрирования и тп. — получается всё очень запутанно и непонятно (во всяком случае для меня).
Не получается. Даже если Вам трудно воспринимать такие медиа выражения, вы можете разбить это все на обычные классы которые обернуть в те же медиа.
И ко всему прочему, браузер имеет некоторую свободу при интерпретации атрибута sizes.
Нет не имеют. sizes всегда интерпретируется однозначно. Поведение которое выбирает браузер в зависимости от ситуации (канал, дпи, разрешние) может варьироваться. И это правильно, потому что человеку сидящему с ретина монитором на 2g канале нет никакого смысла грузить 3x изображение. Он просто не дождется его загрузки.
Тем что Бот должен видеть картинку в максимальном качествеЯ понимаю семантическое значение img. Я не понимаю, в чем принципиальная разница между ситуациями подмены src и srcset.
Если мы решили экономить трафик, то в src в любом случае будет небольшая (но осмысленная!) заглушка.
Если же у нас в src картинка максимального качества (для бота), то причем тут ленивая загрузка, если эта большая картинка будет всё равно загружена? Ведь она будет загружена? Потому что srcset у нас пустой до момента, когда элемент въедет во вьюпорт.
Нет не имеют. sizes всегда интерпретируется однозначноВ спецификации написано, что все эти атрибут имеют информационный характер, и юзер-агент может выбирать любой вариант исходя из своих соображений.
Например, если я напишу:
[img src="0.jpg" srcset="1.jpg 1000w, 2.jpg 2000w" sizes="1500px"]Браузер вправе выбрать любой из вариантов хотя бы потому, что 1500 ровно посередине между 1000 и 2000.
На практике браузеры обычно выбирают большее значение. Но я как-то натыкался на случай, где Хром и ФФ делали разный выбор в пограничных значениях (к сожалению, уже не воспроизведу).
Если же у нас в src картинка максимального качества (для бота), то причем тут ленивая загрузка, если эта большая картинка будет всё равно загружена
Не будет. Вы не внимательно читаете то что я вам пишу с самого начала.
Изображение размечается как содержащее атрибут src с максимальным качеством И атрибут srcset содержащий необходимые для отображения на текущий момент файлы.
Браузер никогда ничего не загрузит из src до тех пор пока есть srcset.
Чтобы в нем не содержалось.
Соответственно, в рамках LazyLoad мы имеем изображение у которого атрибут src с ссылкой на файл самого высокого качества, srcset содержащий единственный урл на заглушку,
и какой-нибудь data-srcset с набором файлов для нашего изображения.
Попали в область просмотра, заменили текущий srcset на data-scrset.
В спецификации написано, что все эти атрибут имеют информационный характер, и юзер-агент может выбирать любой вариант исходя из своих соображений.
Например, если я напишу:
В спецификации пишется о том, что атрибут srcset как и sizes содержат необходимы инструкции на основании которых браузер принимает решение о том, какой из файлов максимально близко отвечает текущей ситуации.
То что Вы задали два правила которые которые находятся на пересечении двух множеств событий — это лично Ваша проблема. А не проблема выдуманной Вами неоднозначности поведения браузера.
Задавайте правила без избыточности и у Вас не будет никаких проблем.
На практике браузеры обычно выбирают большее значение.
Ну что тут скажешь. Попрактикуйтесь побольше.
По src/srcset понятно. Но есть один нюанс — вы заставите юзеров старых браузеров качнуть эту самую картинку максимального качества. А ведь обычно люди со старыми браузерами сидят на слабом железе.
А главное, неизбежно пересекающиеся медиа-запросы — размеры экранов, ориентации экранов, плотности пикселей. И там будет избыточность. Если бы нужно было делать адаптивность строго по одному параметру (ширине или плотности пикселей) — то тогда проблемы действительно нет.
Задавайте правила без избыточности и у Вас не будет никаких проблем.В общем случае это невозможно. Потому что это только в стерильном примере я написал фиксированное значение в px. А в реальности там будут какие-нибудь vw или calc.
А главное, неизбежно пересекающиеся медиа-запросы — размеры экранов, ориентации экранов, плотности пикселей. И там будет избыточность. Если бы нужно было делать адаптивность строго по одному параметру (ширине или плотности пикселей) — то тогда проблемы действительно нет.
По src/srcset понятно. Но есть один нюанс — вы заставите юзеров старых браузеров качнуть эту самую картинку максимального качества. А ведь обычно люди со старыми браузерами сидят на слабом железе.
Разговор начался с того, что
srcset и sizes + обсервер апи — наоборот сделали лейзилоад возможным в серьезных проектах., которым важен трафик из органического поиска.
Что определяет условия в которых мы ведем разговор. А именно существование srcset, которые позволили делать LazyLoad который никаким образом не повлияет на индексацию поисковыми роботами.
Применения других LazyLoadov до того момента фактически убивало проект в поиске, в любой конкурентной нише.
С появлением srcset стал возможен выбор — увеличить аудиторию за счет тех кто не уйдут с тормозящего сайта, но потерять тех кто сидит на старом бразуере, или потерять первых но спасти вторых. При этом сохранив в обоих случаях корректную индексацию.
srcset сейчас это 93% всех браузеров в мире. Дальше вопрос бизнеса, если ты теряешь 7% от тех кто пользуется устаревшими браузерами, коменисруешь ли ты это ростом за счет оставшейся аудитории.
В общем случае это невозможно. Потому что это только в стерильном примере я написал фиксированное значение в px. А в реальности там будут какие-нибудь vw или calc.
А главное, неизбежно пересекающиеся медиа-запросы — размеры экранов, ориентации экранов, плотности пикселей. И там будет избыточность. Если бы нужно было делать адаптивность строго по одному параметру (ширине или плотности пикселей) — то тогда проблемы действительно нет.
Обожаю людей с развитым воображением. Это всегда в плюс к человеку. Даже когда он увлекается.
НЕТ никакой разницы какие правила вы используете и какие единицы для этого используете.
source от sizes отличается только одним — глобальным медиа правилом у тега source, которое можно либо уложить в рамках sizes, либо повторить его (медиа запрос) в стилях закрепив под него класс (), примененный к тому же изображению ( )
Хотите сказать что это не так?
Приведите живой пример где бы было невозможно повторить поведение sources их не используя.
Я не говорил, что повторить поведение source нельзя. Слово «невозможно» относилось ко фразе «задавайте правила без избыточности».
Я говорил, что поскольку source позволяет установить взаимно-однозначное соответствие между файлом и медиа-запросом, то при их большом количестве структура становится гораздо более читаемой и понятной. И плевать на несколько дополнительных узлов в доме — разница незначительна, в отличие от удобства.
Я говорил, что поскольку source позволяет установить взаимно-однозначное соответствие между файлом и медиа-запросом, то при их большом количестве структура становится гораздо более читаемой и понятной. И плевать на несколько дополнительных узлов в доме — разница незначительна, в отличие от удобства.
А хотя нашелся пример. Да, он использовался на практике, хотя и редко.
Я выше упоминал о разных ориентациях экрана — для десктопа и телефона показываются фотки с разным кадрированием.
Ну и плюс конечно размеры тоже, но тут они убраны для наглядности.
Логично: sizes, как и намекает имя атрибута, справляется если картинка одна, просто разных размеров. Но как только появляются содержательно разные картинки, нужен source.
Я выше упоминал о разных ориентациях экрана — для десктопа и телефона показываются фотки с разным кадрированием.
Ну и плюс конечно размеры тоже, но тут они убраны для наглядности.
<picture>
<source srcset="horizontal.jpg" media="(orientation: landscape)">
<source srcset="vertical.jpg" media="(orientation: portrait)">
<img src="fallback.jpg">
</picture>Логично: sizes, как и намекает имя атрибута, справляется если картинка одна, просто разных размеров. Но как только появляются содержательно разные картинки, нужен source.
Интересуюсь, какая есть необходимость в использовании ленивой загрузки картинок? Ведь картинки — это неблокирующие ресурсы для браузера. Грузятся себе в фоне, и хорошо, отрисовке dom-а не мешают. Зато при скроле к картинке — она уже вероятно будет загружена, не нужно будет ждать.
Если ленивая загрузка решает случай, когда на одной html-ине сотни больших картинок, так разве не пагинация эту проблему должна решать?
Если ленивая загрузка решает случай, когда на одной html-ине сотни больших картинок, так разве не пагинация эту проблему должна решать?
1. Экономия трафика (причем и клиентского, и серверного).
2. Экономия памяти устройства (актуально для мобильников).
3. Возможность управлять порядком загрузки (например, сначала загрузить контентные картинки, а уж потом размытый декоративный фон).
Основная суть ленивой загрузки не в том, чтобы загрузить картинку чуть попозже — а в том, чтобы загрузить её только при реальной необходимости. Потому что пользователь может вообще никогда до неё не доскролить, то есть картинка не пригодится.
А пагинация это не всегда приемлемый (по разным соображениям) костыль.
2. Экономия памяти устройства (актуально для мобильников).
3. Возможность управлять порядком загрузки (например, сначала загрузить контентные картинки, а уж потом размытый декоративный фон).
Основная суть ленивой загрузки не в том, чтобы загрузить картинку чуть попозже — а в том, чтобы загрузить её только при реальной необходимости. Потому что пользователь может вообще никогда до неё не доскролить, то есть картинка не пригодится.
А пагинация это не всегда приемлемый (по разным соображениям) костыль.
Экономия трафика это понятно.
Под пагинацией — имел ввиду любой интерфейсный триггер, который явно делает пользователь чтоб подгрузить дополнительный dom-контент (к примеру, «посмотреть ещё...», «далее...», в продвинутых галереях-слайдерах с опцией lazy — кнопка «следующий слайд», сюда также можно отнести инфинити-скролл, и т.д.).
По ощущениям, как раз-таки lazy-подгрузка картинок (замена атрибутов data-src на src) в зависимости от расстояния до видимого экрана выглядит «больше» костылём, чем явная команда пользователя «дайте ещё контента».
Для себя так понял, что ленивая загрузка (именно картинок, не dom), имеет смысл, если каким-то образом дизайнер спроектировал интерфейс, в котором много «толстых» картинок занимающих два и более вьюпорта. Но по субъективному мнению, в таких случаях просится пагинация в том или ином виде.
Под пагинацией — имел ввиду любой интерфейсный триггер, который явно делает пользователь чтоб подгрузить дополнительный dom-контент (к примеру, «посмотреть ещё...», «далее...», в продвинутых галереях-слайдерах с опцией lazy — кнопка «следующий слайд», сюда также можно отнести инфинити-скролл, и т.д.).
По ощущениям, как раз-таки lazy-подгрузка картинок (замена атрибутов data-src на src) в зависимости от расстояния до видимого экрана выглядит «больше» костылём, чем явная команда пользователя «дайте ещё контента».
Для себя так понял, что ленивая загрузка (именно картинок, не dom), имеет смысл, если каким-то образом дизайнер спроектировал интерфейс, в котором много «толстых» картинок занимающих два и более вьюпорта. Но по субъективному мнению, в таких случаях просится пагинация в том или ином виде.
У нас, помню тоже была похожая ситуация в React-приложении. IntersectionObserver использовать не стали — ибо была нужна поддержка IE11. Наш выбор пал на react-waypoint. Сработал на ура, если отбросить кое-какие ограничения по стилям родителя и сузить использование до ленивого рендеринга (+ ленивой загрузки) react-компонентов.
Для более гранулированного контроля, конечно, вряд ли подойдёт.
Будьте добры удалить из текста перевода иллюстрацию на использование которой вам никто не давал прав.
Sign up to leave a comment.
API IntersectionObserver и ленивая загрузка изображений