Wpływ zbyt długiego wczytywania na wydajność

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

Leniwe ładowanie to technika, która opóźnia pobranie zasobu do momentu, aż będzie to potrzebne. Pozwala to zaoszczędzić dane i ograniczyć rywalizację o najważniejsze zasoby w sieci. Stał się standardem internetowym w 2019 r. i obecnie loading="lazy" w przypadku obrazów jest obsługiwany przez większość najpopularniejszych przeglądarek.

Ten przewodnik podsumowuje, jak przeanalizowano zostały publicznie dostępne dane na temat przejrzystości sieci i doraźne testy A/B, które miały pomóc w poznaniu charakterystyki rozpowszechnienia i wydajności leniwego ładowania obrazów na poziomie przeglądarki. Ustaliliśmy, że leniwe ładowanie może być niezwykle skutecznym narzędziem do ograniczania niepotrzebnych bajtów obrazów, ale ich przeciążenie może negatywnie wpłynąć na wydajność. Konkretnie ta analiza pokazuje, że szybsze ładowanie obrazów w pierwszym widocznym obszarze, a jednocześnie leniwe ładowanie reszty, może przynieść korzyści obu stronom: mniejsza liczba wczytywanych bajtów i lepsze podstawowe wskaźniki internetowe.

Rozpowszechnienie

Według najnowszych danych z archiwum HTTP wbudowane leniwe ładowanie obrazów jest wykorzystywane w 29% witryn, a ich popularność gwałtownie rośnie.

Wykres kołowy przedstawiający 84,1% wprowadzenia leniwego ładowania w 84,1%, w przypadku innych systemów CMS – 2,3%, a w przypadku systemów innych niż CMS – 13,5%.
Podział typów witryn, które korzystają z leniwego ładowania obrazów na poziomie przeglądarki. (Źródło).

Wysyłanie zapytań do nieprzetworzonych danych w projekcie HTTP Archive pozwala nam lepiej zorientować się, jakie strony internetowe zyskują popularność: 84% witryn, które wykorzystują leniwe ładowanie obrazów na poziomie przeglądarki, korzysta z WordPressa, 2% innego CMS, a pozostałe 14% nie używa znanego systemu CMS. Te wyniki jasno pokazują, dlaczego WordPress jest liderem pod względem wdrożenia.

Wykres z seriami czasowymi przedstawiający wdrożenie leniwego ładowania, w którym dominuje WordPress w porównaniu z innymi CMS i innymi systemami, w stosunku do poprzedniego wykresu. Wykazuje się, że w okresie od lipca do czerwca 2021 r. całkowite rozpowszechnienie wzrasta z 1% do 17%.
Podział typów witryn, które korzystają z leniwego ładowania obrazów na poziomie przeglądarki. (Źródło).

Warto również spojrzeć na współczynnik rozpowszechnienia. Rok temu w lipcu 2020 roku witryny WordPress, które wykorzystują leniwe ładowanie, stanowiły dziesiątki tysięcy stron w jednym korpusie liczącym około 6 milionów użytkowników (1% wszystkich). Sama metoda leniwego ładowania w WordPressie wzrosła do ponad 1 miliona witryn (14% wszystkich).

Skuteczność korelacyjna

Dokładniejsze informacje o archiwum HTTP pozwala porównać wyniki stron z leniwym ładowaniem obrazów 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), a nie z testów syntetycznych przeprowadzanych w laboratorium. Na tym wykresie przedstawiono wykres typu ramka i wąsko do wizualizacji rozkładu LCP 75 centyla dla każdej strony. Linie reprezentują 10 i 90 centyl, a pola – 25 i 75 centyl.

Wykres typu Box i whisker pokazujący 10, 25, 75 i 90 centyl dla stron, które korzystają z leniwego ładowania obrazów na poziomie przeglądarki lub nie korzystają z nich. Dla porównania w przypadku stron, które nie korzystają z tej funkcji, rozkład LCP jest szybszy niż w przypadku stron, które go nie używają.
Rozkład LCP 75 centyla dla wszystkich stron z podziałem na to, czy używają one leniwego ładowania obrazów na poziomie przeglądarki. (Źródło).

Mediana dla strony bez leniwego ładowania ma 75 centyl LCP równy 2922 milisekundy (dla porównania w przypadku strony mediany z leniwym ładowaniem – 3546 milisekund). Ogólnie rzecz biorąc, witryny z leniwym ładowaniem mają gorszą skuteczność LCP.

Warto zaznaczyć, że są to wyniki korelacyjne, które nie muszą wskazywać, że leniwe ładowanie jest przyczyną wolniejszego działania. Jeśli witryny WordPress są z reguły nieco wolniejsze i uwzględniają wiele elementów w kohorcie z leniwym ładowaniem, może to wyjaśniać tę różnicę. Aby wyeliminować tę zmienność, można zawęzić kierowanie tylko do witryn WordPress.

Wykres typu Box i whisker pokazujący 10, 25, 75 i 90 centyl dla stron WordPress, które korzystają z leniwego ładowania obrazów na poziomie przeglądarki lub nie korzystają z nich. Dla porównania rozkład LCP w przypadku stron, które nie korzystają z tej funkcji, jest szybszy niż w przypadku stron, które go używają, podobnie jak w poprzednim wykresie.
Rozkład LCP 75 centyla stron WordPress z podziałem na to, czy używają one leniwego ładowania obrazów na poziomie przeglądarki. (Źródło).

Niestety ten sam wzorzec może pojawić się przy analizie stron WordPress – te z leniwym ładowaniem mają zwykle wolniejszą wydajność LCP. Mediana dla strony WordPress bez leniwego ładowania ma 75 centyl LCP równy 3495 milisekund, podczas gdy dla strony mediany z leniwym ładowaniem wynosi 3768 milisekund.

To nadal nie dowodzi, że leniwe ładowanie powoduje wolniejsze ładowanie stron, ale korzystanie z niego zbiega się z wolniejszym działaniem. Aby znaleźć odpowiedź na pytanie dotyczące związku przyczynowo-skutkowego, wdrożyliśmy w laboratorium test A/B.

Zasadnicze wyniki

Celem testu A/B było potwierdzenie lub obalenie hipotezy, że wbudowane leniwe ładowanie obrazów (zaimplementowane w rdzeniu WordPressa) powoduje zmniejszenie wydajności LCP i zmniejszenie liczby bajtów obrazu. Wykorzystana metodologia polegała na przetestowaniu demonstracyjnej witryny WordPress z motywem twentytwentyone. Przetestowano zarówno strony archiwum, jak i pojedyncze strony, takie jak strona główna i strona z artykułami, na komputerach oraz emulowane strony mobilne za pomocą narzędzia WebPageTest. Przetestowano każdą kombinację stron z włączonym leniwym ładowaniem i bez niego. Każdy test wykonano 9 razy w celu uzyskania mediany LCP i liczby bajtów obrazu.

Seria default 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) przez wyłączenie leniwego ładowania obrazów na poziomie przeglądarki na przykładowych stronach WordPress.

Te wyniki porównują medianę LCP (w milisekundach) podczas testów w archiwum oraz na pojedynczych stronach w przypadku komputerów i urządzeń mobilnych. Gdy na stronach archiwum wyłączono leniwe ładowanie, wskaźnik LCP znacznie się poprawił. Jednak w przypadku pojedynczych stron nie miało to większego znaczenia.

Wyłączenie leniwego ładowania wydaje się nieco przyśpieszyć wczytywanie pojedynczych stron. Jednak różnica w LCP jest mniejsza niż jedno odchylenie standardowe w testach na komputerach i urządzeniach mobilnych, więc można to przypisać do wariancji i uznać tę zmianę za neutralną. Dla porównania w przypadku stron archiwum różnica jest zbliżona do 2–3 odchyleń standardowych.

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

Te wyniki porównują medianę liczby bajtów obrazu (w KB) w każdym teście. Jak można było oczekiwać, leniwe ładowanie ma bardzo wyraźny pozytywny wpływ na zmniejszenie liczby bajtów obrazu. Gdyby prawdziwy użytkownik przewinął całą stronę, wszystkie obrazy i tak zostałyby wczytane, gdy pojawią się w widocznym obszarze. Wyniki pokazują jednak, że przy początkowym wczytywaniu strony poprawiła się ich wydajność.

Podsumowując wyniki testu A/B: wykorzystywana przez WordPress technika leniwego ładowania pozwala wyraźnie zmniejszyć liczbę bajtów obrazu kosztem opóźnionego LCP.

Testowanie rozwiązania

Najważniejszym aspektem obecnego wdrożenia leniwego ładowania w WordPressie jest to, że ta funkcja leniwie wczytuje obrazy w widocznym obszarze (w części strony widocznej na ekranie). W poście na blogu CMS wyróżniono to jako wzorzec, którego należy unikać, ale dane eksperymentalne w tamtym czasie wskazują, że wpływ na LCP był minimalny i warto uprościć implementację w podstawowej wersji WordPressa.

Na podstawie tych nowych danych stworzyliśmy 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.

Seria default wyłączono fix Różnica w stosunku do wartości domyślnej Różnica w stosunku do ustawień wyłączonych
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) spowodowana przez proponowaną poprawkę leniwego ładowania obrazów na poziomie przeglądarki na przykładowych stronach WordPress.

Te wyniki są znacznie bardziej obiecujące. Leniwe ładowanie tylko obrazów w części strony widocznej po przewinięciu powoduje całkowite cofnięcie regresji LCP, a może nawet nieznacznie poprawić wyłączenie tej funkcji. Co może być szybsze niż bez leniwego ładowania? Jednym z wyjaśnień jest to, że brak ładowania obrazów w części strony widocznej po przewinięciu zmniejsza ryzyko rywalizacji z obrazem LCP w sieci, co sprzyja szybszemu ładowaniu.

Seria default wyłączono fix Różnica w stosunku do wartości domyślnej Różnica w stosunku do ustawień wyłączonych
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) w wyniku proponowanej poprawki dotyczącej leniwego ładowania obrazów na poziomie przeglądarki na przykładowych stronach WordPress.

Jeśli chodzi o bajty obrazu, poprawka nie zmieniła się w porównaniu z domyślnym działaniem. To świetnie, ponieważ to jedna z mocnych stron obecnego podejścia.

Ta poprawka ma pewne zastrzeżenia. WordPress określa, które obrazy mają być leniwie ładowane po stronie serwera, co oznacza, że nie wie nic o rozmiarze widocznego obszaru użytkownika ani o tym, czy obrazy początkowo się w nim ładują. Poprawka wykorzystuje więc dane heurystyczne dotyczące względnego położenia obrazów w znaczniku, aby odgadnąć, czy zostaną one wczytane w widocznym obszarze. W szczególności w przypadku pierwszego obrazu polecanego na stronie lub pierwszego obrazu w treści głównej.

Na to, czy obraz znajduje się w widocznym obszarze, mogą mieć wpływ warunki na poziomie strony, takie jak liczba słów w nagłówku czy ilość tekstu akapitu na początku głównej treści. Istnieją również warunki na poziomie użytkownika, które mogą wpływać na dokładność heurystyki, zwłaszcza rozmiar widocznego obszaru i używanie linków zakotwiczonych, które zmieniają pozycję przewijania strony.

Dlatego należy pamiętać, że poprawka jest kalibrowana tylko w celu zapewnienia dobrej skuteczności w przypadku ogólnym oraz że konieczne może być jej dostosowanie, aby można było zastosować te wyniki we wszystkich rzeczywistych scenariuszach.

Implementacja (:#implementacja)

Odkryto więc lepszy sposób na leniwe ładowanie obrazów. Jak można zaoszczędzić wszystkie obrazy i zwiększyć wydajność LCP? Jak może zacząć z niego korzystać? Najważniejszą zmianą jest przesłanie poprawki do podstawowej WordPress w celu wdrożenia eksperymentalnej poprawki. Zaktualizowaliśmy też wskazówki w poście na blogu Lenne loading for CMSs (leniwe ładowanie na poziomie przeglądarki), aby doprecyzować negatywne skutki leniwego ładowania w części strony widocznej na ekranie i dowiedzieć się, jak systemy CMS mogą go uniknąć za pomocą heurystyki.

Te sprawdzone metody dotyczą wszystkich programistów stron internetowych, dlatego warto też zgłosić antywzorce leniwego ładowania w narzędziach takich jak Lighthouse. Jeśli chcesz śledzić postępy kontroli, zapoznaj się z prośbą o dodanie funkcji w GitHubie. Do tego czasu programiści mogli znaleźć wystąpienia elementów LCP leniwie ładowane, czyli dodać do danych pól bardziej szczegółowe rejestrowanie.

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});

Poprzedni fragment kodu JavaScript oceni ostatni element LCP i zarejestruje ostrzeżenie, jeśli został wczytany leniwie.

Podkreśla to też zaletę metody leniwego ładowania i potencjał możliwości ulepszenia interfejsu API na poziomie platformy. Na przykład w Chromium występuje otwarty problem polegający na eksperymentowaniu z natywnym wczytywaniem kilku pierwszych obrazów natywnie, podobnie jak w przypadku poprawki mimo atrybutu loading.

Podsumowanie

Jeśli Twoja witryna stosuje leniwe ładowanie obrazów na poziomie przeglądarki, sprawdź sposób implementacji i przeprowadź testy A/B, by lepiej poznać koszty związane z wydajnością. Może to przynieść korzyści przy wczytywaniu obrazów w części strony widocznej na ekranie. Jeśli masz witrynę WordPress, być może wkrótce udostępnimy poprawkę w podstawowej wersji WordPress. Jeśli używasz innego systemu CMS, upewnij się, że słyszy on o opisanych tutaj potencjalnych problemach z wydajnością.

Wypróbowywanie stosunkowo nowych interfejsów API platformy internetowej może wiązać się z ryzykiem i korzyściami – nie bez powodu są nazywane najnowszymi funkcjami. Zaczynamy czuć niepokojące zjawiska związane z leniwym ładowaniem obrazów na poziomie przeglądarki, ale dostrzegamy też zalety korzystania z tego narzędzia do zwiększania wydajności.

Fot. Frankie Lopez i film Unsplash