Противоречивый пользовательский опыт с нативной ленивой загрузкой картинок

Спецификация нативной поддержки веб-браузера для лениво загружаемых изображений в HTML Living Standard, эта новая функция позволяет веб-разработчикам указывать браузеру откладывать загрузку изображения до тех пор, пока оно не будет показано для просмотра или пока оно не будет.

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

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

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

Эта двусмысленность в спецификации создала реализации с различным пользовательским опытом. Прежде чем углубляться в детали того, как они различаются, мне нужно сначала объяснить API-интерфейс Intersection Observer.

Intersection Observer - это современная замена практики ручной обработки событий прокрутки для расчета, видим ли элемент на странице. Браузер теперь обрабатывает это для вас и запускает событие, когда отслеживаемый элемент прокручивается в поле зрения. Обозреватель пересечений может быть настроен с полем вокруг видимой области просмотра (IntersectionObserver.rootMargin) вызывая событие на настраиваемом расстоянии перед прокруткой в ​​поле зрения.

В Chromium Blink (Chrome), Mozilla Gecko (Firefox) и WebKit (Safari) реализованы отложенные загрузки изображений с использованием Intersection Observer. Однако каждая реализация имеет разные поля! Эти поля не могут быть изменены без перекомпиляции движка рендеринга.

Chromium Blink использует запас в 3000px для сетевых подключений с низкой задержкой и до 8000px для подключений с высокой задержкой. В зависимости от задержки в сети это может привести к немедленной загрузке всех изображений на странице. Такое поведение компрометирует некоторые преимущества экономии данных и производительности при загрузке, которые вы могли бы получить при использовании изображений с отложенной загрузкой.

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

Реализация WebKit является неполной на момент написания. Тем не менее, предлагаемый патч устанавливает свои поля в 100px по вертикали и 0px по горизонтали. Это дает браузеру небольшой хедз-ап, чтобы начать загрузку изображения перед его прокруткой в ​​поле зрения. Этого может быть недостаточно в зависимости от состояния сети и скорости прокрутки.

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

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

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

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

Поведение Blink было названо «слишком нетерпеливым», и я склонен согласиться. Однако поведение Gecko также кажется слишком ленивым. Я считаю, что идеальное поле по умолчанию, вероятно, лежит где-то между этими двумя реализациями.