• Czas czytania ~11 min
  • 08.04.2023

Obsługa leniwego ładowania obrazów na poziomie przeglądarki jest teraz obsługiwana w Internecie! Ten film pokazuje pokaz funkcji:

W Chrome 76 i nowszych wersjach możesz używać atrybutu loading do leniwego ładowania obrazów bez konieczności pisania niestandardowego leniwego kodu ładowania lub używania oddzielnej biblioteki JavaScript. Przejdźmy do szczegółów.

Zgodność z przeglądarką #

Obsługa przeglądarek

  • chrome 77, obsługiwane 77
  • firefox 75, obsługiwane 75
  • krawędź 79, Obsługiwane 79
  • safari 15.4, obsługiwane 15.4

Źródło

Przeglądarki, które nie obsługują tego loading atrybutu, po prostu ignorują go bez skutków ubocznych.

Dlaczego leniwe ładowanie na poziomie przeglądarki? #

Według HTTPArchive, obrazy są najczęściej pożądanym typem zasobów dla większości stron internetowych i zwykle zajmują więcej przepustowości niż jakikolwiek inny zasób. W 90. percentylu witryny wysyłają około 4,7 MB obrazów na komputery i urządzenia mobilne. To dużo zdjęć kotów.

Wcześniej istniały dwa sposoby odroczenia ładowania obrazów poza ekranem:

Każda z tych opcji może pozwolić programistom na dołączenie funkcji leniwego ładowania, a wielu programistów zbudowało biblioteki innych firm, aby zapewnić abstrakcje, które są jeszcze łatwiejsze w użyciu. Jednak przy leniwym ładowaniu obsługiwanym bezpośrednio przez przeglądarkę nie ma potrzeby korzystania z zewnętrznej biblioteki. Leniwe ładowanie na poziomie przeglądarki zapewnia również, że odroczone ładowanie obrazów nadal działa, nawet jeśli JavaScript jest wyłączony na kliencie.

Atrybut loading #

Chrome wczytuje obrazy o różnych priorytetach w zależności od tego, gdzie się znajdują względem widoku urządzenia. Obrazy poniżej rzutni są wczytywane z niższym priorytetem, ale nadal są pobierane tak szybko, jak to możliwe.

Możesz użyć tego loading atrybutu, aby całkowicie odroczyć ładowanie obrazów poza ekranem, do których można dotrzeć przewijając:

<img src="image.png" loading="lazy" alt="…" width="200" height="200">

Here are the supported values for the loading attribute:

  • lazy: Odrzuć ładowanie zasobu, aż osiągnie on obliczoną odległość od rzutni.
  • eager: Domyślne zachowanie przeglądarki podczas ładowania, które jest takie samo jak brak atrybutu i oznacza, że obraz jest ładowany tak szybko, jak to możliwe, niezależnie od tego, gdzie znajduje się na stronie. Chociaż jest to ustawienie domyślne, przydatne może być jawne ustawienie tego, jeśli narzędzia automatycznie dodają loading="lazy" , jeśli nie ma wyraźnej wartości, lub jeśli kłoto narzeka, jeśli nie jest jawnie ustawione.

Relacja między atrybutem loading a priorytetem pobierania #

Wartość eager jest po prostu instrukcją załadowania obrazu w zwykły sposób, bez opóźniania ładowania, jeśli jest poza ekranem. Nie oznacza to, że obraz jest ładowany szybciej niż inny obraz bez atrybutuloading="eager".

Przeglądarki nadają priorytet zasobom na podstawie różnych algorytmów heurystycznych, a loading atrybut określa tylko, kiedy zasób obrazu jest umieszczany w kolejce, a nie jak jest on traktowany priorytetowo w tej kolejce. Oznacza to po prostu, że zwykle przeglądarki kolejkujące są używane domyślnie. eager

Jeśli chcesz zwiększyć priorytet pobierania ważnego obrazu (na przykład obrazu LCP), należy użyć wskazówek priorytetowych z fetchpriority="high"rozszerzeniem .

Należy pamiętać, że obraz z i fetchpriority="high" nadal będzie opóźniony, gdy jest poza ekranem, a następnie pobierany z loading="lazy" wysokim priorytetem, gdy znajduje się prawie w rzutni. Prawdopodobnie i tak zostałby przyciągnięty z wysokim priorytetem w tym przypadku, więc ta kombinacja nie powinna być naprawdę potrzebna ani używana.

Progi odległości od rzutni #

Wszystkie obrazy znajdujące się w części strony widocznej na ekranie (czyli widoczne natychmiast bez przewijania) ładują się normalnie. Te, które znajdują się znacznie poniżej okienka ekranu urządzenia, są pobierane tylko wtedy, gdy użytkownik przewija w ich pobliżu.

Implementacja leniwego ładowania Chromium stara się zapewnić, że obrazy poza ekranem są ładowane wystarczająco wcześnie, aby zakończyły ładowanie, gdy użytkownik przewinie się w ich pobliżu. Pobierając pobliskie obrazy, zanim staną się widoczne w rzutni, maksymalizujemy szansę, że zostaną już załadowane, zanim staną się widoczne.

W porównaniu z leniwymi bibliotekami ładowania JavaScript, progi pobierania obrazów, które przewijają się do widoku, można uznać za konserwatywne. Chromium szuka lepszego dostosowania tych progów do oczekiwań deweloperów.

Próg odległości nie jest stały i różni się w zależności od kilku czynników:

Wartości domyślne dla różnych efektywnych typów połączeń można znaleźć w źródle Chromium. Te liczby, a nawet podejście polegające na pobieraniu tylko po osiągnięciu pewnej odległości od rzutni, mogą ulec zmianie w najbliższej przyszłości, ponieważ zespół Chrome ulepsza heurystykę, aby określić, kiedy rozpocząć ładowanie.

Ulepszone progi oszczędności danych i odległości od rzutni #

Od lipca 2020 r. Chrome wprowadził znaczące ulepszenia, aby wyrównać progi leniwego ładowania obrazu od rzutni, aby lepiej spełniać oczekiwania programistów.

W przypadku szybkich połączeń (4G) zmniejszyliśmy progi odległości od rzutni przeglądarki Chrome z do i na wolniejszych połączeniach (3G lub niższych), zmieniliśmy próg z 3000px 4000px na 2500px.1250px Ta zmiana osiąga dwie rzeczy:

  • <img loading=lazy> zachowuje się bliżej doświadczenia oferowanego przez JavaScript leniwe ładowanie bibliotek.
  • Nowe progi odległości od rzutni nadal pozwalają nam zagwarantować, że obrazy prawdopodobnie zostaną załadowane do czasu, gdy użytkownik przewinie do nich.

Porównanie starych i nowych progów odległości od rzutni dla jednego z naszych dem na szybkim połączeniu (4G) można znaleźć poniżej:

Stare progi. vs nowe progi: i nowe progi vs. LazySizes (popularna biblioteka leniwego ładowania JS):

The new and improved thresholds for image lazy loading, reducing the distance-from-viewport thresholds for fast connections from 3000px down to 1250px

The new  distance-from-viewport thresholds in Chrome loading 90KB of images compared to LazySizes loading in 70KB under the same network conditions

Zobowiązujemy się do współpracy ze społecznością standardów internetowych w celu zbadania lepszego dopasowania w podejściu do progów odległości od rzutni w różnych przeglądarkach.

Obrazy powinny zawierać atrybuty wymiarów #

Podczas gdy przeglądarka ładuje obraz, nie zna od razu wymiarów obrazu, chyba że są one wyraźnie określone. Aby przeglądarka mogła zarezerwować wystarczającą ilość miejsca na stronie na obrazy, zaleca się, aby wszystkie <img> tagi zawierały oba width znaczniki i height atrybuty. Bez określonych wymiarów mogą wystąpić zmiany układu, które są bardziej widoczne na stronach, których wczytywanie zajmuje trochę czasu.

<img src="image.png" loading="lazy" alt="…" width="200" height="200">

Alternatively, specify their values directly in an inline style:

<img src="image.png" loading="lazy" alt="…" style="height:200px; width:200px;">

The best practice of setting dimensions applies to <img> tags regardless of whether or not they are being loaded lazily. With lazy loading, this can become more relevant. Setting width and height on images in modern browsers also allows browsers to infer their intrinsic size.

W większości scenariuszy obrazy nadal ładują się leniwie, jeśli wymiary nie są uwzględnione, ale istnieje kilka przypadków brzegowych, o których należy wiedzieć. Bez width i height określono, wymiary obrazu wynoszą początkowo 0×0 pikseli. Jeśli masz galerię takich obrazów, przeglądarka może stwierdzić, że wszystkie z nich mieszczą się w rzutni na początku, ponieważ każdy z nich nie zajmuje praktycznie żadnego miejsca i żaden obraz nie jest wypychany poza ekran. W takim przypadku przeglądarka stwierdza, że wszystkie są widoczne dla użytkownika i decyduje się załadować wszystko.

Ponadto określenie wymiarów obrazu zmniejsza prawdopodobieństwo wystąpienia przesunięć układu. Jeśli nie możesz uwzględnić wymiarów obrazów, leniwe ładowanie ich może być kompromisem między oszczędzaniem zasobów sieciowych a potencjalnym większym ryzykiem zmiany układu.

Podczas gdy leniwe ładowanie w Chromium jest zaimplementowane w taki sposób, że obrazy prawdopodobnie zostaną załadowane, gdy będą widoczne, nadal istnieje niewielka szansa, że mogą jeszcze nie zostać załadowane. W takim przypadku brakujące width i height atrybuty na takich obrazach zwiększają ich wpływ na skumulowane przesunięcie układu.

Obrazy zdefiniowane za pomocą elementu <picture> mogą być również leniwie ładowane:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" loading="lazy">
</picture>

Although a browser will decide which image to load from any of the <source> elements, the loading attribute only needs to be included to the fallback <img> element.

Unikaj leniwego ładowania obrazów, które znajdują się w pierwszej widocznej rzutni #

Należy unikać ustawiania loading=lazy dla obrazów, które znajdują się w pierwszej widocznej rzutni. Jest to szczególnie istotne w przypadku obrazów LCP. Więcej informacji można znaleźć w artykule Skutki zbyt leniwego ładowania na wydajność.

Zaleca się, aby dodawać loading=lazy tylko do obrazów, które są umieszczone poniżej strony widocznej na ekranie, jeśli to możliwe. Obrazy, które są chętnie ładowane, można pobrać od razu, natomiast obrazy, które są ładowane leniwie, przeglądarka musi obecnie czekać, aż dowie się, gdzie obraz znajduje się na stronie, co zależy od IntersectionObserver tego, czy jest dostępny.

Ogólnie rzecz biorąc, wszystkie obrazy w rzutni powinny być chętnie ładowane przy użyciu ustawień domyślnych przeglądarki. Nie trzeba określaćloading=eager, aby tak było w przypadku obrazów w rzutni.

<!-- visible in the viewport -->

<img src="product-1.jpg" alt="..." width="200" height="200">

<img src="product-2.jpg" alt="..." width="200" height="200">

<img src="product-3.jpg" alt="..." width="200" height="200">

<!-- offscreen images -->


<img src="product-4.jpg" loading="lazy" alt="..." width="200" height="200">

<img src="product-5.jpg" loading="lazy" alt="..." width="200" height="200">

<img src="product-6.jpg" loading="lazy" alt="..." width="200" height="200">

Graceful degradation #

Przeglądarki, które jeszcze nie obsługują tego loading atrybutu, zignorują jego obecność. Podczas gdy te przeglądarki oczywiście nie uzyskają korzyści z leniwego ładowania, w tym atrybut nie ma na nie negatywnego wpływu.

FAQ #

Czy planowane jest automatyczne leniwe ładowanie obrazów w Chrome? #

Wcześniej Chromium automatycznie leniwie ładował wszystkie obrazy, które dobrze nadawały się do odroczenia, jeśli tryb Lite był włączony w Chrome na Androida, a loading atrybut nie był dostarczany lub ustawiony jako loading="auto". Jednak tryb Lite został wycofany (podobnie jak niestandardowy loading="auto") i obecnie nie ma planów automatycznego leniwego ładowania obrazów w Chrome.

Czy mogę zmienić odległość obrazu, aby wyzwolić ładowanie? #

Te wartości są zakodowane na stałe i nie można ich zmienić za pomocą interfejsu API. Mogą się one jednak zmienić w przyszłości, ponieważ przeglądarki eksperymentują z różnymi odległościami progowymi i zmiennymi.

Czy obrazy tła CSS mogą korzystać z tego loading atrybutu? #

Nie, obecnie można go używać tylko z <img> tagami.

Czy istnieje wada leniwego ładowania obrazów znajdujących się w rzutni urządzenia? #

Bezpieczniej jest unikać umieszczania loading=lazy obrazów w części strony widocznej na ekranie, ponieważ Chrome nie ładuje loading=lazy wstępnie obrazów do skanera. Aby uzyskać więcej informacji,

zobacz Unikanie leniwego ładowania obrazów znajdujących się w pierwszej widocznej rzutni. Jak atrybut loading działa z obrazami, które znajdują się w rzutni, ale nie są od razu widoczne (na przykład: za karuzelą lub ukryte przez CSS dla niektórych rozmiarów ekranu)? #

Użycie loading="lazy" może zapobiec ich załadowaniu, gdy nie są widoczne, ale znajdują się w obliczonej odległości. Na przykład Chrome, Safari i Firefox nie wczytują obrazów przy użyciu display: none; stylizacji – ani w elemencie image, ani w elemencie nadrzędnym. Jednak inne techniki ukrywania obrazów — takie jak używanie opacity:0 stylów — nadal będą powodować wczytywanie obrazów. Zawsze dokładnie testuj implementację, aby upewnić się, że działa zgodnie z przeznaczeniem.

Co zrobić, jeśli używam już biblioteki innej firmy lub skryptu do leniwego ładowania obrazów? #

Dzięki pełnej obsłudze natywnego leniwego ładowania dostępnego teraz w nowoczesnych przeglądarkach, możesz ponownie rozważyć, czy nadal potrzebujesz biblioteki lub skryptu innej firmy do leniwego ładowania obrazów.

Jednym z powodów, dla których warto nadal korzystać z biblioteki loading="lazy" innej firmy, jest zapewnienie polyfill dla przeglądarek, które nie obsługują tego atrybutu, lub większa kontrola nad wyzwalaniem leniwego ładowania.

Jak obsługiwać przeglądarki, które nie obsługują leniwego ładowania? #

Utwórz polyfill lub użyj biblioteki innej firmy, aby leniwie ładować obrazy w witrynie. Właściwość loading może służyć do wykrywania, czy funkcja jest obsługiwana w przeglądarce:

if ('loading' in HTMLImageElement.prototype) {

  // supported in browser

} else {

  // fetch polyfill/third-party library

}

For example, lazysizes is a popular JavaScript lazy loading library. You can detect support for the loading attribute to load lazysizes as a fallback library only when loading isn't supported. This works as follows:

  • Zamień <img src> na <img data-src> , aby uniknąć chętnego obciążenia w nieobsługiwanych przeglądarkach. Jeśli atrybut loading jest obsługiwany, zamień data-src na src.
  • Jeśli loading nie jest obsługiwany, załaduj rezerwowy (lazysizes) i zainicjuj go. Zgodnie z dokumentami lazysizes, używasz klasy lazyload jako sposobu na wskazanie leniwym rozmiarom, które obrazy mają być leniwie ładowane.
<!-- Let's load this in-viewport image normally -->

<img src="hero.jpg" alt="…">

<!-- Let's lazy-load the rest of these images -->

<img data-src="unicorn.jpg" alt="…" loading="lazy" class="lazyload">

<img data-src="cats.jpg" alt="…" loading="lazy" class="lazyload">

<img data-src="dogs.jpg" alt="…" loading="lazy" class="lazyload">

<script>

if ('loading' in HTMLImageElement.prototype) {

const images = document.querySelectorAll('img[loading="lazy"]');

images.forEach(img => {

img.src = img.dataset.src;

});

} else {

// Dynamically import the LazySizes library

const script = document.createElement('script');

script.src = 'https://cdnjs.cloudflare.com/ajax/libs/lazysizes/5.1.2/lazysizes.min.js';

document.body.appendChild(script);

}

</script>

Here's a demo of this pattern. Try it out in an older browser to see the fallback in action.

Czy leniwe ładowanie elementów iframe jest również obsługiwane w Chrome? #

Obsługa przeglądarek

  • chrome 77, obsługiwane 77
  • firefox, Nieobsługiwane ×
  • krawędź 79, Obsługiwane 79
  • safari 16.4, obsługiwane 16.4

<iframe loading=lazy> has also been standardized and is already implemented in Chromium. This allows you to lazy-load iframes using the loading attribute. See this dedicated article about iframe lazy-loading for more information.

W jaki sposób leniwe ładowanie na poziomie przeglądarki wpływa na reklamy na stronie internetowej? #

Wszystkie reklamy wyświetlane użytkownikowi w postaci obrazu lub iframe leniwie ładują się tak jak każdy inny obraz lub element iframe.

Jak obsługiwane są obrazy podczas drukowania strony internetowej? #

Wszystkie obrazy i elementy iframe są natychmiast ładowane, jeśli strona jest drukowana. Zobacz numer #875403 po szczegóły.

Czy Lighthouse rozpoznaje leniwe ładowanie na poziomie przeglądarki? #

Wcześniejsze wersje Lighthouse nadal podkreślały, że strony używane loading=lazy na obrazach wymagają strategii ładowania obrazów poza ekranem. Lighthouse 6.0 i nowsze lepsze czynniki w podejściach do leniwego ładowania obrazu poza ekranem, które mogą używać różnych progów, co pozwala im przejść audyt odroczenia obrazów poza ekranem .

Wniosek #

Pieczenie w obsłudze leniwego ładowania obrazów może znacznie ułatwić poprawę wydajności stron internetowych.

Czy zauważasz jakieś nietypowe zachowanie po włączeniu tej funkcji w Chrome? Zgłoś błąd!

Comments

No comments yet
Yurij Finiv

Yurij Finiv

Full stack

O

Professional Fullstack Developer with extensive experience in website and desktop application development. Proficient in a wide range of tools and technologies, including Bootstrap, Tailwind, HTML5, CSS3, PUG, JavaScript, Alpine.js, jQuery, PHP, MODX, and Node.js. Skilled in website development using Symfony, MODX, and Laravel. Experience: Contributed to the development and translation of MODX3 i...

O autorze CrazyBoy49z
WORK EXPERIENCE
Kontakt
Ukraine, Lutsk
+380979856297