Skutki zbyt częstego leniwego ładowania

Oparte na danych porady dotyczące leniwego ładowania obrazów z uwzględnieniem podstawowych wskaźników internetowych.

Leniwe ładowanie to technika, która opóźnia pobieranie zasobu do momentu, gdy jest on potrzebny. Pozwala to oszczędzać dane i zmniejszać obciążenie sieci w przypadku kluczowych zasobów. W 2019 roku stał się standardem internetowym, a obecnie atrybut loading="lazy" dla obrazów jest obsługiwany przez większość popularnych przeglądarek.

Ten przewodnik podsumowuje, jak analizowano publicznie dostępne dane dotyczące przejrzystości w internecie i testy A/B ad hoc, aby zrozumieć charakterystykę wdrażania i skuteczności leniwego ładowania obrazów na poziomie przeglądarki. Z ustaleń wynika, że leniwe ładowanie może być niezwykle skutecznym narzędziem do zmniejszania niepotrzebnych bajtów obrazów, ale nadmierne korzystanie z niego może negatywnie wpłynąć na wydajność. Ta analiza pokazuje, że szybsze ładowanie obrazów w początkowym obszarze widocznego ekranu i swobodne leniwe ładowanie pozostałych obrazów może przynieść najlepsze rezultaty: mniejszą liczbę załadowanych bajtów i lepsze Core Web Vitals.

Rozpowszechnienie

Według najnowszych danych z HTTP Archive wbudowane leniwe ładowanie obrazów jest używane przez 29% witryn, a jego popularność szybko rośnie.

Wykres kołowy pokazujący, że WordPress stanowi 84,1% przypadków wdrożenia leniwego ładowania, inne systemy CMS – 2,3%, a systemy inne niż CMS – 13,5%.
Zestawienie typów witryn, które korzystają z leniwego ładowania obrazów na poziomie przeglądarki. (źródło).

Zapytania o nieprzetworzone dane w projekcie HTTP Archive dają nam lepszy obraz tego, jakie rodzaje witryn przyczyniają się do wzrostu popularności: 84% witryn, które używają leniwego ładowania obrazów na poziomie przeglądarki, korzysta z WordPressa, 2% używa innego systemu CMS, a pozostałe 14% nie używa znanego systemu CMS. Te wyniki wyraźnie pokazują, że WordPress jest liderem pod względem wdrażania.

Wykres szeregów czasowych przedstawiający wdrażanie leniwego ładowania, na którym WordPress jest dominującym graczem w porównaniu z innymi systemami CMS i innymi systemami, z podobnymi proporcjami jak na poprzednim wykresie. Wykres pokazuje, że od lipca 2020 r. do czerwca 2021 r. łączny odsetek użytkowników szybko wzrósł z 1% do 17%.
Zestawienie typów witryn, które korzystają z leniwego ładowania obrazów na poziomie przeglądarki. (źródło).

Warto też zwrócić uwagę na tempo wdrażania. W lipcu 2020 r. witryny WordPress, które korzystają z leniwego ładowania, stanowiły kilkadziesiąt tysięcy witryn w korpusie liczącym około 6 milionów (1% całości). Od tego czasu leniwe ładowanie zostało wdrożone w ponad milionie witryn korzystających z WordPressa (14% całości).

Skuteczność korelacyjna

Analizując dokładniej dane HTTP Archive, można porównać, jak strony z leniwym ładowaniem obrazów na poziomie przeglądarki i bez niego wypadają pod względem wskaźnika największego wyrenderowania treści (LCP). Dane LCP pochodzą z Raportu na temat użytkowania Chrome (CrUX), który zawiera dane o wrażeniach rzeczywistych użytkowników, a nie z testów syntetycznych w laboratorium. Na wykresie poniżej użyto wykresu pudełkowego do wizualizacji rozkładu 75 percentyla LCP każdej strony: linie reprezentują 10 i 90 percentyl, a pudełka – 25 i 75 percentyl.

Wykres pudełkowy przedstawiający 10, 25, 75 i 90 percentyl dla stron, które używają i nie używają leniwego ładowania obrazów na poziomie przeglądarki. Dla porównania, rozkład LCP stron, które nie korzystają z tej funkcji, jest szybszy niż stron, które z niej korzystają.
Rozkład 75 percentyla LCP wszystkich stron z podziałem na to, czy używają leniwego ładowania obrazów na poziomie przeglądarki. (źródło).

W przypadku mediany stron bez leniwego ładowania 75 percentyl LCP wynosi 2922 milisekundy, a w przypadku mediany stron z leniwym ładowaniem – 3546 milisekund. Ogólnie rzecz biorąc, witryny, które korzystają z leniwego ładowania, mają zwykle gorsze wyniki LCP.

Warto podkreślić, że są to wyniki korelacyjne i niekoniecznie wskazują na leniwe ładowanie jako przyczynę wolniejszego działania. Jeśli witryny WordPress są nieco wolniejsze i stanowią dużą część kohorty leniwego ładowania, może to wyjaśniać różnicę. Aby wyeliminować tę zmienność, można skupić się wyłącznie na witrynach WordPress.

Wykres pudełkowy przedstawiający 10, 25, 75 i 90 percentyl stron WordPress, które używają i nie używają leniwego ładowania obrazów na poziomie przeglądarki. Dla porównania, rozkład LCP stron, które nie korzystają z tej funkcji, jest szybszy niż w przypadku stron, które z niej korzystają, podobnie jak na poprzednim wykresie.
Rozkład 75 percentyla LCP stron WordPressa z podziałem na strony, które używają leniwego ładowania obrazów na poziomie przeglądarki, i te, które go nie używają. (źródło).

Niestety ten sam wzorzec pojawia się, gdy analizujemy strony WordPressa – te, które używają leniwego ładowania, mają zwykle gorsze wyniki LCP. Mediana strony WordPress bez leniwego ładowania ma LCP na poziomie 75 percentyla wynoszący 3495 milisekund, podczas gdy mediana strony z leniwym ładowaniem ma LCP na poziomie 3768 milisekund.

Nie dowodzi to, że leniwe ładowanie powoduje wolniejsze działanie stron, ale jego stosowanie zbiega się z gorszą wydajnością. Aby spróbować odpowiedzieć na pytanie o związek przyczynowo-skutkowy, przeprowadzono laboratoryjny test A/B.

Skuteczność przyczynowa

Celem testu A/B było potwierdzenie lub obalenie hipotezy, że wbudowane leniwe ładowanie obrazów, zaimplementowane w rdzeniu WordPressa, powoduje wolniejsze działanie LCP i mniejszą liczbę bajtów obrazu. Metodologia polegała na przetestowaniu demonstracyjnej witryny WordPress z motywem twentytwentyone. Przetestowano zarówno typy stron archiwum, jak i pojedynczych stron, które są podobne do stron głównych i stron artykułów, na komputerach i emulowanych urządzeniach mobilnych za pomocą narzędzia WebPageTest. Przetestowano każdą kombinację stron z włączonym i wyłączonym leniwym ładowaniem, a każdy test został przeprowadzony 9 razy, aby uzyskać medianę wartości LCP i liczbę bajtów obrazu.

Serie domyślna wyłączono Różnica w stosunku do wartości domyślnej
twentytwentyone-archive-desktop 2029 1759 -13%
twentytwentyone-archive-mobile 1657 1403 –15%
twentytwentyone-single-desktop 1655 1726 4%
twentytwentyone-single-mobile 1352 1384 2%
Zmiana LCP (ms) po wyłączeniu leniwego ładowania obrazów na poziomie przeglądarki na przykładowych stronach WordPressa.

Te wyniki porównują medianę LCP w milisekundach w przypadku testów na stronach archiwum i pojedynczych stronach na komputerach i urządzeniach mobilnych. Po wyłączeniu leniwego ładowania na stronach archiwum wskaźnik LCP znacznie się poprawił. W przypadku pojedynczych stron różnica była jednak mniejsza.

Wyłączenie leniwego ładowania wydaje się nieco przyspieszać wczytywanie pojedynczych stron. Jednak różnica w LCP jest mniejsza niż 1 odchylenie standardowe zarówno w przypadku testów na komputerach, jak i na urządzeniach mobilnych, więc można ją przypisać zmienności i uznać zmianę za neutralną. Dla porównania, różnica w przypadku stron archiwum jest bliższa 2–3 odchyleniom standardowym.

Serie domyślna wyłączono Różnica w stosunku do wartości domyślnej
twentytwentyone-archive-desktop 577 1173 103%
twentytwentyone-archive-mobile 172 378 120%
twentytwentyone-single-desktop 301 850 183%
twentytwentyone-single-mobile 114 378 233%
Zmiana liczby bajtów obrazu (KB) po wyłączeniu leniwego ładowania obrazów na poziomie przeglądarki na przykładowych stronach WordPressa.

Te wyniki porównują medianę liczby bajtów obrazu (w KB) w każdym teście. Zgodnie z oczekiwaniami leniwe ładowanie ma bardzo wyraźny pozytywny wpływ na zmniejszenie liczby bajtów obrazów. Gdyby prawdziwy użytkownik przewinął całą stronę, wszystkie obrazy i tak zostałyby wczytane, gdyby znalazły się w obszarze widocznym, ale te wyniki pokazują lepszą wydajność początkowego wczytywania strony.

Podsumowując wyniki testu A/B, technika leniwego ładowania używana przez WordPressa wyraźnie pomaga zmniejszyć liczbę bajtów obrazu kosztem opóźnienia LCP.

Testowanie poprawki

Najważniejszym aspektem obecnej implementacji leniwego ładowania w WordPressie w przypadku tego eksperymentu jest to, że leniwie ładuje on obrazy w widocznym obszarze (w części strony widocznej na ekranie). W poście na blogu CMS wspomniano, że jest to wzorzec, którego należy unikać, ale dane eksperymentalne wskazywały wówczas, że wpływ na LCP był minimalny i warto było uprościć implementację w rdzeniu WordPressa.

Na podstawie tych nowych danych utworzono eksperymentalną poprawkę, która pozwala uniknąć leniwego ładowania obrazów w części strony widocznej na ekranie. Poprawka została przetestowana w tych samych warunkach co pierwszy test A/B.

Serie domyślna wyłączono rozwiązanie problemu Różnica w stosunku do wartości domyślnej Różnica w porównaniu z wyłączonymi
twentytwentyone-archive-desktop 2029 1759 1749 -14% -1%
twentytwentyone-archive-mobile 1657 1403 1352 –18% -4%
twentytwentyone-single-desktop 1655 1726 1676 1% -3%
twentytwentyone-single-mobile 1352 1384 1342 -1% -3%
Zmiana LCP (ms) po zastosowaniu proponowanej poprawki dotyczącej leniwego ładowania obrazów na poziomie przeglądarki na przykładowych stronach WordPressa.

Te wyniki są znacznie bardziej obiecujące. Leniwe ładowanie tylko obrazów w części strony widocznej po przewinięciu powoduje całkowite odwrócenie regresji LCP, a być może nawet niewielką poprawę w porównaniu z całkowitym wyłączeniem leniwego ładowania. Jak może być szybsze niż brak leniwego ładowania? Jednym z wyjaśnień jest to, że dzięki temu, że nie są wczytywane obrazy w części strony widocznej po przewinięciu, obraz LCP nie musi konkurować o zasoby sieciowe, co umożliwia jego szybsze wczytanie.

Serie domyślna wyłączono rozwiązanie problemu Różnica w stosunku do wartości domyślnej Różnica w porównaniu z wyłączonymi
twentytwentyone-archive-desktop 577 1173 577 0% -51%
twentytwentyone-archive-mobile 172 378 172 0% -54%
twentytwentyone-single-desktop 301 850 301 0% –65%
twentytwentyone-single-mobile 114 378 114 0% -70%
Zmiana liczby bajtów obrazu (KB) po zastosowaniu proponowanej poprawki dotyczącej leniwego ładowania obrazów na poziomie przeglądarki na przykładowych stronach WordPressa.

Jeśli chodzi o bajty obrazu, poprawka nie wprowadza żadnych zmian w porównaniu z działaniem domyślnym. To świetnie, ponieważ była to jedna z zalet obecnego podejścia.

To rozwiązanie ma pewne ograniczenia. WordPress określa, które obrazy mają być ładowane leniwie po stronie serwera, co oznacza, że nie ma informacji o rozmiarze widocznego obszaru użytkownika ani o tym, czy obrazy są początkowo ładowane w jego obrębie. Dlatego poprawka wykorzystuje heurystykę dotyczącą względnej lokalizacji obrazów w znacznikach, aby oszacować, czy obraz ładuje się w widocznym obszarze. Jeśli obraz jest pierwszym polecanym obrazem na stronie lub pierwszym obrazem w głównej treści, zakłada się, że znajduje się on w części strony widocznej na ekranie lub blisko niej i nie będzie ładowany leniwie.

Warunki na poziomie strony, takie jak liczba słów w nagłówku lub ilość tekstu w akapitach na początku głównej treści, mogą wpływać na to, czy obraz znajduje się w widocznym obszarze. Istnieją też warunki na poziomie użytkownika, które mogą wpływać na dokładność heurystyki, zwłaszcza rozmiar widocznego obszaru i użycie linków do kotwic, które zmieniają pozycję przewijania strony.

Z tego powodu należy pamiętać, że poprawka jest skalibrowana tak, aby zapewniać dobrą wydajność w ogólnych przypadkach, i może wymagać dostrojenia, aby te wyniki miały zastosowanie we wszystkich rzeczywistych scenariuszach.

Implementacja

Teraz, gdy znaleźliśmy lepszy sposób na leniwe ładowanie obrazów, który pozwala zaoszczędzić miejsce i przyspieszyć LCP, jak witryny mogą zacząć go używać? Najważniejszą zmianą jest przesłanie poprawki do rdzenia WordPressa, aby wdrożyć eksperymentalną poprawkę. Zaktualizujemy też wskazówki w poście na blogu Leniwe ładowanie na poziomie przeglądarki w systemach CMS, aby wyjaśnić negatywne skutki leniwego ładowania w części strony widocznej na ekranie i sposób, w jaki systemy CMS mogą używać heurystyki, aby go uniknąć.

Te sprawdzone metody dotyczą wszystkich programistów stron internetowych, dlatego warto też oznaczać antywzorce leniwego ładowania w narzędziach takich jak Lighthouse. Jeśli chcesz śledzić postępy w zakresie tej kontroli, zapoznaj się z prośbą o dodanie funkcji na GitHubie. Do tego czasu deweloperzy mogą znaleźć przypadki leniwego ładowania elementów LCP, dodając bardziej szczegółowe logowanie do danych z pola.

new PerformanceObserver((list) => {
  const latestEntry = list.getEntries().at(-1);

  if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
    console.warn('Warning: LCP element was lazy loaded', latestEntry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

Powyższy fragment kodu JavaScript oceni najnowszy element LCP i zarejestruje ostrzeżenie, jeśli został on załadowany leniwie.

Wskazuje to również na słaby punkt techniki leniwego ładowania i potencjalne możliwości ulepszenia interfejsu API na poziomie platformy. Na przykład w Chromium jest otwarty problem dotyczący eksperymentu z natywnym, natychmiastowym wczytywaniem pierwszych kilku obrazów, podobnie jak w przypadku poprawki, pomimo atrybutu loading.

Podsumowanie

Jeśli Twoja witryna korzysta z leniwego ładowania obrazów na poziomie przeglądarki, sprawdź, jak jest ono zaimplementowane, i przeprowadź testy A/B, aby lepiej zrozumieć jego wpływ na wydajność. Może skorzystać na bardziej agresywnym wczytywaniu obrazów w górnej części strony. Jeśli masz witrynę WordPress, wkrótce powinna pojawić się poprawka w rdzeniu WordPressa. Jeśli używasz innego systemu CMS, upewnij się, że jego twórcy wiedzą o potencjalnych problemach z wydajnością opisanych tutaj.

Wypróbowanie stosunkowo nowych interfejsów API platformy internetowej może wiązać się zarówno z ryzykiem, jak i korzyściami – nie bez powodu nazywa się je funkcjami najnowocześniejszymi. Chociaż zaczynamy dostrzegać trudności związane z leniwym ładowaniem obrazów na poziomie przeglądarki, widzimy też zalety korzystania z tej funkcji w celu zwiększenia wydajności.