Lazy Load — пишем на чистом JavaScript загрузку изображений

Что такое ленивая загрузка изображений, как её можно реализовать всего в несколько строк, не подключая jQuery?

Что такое Lazy Load или ленивая загрузка изображений

Когда мы открываем страницу, мы загружаем сразу все ресурсы страницы — собираем DOM дерево из HTML, когда браузер видит ссылку, будь-то CSS, JS, IMG (Image — картинка), то сразу же загружает файл по ссылке, делая на сервер запрос. Как вы наверное уже знаете, чтобы избежать множество запросов к серверу для иконок, решили собирать их в спрайтовые изображения (спрайт):

Либо же, использовать шрифты с иконками, такие как FontAwesome. Либо же, использовать SVG (от англ. Scalable Vector Graphics — масштабируемая векторная графика). Очень классная штука, рекомендую применять всё вышеперечисленное :). Сейчас еще мэйнстрим на формат изображений webp, которые значительно уменьшают вес изображений.

Вы спросите, а причём тут вообще это? Где статья? 🙂 Чтобы добиться минимального веса страниц, нужно применять все эти рекомендации на своих проектах. И вот однажды, придумали такую классную штуку как Lazy Load. Суть её в том, что вы будете загружать только те изображения, которые попали в «вашу область видимости». Даже, если вы открыли страницу по середине и нажали F5, будут загружены именно те изображения, которые относятся к данному участку кода.

И это, как по мне, гениально. Если представить насколько меньше станет запросов к серверу, и насколько это уменьшит размер страниц, то это «отвал башки!» 🙂

Как написать Lazy Load на JavaScript

Знакомьтесь, это IntersectionObserver . Intersection Observer API позволяет веб-приложениям асинхронно следить за изменением пересечения элемента с его родителем или областью видимости документа.
Как это выглядит на практике:

window.onload = () => {
	const observer = new IntersectionObserver((entries, observer) => {
		entries.forEach(entry => {
			if (entry.isIntersecting) {
				//console.log(entry.target. dataset.src)
				entry.target.src = entry.target.dataset.src
				observer.unobserve(entry.target)
			}
		})
	}, { threshold: 0.5 })
	document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img))
}

Что мы получим в итоге — изображения, в которых есть атрибут data-src, будут загружены по принципу «попало в область браузера — загружаю, и снимаю с этого объекта наблюдение». observer.unobserve(entry.target) — как раз и снимает «наблюдение». В коде есть вывод в консоль для браузера, без этой строки код будет еще меньше, он сейчас закомментирован :).

И вот если раньше, я бы подключал мною любимый jQuery, вешал на scroll обработчик, то благодаря такому коду, можно сделать всё куда проще. Кстати говоря, от jQuery сейчас тоже все отказываются, и одна из причин это оптимизация загрузки страницы, а также полный переход на чистый javascript.

Lazy Load для бекграундов на JavaScript

Сначала код:

window.onload = () => {
	const observerBg = new IntersectionObserver((entries, observer) => {
		entries. forEach(entry => {
			if (entry.isIntersecting) {
				console.log(entry.target.dataset.bg)
				entry.target.style.backgroundImage = "url('"+entry.target.dataset.bg+"')"
				observer.unobserve(entry.target)
			}
		})
	}, { threshold: 0.5 })
	document.querySelectorAll('[data-bg]').forEach(el => observerBg.observe(el))
}

Как видно, мы просто ищем атрибут [data-bg], в котором хранится путь к изображению (в данном случае браузер не будет загружать такую ссылку, т.к. посчитает эту информацию строкой) и затем добавляем атрибут style в background-image. Напоминаю, что для указания свойств, состоящих из 2 и более символов, нужно указывать через camelCase — поэтому мы пишем backgroundImage.

Таким же образом, можно добавлять\убирать какие-то классы, менять бекграунд, и т.д.

Для чего вообще применяют это API:
— «ленивая» или отложенная загрузка изображений
— бесконечная прокрутка страницы
— получение информации о видимости рекламы для целей расчета стоимости показов
— запуск процесса или анимации, находящихся в поле зрения пользователя

Какие минусы у Lazy Load?

Казалось бы, какие тут минусы, сплошные плюсы. Ан нет! Дело в поисковых роботах, которые анализируют вашу страницу на наличие в них изображений, с рабочими путями. Поэтому будьте внимательны, и если будете применять этот метод, то делайте это для менее важного контента. Например, если вы делаете это на карточке товара или новости — то скорей всего это будет не самой лучшей идеей, а вот если примените код в подгрузке товаров по клику на кнопку «показать еще» через AJAX, то ничего плохого не случится.

HTML если было не понятно:

<img alt="" data-src="/local/templates/site/img/logo.webp">

<div data-bg="/upload/iblock/faf1/m01qfgi7ld3qnbfa0eglxadz7j0lmf5x.webp">..

Спасибо всем за прочтение, надеюсь было интересно :).

Оптимизация загрузки изображений

tilda help center

О технологии Lazy Load.

На Тильде для всех сайтов по умолчанию включен режим Lazy Load. Это позволяет сайтам загружаться очень быстро, даже на мобильных устройствах.

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

Lazy Load — это плагин, который блокирует загрузку изображений вне области просмотра. То есть изображения загружаются по мере того, как пользователь прокручивает страницу. Давайте посмотрим как это выглядит.

Возьмем стандартную страницу в темплейтах и опубликуем. http://project130385.tilda.ws/

Откроем инспектор браузера, включим в настройках имитацию медленной скорости интернета — 3G и перезагрузим страницу.

DOMContentLoaded: 628 миллисекунд
параметр, который говорит о том, что загрузились все важные скрипты и html, то есть пользователь может уже увидеть страницу.

Finish: 1.65 секунд
параметр, который показывает, за какое время загрузился весь сайт.

Transferred: 263 kb
параметр, который показывает сколько байт информации было передано.

Цифры очень оптимистичные! Но все познается в сравнении. Перейдем в Настройки сайта > Еще и отключим режим Lazy Load. Протестируем страницу еще раз.

DOMContentLoaded: 697 миллисекунд
параметр, который говорит о том, что загрузились все важные скрипты и html, то есть пользователь может уже увидеть страницу.

Finish: 10.14 секунд
параметр, который показывает, за какое время загрузился весь сайт.

Transferred: 1.8 mb
параметр, который показывает сколько байт информации было передано.

Общее время загрузки страницы и количество информации, которая была передана, увеличилось в разы.

Давайте посмотрим, что скажет PageSpeed Google. Проверим страницу с выключенной оптимизацией:

И включим Lazy Load:

Lazy Load блокирует изображения, которые не видны пользователю, и поэтому ускоряет загрузку сайта.

Кроме режима Lazy Load нужно обязательно оптимизировать изображения, загруженные на сайт. Больше всего на результаты теста PageSpeed Google влияют именно вес изображений. Чтобы уменьшить вес, можно использовать специальные инструменты, например Tinypng.

Примечание

Как удалить код JavaScript и CSS, блокирующий отображение верхней части страницы?

Это довольно частый вопрос, который появляется после прохождения теста. Google очень строго ругается на наличие скриптов в верхней части страницы.

Теоретически удалить скрипты можно, но нужно делать скидку на то, что это автоматический анализ, он не точен. Как мы посмотрели раньше, с включенным режимом Lazy Load страницы загружаются очень быстро — все, что можно уже оптимизировано. Мы проанализировали и пришли к выводу, что удаление скриптов даст выгоду в условные 0.3 секунды, которые принципиально ничего не изменят.

Поэтому наша позиция: мы игнорируем замечание автоматического теста Google о скриптах в начале страницы.

Кстати, а как Google проходит собственный тест?

Критический путь рендеринга — веб-производительность

Критический путь рендеринга — это последовательность шагов, которые браузер выполняет для преобразования HTML, CSS и JavaScript в пиксели на экране. Оптимизация критического пути рендеринга повышает производительность рендеринга. Критический путь рендеринга включает в себя объектную модель документа (DOM), объектную модель CSS (CSSOM), дерево рендеринга и макет.

Объектная модель документа создается при анализе HTML. HTML может запросить JavaScript, который, в свою очередь, может изменить DOM. HTML включает или делает запросы на стили, которые, в свою очередь, создают объектную модель CSS. Движок браузера объединяет их для создания дерева рендеринга. Макет определяет размер и расположение всего на странице. Как только макет определен, пиксели рисуются на экране.

Оптимизация критического пути рендеринга сокращает время до первого рендеринга. Понимание и оптимизация критического пути рендеринга важны для того, чтобы перекомпоновки и перерисовки могли происходить со скоростью 60 кадров в секунду, чтобы обеспечить эффективное взаимодействие с пользователем и избежать рывков.

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

Запрос веб-страницы или приложения начинается с запроса HTML. Сервер возвращает HTML — заголовки ответа и данные. Затем браузер начинает анализировать HTML, преобразовывая полученные байты в дерево DOM. Браузер инициирует запросы каждый раз, когда находит ссылки на внешние ресурсы, будь то таблицы стилей, скрипты или встроенные ссылки на изображения. Некоторые запросы блокируются, что означает, что синтаксический анализ остальной части HTML останавливается до тех пор, пока не будет обработан импортированный ресурс. Браузер продолжает анализировать HTML, делая запросы и создавая DOM, пока не дойдет до конца, после чего он строит объектную модель CSS. Когда DOM и CSSOM завершены, браузер строит дерево рендеринга, вычисляя стили для всего видимого содержимого. После того, как дерево рендеринга завершено, происходит компоновка, определяющая расположение и размер всех элементов дерева рендеринга. После завершения страница визуализируется или «рисуется» на экране.

Объектная модель документа

Построение DOM является добавочным. Ответ HTML превращается в токены, которые превращаются в узлы, которые превращаются в дерево DOM. Один узел DOM начинается с токена startTag и заканчивается токеном endTag. Узлы содержат всю необходимую информацию об элементе HTML. Информация описывается с помощью токенов. Узлы подключаются к дереву DOM на основе иерархии токенов. Если другой набор токенов startTag и endTag находится между набором startTag и endTags, у вас есть узел внутри узла, именно так мы определяем иерархию дерева DOM.

Чем больше количество узлов, тем дольше будут происходить следующие события на критическом пути рендеринга. Мера! Несколько дополнительных узлов не будут иметь большого значения, но имейте в виду, что добавление большого количества дополнительных узлов повлияет на производительность.

Объектная модель CSS

Модель DOM содержит все содержимое страницы. CSSOM содержит всю информацию о том, как стилизовать DOM. CSSOM похож на DOM, но отличается. В то время как конструкция DOM является инкрементной, CSSOM — нет. CSS блокирует рендеринг: браузер блокирует рендеринг страницы до тех пор, пока не получит и не обработает весь CSS. CSS блокирует отрисовку, потому что правила могут быть перезаписаны, поэтому содержимое не может быть отрисовано, пока CSSOM не будет завершен.

В CSS есть собственный набор правил для определения действительных токенов. Помните, что C в CSS означает «Каскад». Правила CSS каскадируются. Поскольку синтаксический анализатор преобразует токены в узлы, узлы-потомки наследуют некоторые стили родителя. Функции инкрементной обработки не применяются к CSS, как к HTML, поскольку последующие правила могут иметь приоритет над предыдущими. Объектная модель CSS строится по мере синтаксического анализа CSS, но ее нельзя использовать для построения дерева рендеринга до тех пор, пока оно не будет полностью проанализировано, поскольку стили, которые будут перезаписаны при более позднем синтаксическом анализе, не должны отображаться на экране.

С точки зрения производительности селекторов менее конкретные селекторы работают быстрее, чем более конкретные. Например, .foo {} быстрее, чем .bar .foo {} , потому что, когда браузер находит .foo , во втором сценарии он должен просмотреть DOM, чтобы проверить, есть ли .foo . предок .bar . Более конкретный тег требует больше работы от браузера, но вряд ли стоит оптимизировать этот штраф.

Если вы измерите время, необходимое для синтаксического анализа CSS, вы будете поражены тем, насколько на самом деле быстры браузеры. Более конкретное правило дороже, потому что оно должно проходить через большее количество узлов в дереве DOM, но эти дополнительные затраты, как правило, минимальны. Сначала измерьте. Оптимизируйте по мере необходимости. Специфичность, скорее всего, не ваш самый низкий висящий фрукт. Когда дело доходит до CSS, улучшения оптимизации производительности селекторов будут всего за микросекунды. Существуют и другие способы оптимизации CSS, такие как минимизация и разделение отложенного CSS на неблокирующие запросы с помощью медиа-запросов.

Дерево рендеринга

Дерево рендеринга захватывает как содержимое, так и стили: деревья DOM и CSSOM объединяются в дерево рендеринга. Чтобы построить дерево рендеринга, браузер проверяет каждый узел, начиная с корня дерева DOM, и определяет, какие правила CSS присоединены.

Дерево рендеринга захватывает только видимое содержимое. Раздел заголовка (обычно) не содержит никакой видимой информации и поэтому не включается в дерево рендеринга. При наличии дисплея : нет; для элемента, ни он, ни его потомки не находятся в дереве рендеринга.

Компоновка

После построения дерева рендеринга становится возможной компоновка. Макет зависит от размера экрана. Шаг компоновки определяет, где и как элементы располагаются на странице, определяя ширину и высоту каждого элемента, а также их расположение по отношению друг к другу.

Какова ширина элемента? Элементы уровня блока по определению имеют ширину по умолчанию, равную 100% ширины их родителя. Элемент шириной 50% будет составлять половину ширины своего родителя. Если не указано иное, тело имеет ширину 100%, что означает, что оно будет составлять 100% ширины области просмотра. Эта ширина устройства влияет на макет.

Метатег области просмотра определяет ширину области просмотра макета, влияя на макет. Без этого браузер использует ширину области просмотра по умолчанию, которая в полноэкранных браузерах по умолчанию обычно составляет 960 пикселей. В полноэкранных браузерах по умолчанию, таких как браузер вашего телефона, установив , ширина будет шириной устройства вместо ширины области просмотра по умолчанию. . Ширина устройства изменяется, когда пользователь поворачивает свой телефон между альбомным и портретным режимами. Макет происходит каждый раз, когда устройство поворачивается или размер браузера иным образом изменяется.

DOM влияет на производительность макета — чем больше количество узлов, тем больше времени занимает макет. Макет может стать узким местом, приводя к рывкам, если это необходимо во время прокрутки или других анимаций. Хотя задержка в 20 мс при загрузке или изменении ориентации может быть хорошей, она приведет к рывкам при анимации или прокрутке. При каждом изменении дерева рендеринга, например добавлении узлов, изменении содержимого или обновлении стилей блочной модели на узле, происходит компоновка.

Чтобы уменьшить частоту и продолжительность событий компоновки, пакетные обновления и избежать анимации свойств блочной модели.

Краска

Последний шаг — рисование пикселей на экране. После создания дерева рендеринга и компоновки пиксели можно отрисовывать на экране. При загрузке рисуется весь экран. После этого будут перерисованы только затронутые области экрана, так как браузеры оптимизированы для перерисовки минимально необходимой области. Время отрисовки зависит от того, какие обновления применяются к дереву рендеринга. Хотя рисование — это очень быстрый процесс, и поэтому, вероятно, не самое эффективное место, на котором следует сосредоточиться для повышения производительности, важно помнить, что при измерении того, сколько времени может занять кадр анимации, необходимо учитывать время как макета, так и повторного рисования. Стили, применяемые к каждому узлу, увеличивают время отрисовки, но удаление стиля, который увеличивает отрисовку на 0,001 мс, может не дать вам максимальной отдачи от оптимизации. Не забудьте сначала измерить. Затем вы можете определить, должно ли это быть приоритетом оптимизации.

Увеличьте скорость загрузки страниц, установив приоритет загрузки ресурсов, контролируя порядок их загрузки и уменьшая размер файлов этих ресурсов. Советы по повышению производительности включают в себя 1) минимизацию количества критически важных ресурсов путем отсрочки загрузки некритических ресурсов, пометки их как асинхронных или их полного исключения, 2) оптимизацию количества необходимых запросов вместе с размером файла каждого запроса и 3) оптимизация порядка загрузки критических ресурсов путем определения приоритета загрузки критических ресурсов, тем самым сокращая длину критического пути.

Последнее изменение: 6 октября 2022 г. , участниками MDN

Отложенная загрузка изображений — Полное руководство

Содержание

Сегодня изображения имеют решающее значение для каждого веб-сайта и приложения. Будь то рекламные баннеры, изображения продуктов или логотипы, невозможно представить веб-сайт без изображений. К сожалению, изображения имеют большой размер, что делает их самым большим фактором, влияющим на размер страницы.

Согласно последним данным HTTP-архива, средний размер страницы на настольных компьютерах составляет 1511 КБ. Изображения составляют почти 650 КБ этого размера, примерно 45% от общего размера страницы. Теперь, поскольку мы не можем избавиться от изображений, нам нужно сделать так, чтобы наши веб-страницы загружались с ними быстрее.

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

Получите это руководство в виде электронной книги. Прямо в почтовый ящик!

Содержание

Что такое отложенная загрузка изображения?

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

Вот короткое видео, которое поможет вам лучше понять:

Слово «ленивый» в английском языке часто связывают с избеганием работы как можно дольше.

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

Технику ленивой загрузки можно применять почти ко всем ресурсам на странице. Например, в одностраничном приложении, если JS-файл не понадобится позже, лучше не загружать его изначально. Если изображение не требуется заранее, загрузите его позже, когда оно действительно понадобится для просмотра.

Зачем вообще откладывать загрузку изображений?

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

Имеет два основных преимущества.

1. Улучшение производительности

Это самое важное для вас как администратора веб-сайта — лучшая производительность и время загрузки.

При отложенной загрузке вы уменьшаете количество изображений, которые необходимо загрузить на страницу изначально. Меньшие запросы ресурсов означают меньшее количество байтов для загрузки и меньшую конкуренцию за ограниченную полосу пропускания сети, доступную пользователю. Это гарантирует, что устройство сможет загружать и обрабатывать оставшиеся ресурсы намного быстрее. Следовательно, страница становится пригодной для использования намного раньше, чем страница без отложенной загрузки.

2. Снижение затрат

Второе преимущество для вас заключается в стоимости доставки. Доставка изображения или доставка любого другого актива обычно оплачивается на основе количества переданных байтов.

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

Какие изображения можно загружать отложенно?

Основная идея ленивой загрузки проста — отложить загрузку всего, что сейчас не нужно. Для изображений это обычно означает, что любое изображение, которое не видно пользователю, может быть загружено отложенно.

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

Вы можете узнать, какие изображения являются кандидатами на отложенную загрузку и сколько байтов вы можете сэкономить при начальной загрузке страницы, используя инструмент аудита Google Lighthouse. Аудит, выполняемый этим инструментом, имеет раздел, посвященный закадровым изображениям. Вы также можете использовать анализатор веб-сайтов ImageKit, чтобы определить, использует ли ваш веб-сайт отложенную загрузку или нет, в дополнение к другим важным оптимизациям, связанным с изображениями на вашей странице.

Ленивая загрузка имеет решающее значение не только для хорошей производительности, но и для удобного взаимодействия с пользователем.

Методы ленивой загрузки изображений

Изображения на веб-странице можно загружать двумя способами — с помощью тега или с помощью свойства CSS `background`. Давайте сначала рассмотрим более распространенный из двух тегов , а затем перейдем к фоновым изображениям CSS.

Общая концепция ленивой загрузки изображений в теге

Ленивая загрузка изображений может быть разбита на два этапа:

Первый шаг — предотвратить предварительную загрузку изображения. Для изображений, загружаемых с использованием тега , браузер использует атрибут тега src для запуска загрузки изображения. Независимо от того, является ли это 1-м или 1000-м изображением в вашем HTML и находится далеко за пределами экрана, если браузер получит атрибут src , он вызовет загрузку изображения.

Таким образом, чтобы лениво загружать такие изображения, поместите URL-адрес изображения в атрибут, отличный от src . Допустим, мы указываем URL-адрес изображения в поле 9.0025 data-src атрибут тега изображения. Теперь, когда src пуст, браузер не запускает загрузку изображения

мы остановили предварительную загрузку, нам нужно сообщить браузеру, когда загружать изображение.

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

Проверить, когда изображение попадает в окно просмотра, можно двумя способами:

Инициировать загрузку изображения с помощью событий Javascript

В этом методе мы используем прослушиватели событий прокрутки , изменения размера, и ориентацияChange событий в браузере. Событие прокрутки является очевидным событием для проверки, когда пользователь прокручивает страницу. События resize и OrientChange одинаково важны для ленивой загрузки. Событие изменения размера возникает при изменении размера окна браузера. Событие ориентацияChange запускается, когда устройство поворачивается из альбомного режима в портретный или наоборот. В таких случаях количество изображений, которые становятся видимыми на экране, изменится. Поэтому нам нужно инициировать загрузку этих изображений.

Когда происходит любое из этих событий, мы находим на странице все изображения, которые должны быть загружены отложенно и которые еще не были загружены. По этим изображениям мы проверяем, какие из них сейчас находятся в окне просмотра. Это делается с использованием верхнего смещения изображения, верхнего края прокрутки текущего документа и высоты окна. Если он вошел в область просмотра, мы выбираем URL-адрес из атрибута data-src и помещаем его в атрибут src . Это запускает загрузку изображения. Мы также удаляем класс lazy , который идентифицирует изображения для ленивой загрузки для событий, которые запускаются позже. Как только все изображения загружены, мы удаляем прослушиватели событий.

Когда мы прокручиваем, событие прокрутки запускается несколько раз быстро. Таким образом, для производительности мы добавляем небольшой тайм-аут, который ограничивает выполнение функции ленивой загрузки.

Вот рабочий пример такого подхода.

Если вы заметили, первые 3 изображения в примере загружаются вперед. URL-адрес присутствует непосредственно в атрибуте src вместо атрибута data-src . Это необходимо для хорошего пользовательского опыта. Поскольку эти изображения находятся в верхней части страницы, их следует сделать видимыми как можно скорее. Мы не должны ждать события или выполнения JS, чтобы загрузить их.

Использование Intersection Observer API для запуска загрузки изображений

Intersection Observer API — относительно новый API в браузерах. Это позволяет очень просто определить, когда элемент входит в область просмотра, и выполнить действие, когда это произойдет. В предыдущем методе нам приходилось привязывать события, помнить о производительности и реализовывать способ вычисления того, был ли элемент в области просмотра или нет. Intersection Observer API делает это действительно простым, помогает избежать математики и обеспечивает отличную производительность.

Пример использования Intersection Observer API для ленивой загрузки изображений:

Мы прикрепляем наблюдатель ко всем изображениям, подлежащим ленивой загрузке. Как только API обнаруживает, что элемент вошел в область просмотра, используя свойство isIntersecting , мы выбираем URL-адрес из атрибута data-src и перемещаем его в атрибут src , чтобы браузер инициировал загрузку изображения. Как только это будет сделано, мы удалим ленивый класс из изображения, а также удалим наблюдателя из этого изображения.

Если вы сравните время, затрачиваемое на загрузку изображения в обоих методах, прослушиватели событий и Intersection Observer, вы обнаружите, что при использовании Intersection Observer API загрузка изображения запускается намного быстрее, и при этом сайт не выглядит вялым. при прокрутке. В методе, включающем прослушиватели событий, нам пришлось добавить тайм-аут, чтобы сделать его производительным, что оказывает незначительное влияние на взаимодействие с пользователем, поскольку загрузка изображения запускается с небольшой задержкой.

Однако поддержка Intersection Observer API доступна не во всех браузерах. Следовательно, нам нужно вернуться к методу прослушивания событий в браузерах, где API-интерфейс Intersection Observer не поддерживается. Мы учли это в приведенном выше примере.

Встроенная отложенная загрузка

В своем последнем обновлении Google добавила поддержку встроенной отложенной загрузки в последнюю версию браузера Chrome — Chrome 76. Все браузеры на основе Chromium, т. е. Chrome, Edge и Safari, а также Firefox. Вы можете найти более подробную информацию о поддержке браузерами встроенной отложенной загрузки на caniuse.com.

Теперь, когда в игру вступает поддержка на стороне браузера, разработчикам нужно только добавить атрибут «загрузка» при встраивании изображений, чтобы реализовать ленивую загрузку на своих веб-сайтах.

Для этого даже не нужно быть разработчиком. Некоторых базовых знаний HTML достаточно, чтобы реализовать атрибут «загрузка», что делает эту функцию доступной для большего количества администраторов веб-сайтов.

Теперь код будет выглядеть так:

Атрибут загрузки поддерживает следующие значения:

• lazy — Отсрочка загрузки ресурсов до тех пор, пока они не достигнут определенного расстояния от области просмотра.
• нетерпеливый — загрузка ресурсов сразу после загрузки страницы, независимо от того, где они расположены на странице, выше или ниже сгиба страницы.
• авто — Это значение запускает отложенную загрузку по умолчанию. По сути, это то же самое, что не включать атрибут загрузки.

Однако для браузеров, которые не поддерживают встроенную ленивую загрузку, необходимо применять вышеупомянутые методы ее реализации.

Как описано далее в этом блоге, чтобы предотвратить перекомпоновку окружающего содержимого при загрузке отложенного изображения, обязательно добавьте атрибуты height и width к элементу или укажите их значения напрямую. во встроенном стиле:

Получите это руководство в виде электронной книги. Прямо в почтовый ящик!

Отложенная загрузка фоновых изображений CSS

После тегов фоновые изображения являются наиболее распространенным способом загрузки изображений на веб-страницу. Для тегов у браузера очень простой подход — если доступен URL изображения, давайте загрузим изображение.

С фоновыми изображениями CSS все не так просто. Чтобы загрузить фоновые изображения CSS, браузеру необходимо построить дерево DOM (объектная модель документа), а также дерево CSSOM (объектная модель CSS), чтобы решить, применяется ли стиль CSS к узлу DOM в текущем документе.

Если правило CSS, определяющее фоновое изображение, не применяется к элементу в документе, браузер не загружает фоновое изображение. Если правило CSS применимо к элементу в текущем документе, браузер загружает изображение.

Поначалу это может показаться сложным, но такое же поведение лежит в основе техники ленивой загрузки фоновых изображений. Проще говоря, мы обманываем браузер, заставляя его не применять CSS-свойство фонового изображения к элементу до тех пор, пока этот элемент не появится в области просмотра.

Вот рабочий пример ленивой загрузки фонового изображения CSS.

Следует отметить, что код Javascript для отложенной загрузки остался прежним. Мы используем метод Intersection Observer API с откатом к слушателям событий. Хитрость заключается в CSS.

Элемент с идентификатором bg-image имеет фоновое изображение , указанное в CSS. Однако когда к этому элементу добавляется класс lazy , в CSS мы переопределяем фоновое изображение 9.0026 и установите для него значение none.

Поскольку правило, объединяющее #bg-image с классом .lazy , имеет более высокий приоритет в CSS, чем просто #bg-image , браузер изначально применяет свойство background-image: none к элементу . Когда мы прокручиваем вниз, Intersection Observer (или прослушиватели событий) обнаруживает, что изображение находится в области просмотра, и удаляет класс lazy . Это изменяет применимый CSS и применяет фактическое фоновое изображение 9.0026 к элементу, вызывающему загрузку фонового изображения.

Более удобный пользовательский интерфейс с отложенной загрузкой изображений

Отложенная загрузка значительно повышает производительность. Для компании электронной коммерции, которая загружает сотни изображений продуктов на страницу, отложенная загрузка может обеспечить значительное сокращение времени начальной загрузки страницы при одновременном снижении потребления полосы пропускания.

Однако многие компании не выбирают ленивую загрузку, потому что считают, что это идет вразрез с удобством работы пользователей, ссылаясь на такие причины, как «первоначальный заполнитель уродлив», «время загрузки медленное» и т. д.

Как мы можем решить эти проблемы, связанные с пользовательским интерфейсом с отложенной загрузкой изображений?

1. Использование правильных заполнителей изображений

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

Мы использовали то же самое в нашем примере кода. Для фона всех наших изображений используется сплошной светло-серый цвет. Тем не менее, мы можем сделать лучше, чтобы обеспечить более приятный пользовательский опыт.

Посмотрите на некоторые примеры лучших заполнителей для наших изображений:

 
 imagekit.io/demo/img/image4.jpeg?tr=w-400,h-300" alt="исходное изображение" />