Skutki zbyt częstego leniwego ładowania

Porady oparte na danych dotyczące wolnego wczytywania obrazów z uwzględnieniem podstawowych wskaźników internetowych.

Łagodne wczytywanie to technika, która opóźnia pobieranie zasobu do momentu, gdy jest on potrzebny, aby oszczędzać dane i zmniejszać współzawodnictwo w sieci o najważniejsze zasoby. W 2019 roku stał się standardem internetowym, a obecnie loading="lazy" dla obrazów jest obsługiwany przez większość popularnych przeglądarek.

W tym przewodniku opisujemy, jak za pomocą publicznie dostępnych danych o przejrzystości w internecie i eksperymentów A/B analizowaliśmy wdrażanie i charakterystykę wydajności leniwego wczytywania obrazów na poziomie przeglądarki. Nasze badania wykazały, że ładowanie opóźnione może być niesamowicie skutecznym narzędziem do zmniejszania liczby niepotrzebnych bajtów obrazów, ale nadmierne korzystanie z tego rozwiązania może negatywnie wpływać na wydajność. Ta analiza pokazuje, że szybsze wczytywanie obrazów w pierwszym widocznym obszarze strony, a pozostałe elementy wczytując z opóźnieniem, może przynieść najlepsze efekty: mniejszą liczbę wczytywanych bajtów i lepsze wyniki w ramach podstawowych wskaźników internetowych.

Rozpowszechnienie

Według najnowszych danych z archiwum HTTP wbudowane opóźnione wczytywanie obrazów używa 29% witryn, a liczba ta szybko rośnie.

Wykres kołowy pokazujący, że 84,1% użytkowników korzysta z łagodnego wczytywania w WordPressie, 2,3% z innych systemów CMS, a 13,5% z systemów innych niż CMS.
Podział typów witryn, które korzystają z opóźnionego wczytywania obrazów na poziomie przeglądarki. (źródło).

Wysyłanie zapytań do nieprzetworzonych danych w projekcie HTTP Archive pozwala nam lepiej zrozumieć, jakie rodzaje witryn przyczyniają się do wdrażania tej funkcji: 84% witryn, które korzystają z opóźnionego wczytywania obrazów na poziomie przeglądarki, używa WordPressa, 2% innego systemu CMS, a pozostałe 14% nie korzysta z żadnego znanego systemu CMS. Wyniki wyraźnie pokazują, że WordPress jest liderem w zakresie wdrażania.

Wykres czasowy przedstawiający stosowanie leniwego wczytywania. WordPress jest dominującym systemem w porównaniu z innymi systemami CMS i systemami bez CMS, a proporcje są podobne do tych z poprzedniego wykresu. W okresie od lipca 2020 r. do czerwca 2021 r. całkowita liczba użytkowników wzrosła z 1% do 17%.
Podział typów witryn, które korzystają z opóźnionego wczytywania obrazów na poziomie przeglądarki. (źródło).

Warto też zwrócić uwagę na tempo wdrażania. Rok temu, w lipcu 2020 r., witryny WordPress korzystające z opóźnionego wczytywania stanowiły dziesiątki tysięcy witryn w korpusie około 6 mln (1% ogółem). Od tego czasu leniwy sposób ładowania został zaimplementowany w ponad milionie witryn korzystających z WordPressa (14% ogółem).

Korelacja

Więcej informacji znajdziesz w archiwum HTTP. Możesz porównać, jak działają strony z łatwym wczytywaniem obrazu na poziomie przeglądarki i bez niego za pomocą 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 prawdziwych użytkowników, a nie z testów syntetycznych w laboratorium. Na wykresie poniżej zastosowano wykres pudełkowy i oświadowczy, aby zilustrować rozkłady wartości LCP w 75. percentylu dla poszczególnych stron: linie reprezentują 10. i 90. percentyl, a pudła – 25. i 75. percentyl.

Wykres pudełkowy pokazujący 10., 25., 75. i 90. percentyl strony, która korzysta z opóźnionego wczytywania obrazów na poziomie przeglądarki lub nie korzysta z tego mechanizmu. W porównaniu z tym czas LCP stron, które nie korzystają z AMP, jest krótszy niż w przypadku stron, które z niego korzystają.
Rozkład 75 procentyla LCP wszystkich stron z podziałem na to, czy korzystają one z opóźnionego wczytywania obrazów na poziomie przeglądarki. (źródło).

Średnia strona bez leniwego wczytywania ma wartość LCP w 75. percentylu wynoszącą 2922 ms, a z leniwym wczytywaniem – 3546 ms. Ogólnie rzecz biorąc, witryny korzystające z leniwego ładowania mają gorsze wyniki LCP.

Należy pamiętać, że są to wyniki korelacyjne i niekoniecznie wskazują, że wczytywanie opóźnione jest przyczyną wolniejszego działania. Teoretycznie, jeśli witryny WordPress są nieco wolniejsze i biorą one udział w większym stopniu w grupie użytkowników korzystających z opóźnionego wczytywania, może to tłumaczyć różnicę. Aby wyeliminować tę zmienność, możesz skupić się na witrynach WordPress.

Wykres pudełkowy pokazujący 10., 25., 75. i 90. percentyl na stronach WordPress, które korzystają z opóźnionego wczytywania obrazów na poziomie przeglądarki lub nie korzystają z tej funkcji. W porównaniu z poprzednim wykresem rozkład LCP stron, które go nie wykorzystują, jest szybszy niż tych, które go wykorzystują.
Rozkład wartości LCP na poziomie 75 procentyla dla stron WordPressa, z podziałem na strony, które korzystają z leniwego ładowania obrazów na poziomie przeglądarki. (źródło).

Ten sam schemat pojawia się niestety również w przypadku stron WordPress, które korzystają z leniwego ładowania. Ich LCP jest zwykle wolniejsze. Średnia strona WordPress bez opóźnionego wczytywania ma wartość LCP na poziomie 75. percentyla wynoszącą 3495 ms, w porównaniu z 3768 ms dla średniej strony z opóźnionym wczytywaniem.

Nie dowodzi to jednak, że opóźnione wczytywanie powoduje spowolnienie stron, ale jego użycie wiąże się z mniejszymi osiągami. Aby spróbować odpowiedzieć na pytanie o przyczynowość, przeprowadzono test A/B w laboratorium.

Skuteczność przyczynowa

Celem testu A/B było udowodnienie lub obalenie hipotezy, że wbudowane leniwie wczytywanie obrazów w rdzenia WordPressa powoduje wolniejsze działanie LCP i mniejszą liczbę bajtów obrazu. W ramach testu wykorzystano witrynę demonstracyjną WordPressa z motywem twentytwentyone. Testowaliśmy zarówno typy strony z archiwum, jak i pojedyncze strony, które są podobne do stron głównych i artykułów, na komputerach oraz na emulowanych urządzeniach mobilnych za pomocą narzędzia WebPageTest. Przetestowano wszystkie kombinacje stron z włączonym i wyłączonym ładowaniem opóźnionym. Każdy test został przeprowadzony 9 razy, aby uzyskać medianę wartości LCP i liczbę bajtów obrazu.

Serie domyślna wyłączone 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 WordPress.

Te wyniki porównują średnie wartości LCP w milisekundach w przypadku testów na archiwum i pojedynczych stronach na komputery i urządzenia mobilne. Po wyłączeniu ładowania opóźnionego na stronach archiwalnych wskaźnik LCP poprawił się znacząco. W przypadku pojedynczych stron różnica była jednak mniejsza.

Wyłączenie leniwego ładowania powoduje, że poszczególne strony wczytują się nieco szybciej. Różnica w LCP jest jednak mniejsza niż jedno odchylenie standardowe zarówno w przypadku testów na komputery, jak i na urządzenia mobilne, więc można ją przypisać odchyleniu i uznać za neutralną. W przypadku stron archiwalnych różnica jest zbliżona do 2–3 odchyleń standardowych.

Serie domyślna wyłączone 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 wczytywania obrazu na poziomie przeglądarki na przykładowych stronach WordPressa.

Te wyniki porównują średnią liczbę bajtów obrazu (w KB) w przypadku każdego testu. Zgodnie z oczekiwaniami opóźnione wczytywanie ma bardzo wyraźny pozytywny wpływ na zmniejszenie liczby bajtów obrazu. Jeśli prawdziwy użytkownik przewinie całą stronę, wszystkie obrazy zostaną załadowane, gdy znajdą się w widocznym obszarze. Te wyniki pokazują jednak wyższą wydajność początkowego wczytania strony.

Podsumowując wyniki testu A/B, należy stwierdzić, że technika ładowania opóźnionego stosowana przez WordPressa wyraźnie pomaga zmniejszyć liczbę bajtów obrazu kosztem opóźnienia LCP.

Testowanie poprawki

W przypadku tego eksperymentu najważniejszym aspektem obecnej implementacji leniwego ładowania w WordPressie jest to, że leniwie ładuje obrazy w obszarze widocznym (powyżej linii zagięcia). W poście na blogu CMS zaznaczamy, że należy unikać takiego wzorca, ale dane z eksperymentu wskazywały wówczas, że wpływ na LCP jest minimalny i warto uprościć implementację w rdzenia WordPress.

Na podstawie tych nowych danych stworzono eksperymentalne rozwiązanie, które zapobiega wczytywaniu leniwie obrazów znajdujących się powyżej paska przewijania. Rozwiązanie zostało przetestowane w tych samych warunkach co pierwszy test A/B.

Serie domyślna wyłączone Napraw Różnica w stosunku do wartości domyślnej Różnica w stosunku do wyłączenia
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) dzięki proponowanemu rozwiązaniu problemu leniwego ładowania obrazów na poziomie przeglądarki na przykładowych stronach WordPressa.

Te wyniki są znacznie bardziej obiecujące. Lazy loading tylko obrazów poniżej linii wzroku odwraca regresję LCP i może nawet przynieść niewielkie ulepszanie w porównaniu z całkowitym wyłączeniem lazy loadingu. Jak to może być szybsze niż nieużywanie lazy loadingu? Jednym z wyjaśnień jest to, że nie wczytywanie obrazów poniżej pola widzenia zmniejsza konkurencję o zasoby sieci w przypadku obrazu LCP, co pozwala na jego szybsze wczytanie.

Serie domyślna wyłączone Napraw Różnica w stosunku do wartości domyślnej Różnica w stosunku do wyłączenia
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) dzięki proponowanemu rozwiązaniu problemu opóźnionego wczytywania obrazu na poziomie przeglądarki na przykładowych stronach WordPressa.

W przypadku bajtów obrazu poprawka nie powoduje żadnych zmian w porównaniu z działaniem domyślnym. To świetna wiadomość, ponieważ była to jedna z zalet obecnego podejścia.

Ta poprawka ma pewne ograniczenia. WordPress określa, które obrazy mają być wczytywane z opóźnieniem po stronie serwera, co oznacza, że nie wie nic o rozmiarze widocznego obszaru użytkownika ani o tym, czy obrazy są wczytywane w ramach tego obszaru. Aby to zrobić, używa heurystyki dotyczącej względnej lokalizacji obrazów w znacznikach, aby określić, czy obraz wczytuje się w obszarze widoku. Jeśli obraz jest pierwszym wyróżnionym obrazem na stronie lub pierwszym obrazem w głównej treści, zakłada się, że znajduje się on powyżej lub blisko zagięcia i nie będzie ładowany z opóźnieniem.

Warunki na poziomie strony, takie jak liczba słów w tytule lub ilość tekstu w akapitach we wczesnej części głównej treści, mogą wpływać na to, czy obraz jest widoczny 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żywanie linków kotwicy, które zmieniają pozycję przewijania strony.

Z tego powodu ważne jest, aby pamiętać, że ta poprawka jest skalibrowana tylko pod kątem zapewnienia dobrej skuteczności w ogólnym przypadku. Aby wyniki były odpowiednie do wszystkich rzeczywistych scenariuszy, może być konieczne dostosowanie ich.

Implementacja

Teraz, gdy znaleźliśmy lepszy sposób na opóźnione wczytywanie obrazów, jak strony mogą zacząć z niego korzystać? Zmiana o najwyższym priorytecie to przesłanie poprawki do rdzenia WordPressa w celu wdrożenia eksperymentalnej poprawki. W poście na blogu na temat nieaktywnych zasobów na poziomie przeglądarki w przypadku systemów CMS zostaną również wprowadzone zmiany, aby wyjaśnić negatywne skutki wczytywania nieaktywnych zasobów powyżej progu i pokazać, jak systemy CMS mogą używać heurystyki, aby uniknąć tego problemu.

Te sprawdzone metody są przydatne dla wszystkich web developerów, dlatego warto też oznaczyć w narzędziach takich jak Lighthouse antywzorce dotyczące leniwego ładowania. Jeśli chcesz śledzić postępy w realizacji tego audytu, zapoznaj się z prośbą o dodanie funkcji w GitHub. Do tego czasu deweloperzy mogą dodać do danych polowych bardziej szczegółowe logi, aby znaleźć elementy LCP wczytywane z opóźnieniem.

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 sprawdzi ostatni element LCP i zarejestruje ostrzeżenie, jeśli został on załadowany z opóźnieniem.

Pokazuje to też słabą stronę techniki leniwego ładowania i potencjał do ulepszenia interfejsu API na poziomie platformy. Na przykład w Chromium jest otwarty problem dotyczący eksperymentowania z domyślnym wczytywaniem kilku pierwszych obrazów, podobnie jak w przypadku poprawki, mimo atrybutu loading.

Podsumowanie

Jeśli Twoja witryna korzysta z opóźnionego wczytywania obrazów na poziomie przeglądarki, sprawdź, jak jest ono zaimplementowane, i przeprowadź testy A/B, aby lepiej poznać koszty związane z tym rozwiązaniem. Może to być korzystne w przypadku szybszego wczytywania obrazów powyżej zagięcia. Jeśli masz witrynę WordPress, wkrótce powinna pojawić się łatka do głównego kodu WordPress. Jeśli używasz innego systemu CMS, upewnij się, że jego twórcy są świadomi potencjalnych problemów z wydajnością opisanych w tym artykule.

Wypróbowywanie stosunkowo nowych interfejsów API platform internetowych może wiązać się z zaryskiem ryzyka i możliwościami. Nie bez powodu nazywamy je zaawansowanymi funkcjami. Zaczynamy już rozumieć, jak trudne jest opóźnione wczytywanie obrazów na poziomie przeglądarki, ale widzimy też zalety takiego rozwiązania, które pozwala uzyskać lepszą wydajność.

Zdjęcie autorstwa Frankie LopezUnsplash