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

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

Felix Arntz

Rick Viscomi

Leniwe ładowanie to technika pozwalająca na odłożenie pobierania zasobu do momentu, gdy będzie potrzebna. Pozwala to zaoszczędzić dane i zmniejszyć rywalizację sieci o najważniejsze zasoby. W 2019 roku stał się standardem internetowym. Dziś loading="lazy" w przypadku obrazów jest obsługiwana przez większość najpopularniejszych przeglądarek. Brzmi nieźle, ale czy jest coś takiego jak za dużo leniwego ładowania?

W tym poście podsumowaliśmy nasze analizy dostępnych publicznie danych dotyczących przejrzystości sieci i doraźnych testów A/B, aby poznać cechy rozpowszechnienia i wydajności leniwego ładowania obrazów natywnych. Okazało się, że leniwe ładowanie może być niezwykle skutecznym narzędziem do zmniejszania liczby zbędnych bajtów obrazu, ale jego nadużywanie może negatywnie wpłynąć na wydajność. Nasze analizy pokazują, że szybsze wczytywanie obrazów w początkowym widocznym obszarze (przy swobodnym leniwym ładowaniu pozostałych) może przynieść korzyści obu stronom: mniej wczytywanych bajtów i poprawić podstawowe wskaźniki internetowe.

Rozpowszechnienie

Jak wynika z najnowszych danych w archiwum HTTP, leniwe ładowanie obrazów natywnych jest stosowane w 17% witryn, a ich popularność rośnie bardzo szybko. Taki fundament w ekosystemie jest imponujący w przypadku stosunkowo nowego interfejsu API.

Wysyłanie zapytań do nieprzetworzonych danych w projekcie archiwum HTTP pozwala nam lepiej zrozumieć, jakie rodzaje witryn są najbardziej popularne: 84% witryn używających natywnego leniwego ładowania obrazów korzysta z WordPressa, 2% z innego systemu CMS, a pozostałe 14% nie korzysta ze znanego systemu CMS. Te wyniki pokazują, że WordPress jest liderem w sprawie wdrożenia.

Warto też zwrócić uwagę na wskaźnik rozpowszechnienia. Rok temu, w lipcu 2020 r., witryny WordPress korzystające z leniwego ładowania tworzyły dziesiątki tysięcy stron w korpusie z około 6 milionów stron (1% całości). Wdrożenie leniwego wczytywania w samej tylko WordPressie rozwinęło się do ponad miliona witryn, co stanowi 14% wszystkich stron internetowych.

Skuteczność korelacyjna

Analizując dokładniej w archiwum HTTP, możemy porównać wydajność stron z leniwym ładowaniem obrazów natywnych i bez nich, korzystając z danych Największe wyrenderowanie treści (LCP). Dane LCP pochodzą z rzeczywistych doświadczeń użytkownika, które pochodzą z Raportu na temat użytkowania Chrome (CrUX), a nie z testów syntetycznych występujących w module. Na poniższym wykresie użyto wykresu pudełko-wąs do wizualizacji rozkładów LCP 75 centyla dla każdej strony: linie reprezentują 10 i 90 centyl, a pola – 25. i 75. percentyl.

Mediana strony bez leniwego ładowania ma 75 centyl LCP wynoszący 2922 ms, a dla mediany strony z leniwym ładowaniem – 3546 ms. Ogólnie witryny korzystające z leniwego ładowania uzyskują gorsze wyniki w zakresie LCP.

Trzeba pamiętać, że są to wyniki korelacyjne i niekoniecznie wskazują na leniwe ładowanie jako przyczynę wolniejszego działania. Hipotetycznie, jeśli witryny WordPress mogą działać trochę wolniej, a biorąc pod uwagę, w jakim stopniu stanowią one kohortę leniwego ładowania, może to wyjaśniać różnicę. Spróbujmy więc wyeliminować tę zmienność, analizując wyłącznie witryny WordPress.

Ten sam schemat pojawia się, gdy zagłębiamy się w strony WordPress. Te z leniwym ładowaniem mają zwykle wolniejszy wskaźnik LCP. Mediana strony WordPress bez leniwego ładowania ma 75 centyl LCP wynoszący 3495 ms, a dla mediany strony z leniwym ładowaniem – 3768 ms.

To nadal nie dowodzi, że leniwe ładowanie powoduje spowolnienie działania stron, ale korzystanie z niego zbiega się z większą wydajnością. Aby spróbować znaleźć odpowiedź na pytanie o związki przyczynowo-skutkowe, opracowaliśmy w laboratorium test A/B.

Przypadkowe wyniki

Celem testu A/B było potwierdzenie lub odrzucenie hipotezy, według której leniwe ładowanie obrazów natywnych, stosowane w podstawowej wersji WordPressa, powodowało zmniejszenie wydajności LCP i zmniejszenie liczby bajtów obrazu. Używana metodologia polegała na przetestowaniu witryny demonstracyjnej WordPress o temacie dwentytwentyone. Przetestowaliśmy zarówno strony archiwów, jak i pojedyncze typy stron (takie jak strona główna i strony z artykułami) na komputerach oraz emulowane urządzenia mobilne za pomocą narzędzia WebPageTest. Przetestowaliśmy każdą kombinację stron z włączonym leniwym ładowaniem i bez niego, a następnie przeprowadziliśmy każdy test 9 razy, aby uzyskać medianę LCP i liczbę bajtów obrazu.

Powyższe wyniki porównują medianę LCP w milisekundach w przypadku testów w archiwum oraz na pojedynczych stronach na komputery i urządzenia mobilne. Po wyłączeniu leniwego ładowania na stronach archiwum zaobserwowaliśmy znaczny wzrost LCP. Na pojedynczych stronach różnica była jednak bardziej neutralna.

Warto zauważyć, że wyłączenie leniwego ładowania sprawia, że pojedyncze strony wczytują się nieco szybciej. Jednak różnica w LCP jest mniejsza niż jedno odchylenie standardowe zarówno w testach na komputerach, jak i urządzeniach mobilnych. Dlatego przypisujemy tę wartość do wariancji i ogólnie uznajemy zmianę za neutralną. Dla porównania różnica w przypadku stron archiwum wynosi około 2–3 odchyleń standardowych.

Powyższe wyniki porównują medianę liczby bajtów obrazu (w KB) w każdym teście. Jak można było się spodziewać, leniwe ładowanie ma bardzo pozytywny wpływ na zmniejszenie liczby bajtów obrazu. Gdyby prawdziwy użytkownik przewinął całą stronę w dół, wszystkie obrazy i tak by były wczytywane w widocznym obszarze. Wyniki te pokazały jednak wzrost wydajności początkowego wczytywania strony.

Podsumujmy wyniki testu A/B. Zastosuj w WordPressie technikę leniwego ładowania, by zmniejszyć liczbę bajtów obrazu, ale kosztem opóźnionego LCP.

Testowanie poprawki

Zanim przejdziemy do szczegółów implementacji poprawki, zobaczmy, jak działa leniwe ładowanie w WordPressie. Najważniejszym aspektem obecnej implementacji jest to, że leniwe ładowanie obrazów w części strony widocznej na ekranie (w widocznym obszarze). W poście na blogu CMS potwierdzamy, że można tego uniknąć, ale z danych eksperymentalnych wynika, że wpływ na LCP był minimalny i warto uprościć implementację w podstawowym interfejsie WordPress.

Biorąc pod uwagę te nowe dane, opracowaliśmy rozwiązanie eksperymentalne, które pozwala uniknąć leniwego ładowania obrazów w części strony widocznej na ekranie. Przetestowaliśmy je w tych samych warunkach co pierwszy test A/B.

Wyniki te są znacznie bardziej obiecujące. Leniwe ładowanie tylko obrazów w części strony widocznej po przewinięciu prowadzi do całkowitego odwrócenia regresji LCP, a nawet niewielkiej poprawy w stosunku do całkowitego wyłączenia LCP. Czy może być coś szybszego niż leniwe ładowanie? Jednym z wyjaśnień jest to, że brak ładowania obrazów w części strony widocznej po przewinięciu zmniejsza rywalizację sieci o obraz LCP, co sprzyja jego szybszemu ładowaniu.

Jeśli chodzi o liczbę bajtów obrazu, poprawka nie zmieniła się w porównaniu z domyślnym działaniem. To wspaniałe, ponieważ było to jedną z mocnych stron obecnego podejścia.

Ta poprawka wiąże się z pewnymi zastrzeżeniami. WordPress określa, które obrazy mają być ładowane po stronie serwera, co oznacza, że nie ma informacji o rozmiarze widocznego obszaru użytkownika ani o tym, czy obrazy zostaną w nim wstępnie wczytane. Poprawka korzysta więc z metod heurystycznych dotyczących względnej lokalizacji obrazów w znacznikach, aby odgadnąć, czy znajdą się one w widocznym obszarze. W szczególności zakłada się, że obraz jest pierwszym polecanym obrazem na stronie lub pierwszym w głównej treści, czyli znajduje się w części strony widocznej na ekranie (lub jest w jego pobliżu) i nie będzie leniwy. Na to, czy obraz znajduje się w widocznym obszarze, mogą wpływać warunki na poziomie strony, takie jak liczba słów w nagłówku czy ilość tekstu akapitu na początku głównej treści. Istnieją też warunki na poziomie użytkownika, które mogą wpływać na dokładność heurystyki, a zwłaszcza rozmiar widocznego obszaru oraz wykorzystanie linków zakotwiczonych, które zmieniają pozycję przewijania strony. Dlatego trzeba pamiętać, że poprawka jest skalibrowana tylko tak, aby zapewnić dobrą wydajność w przypadku ogólnym, i może być konieczne jej dopracowanie, aby wyniki te były stosowane we wszystkich rzeczywistych scenariuszach.

Wdrażanie

Skoro zidentyfikowaliśmy lepszy sposób leniwego ładowania obrazów, oszczędność obrazów i szybszą wydajność LCP, jak mogę zachęcić witryny do korzystania z tej technologii? Najważniejszą zmianą jest przesłanie poprawki do podstawowej WordPressa w celu zaimplementowania poprawki eksperymentalnej. Uaktualnimy też wskazówki zawarte w poście na blogu leniwe ładowanie na poziomie przeglądarki dla systemów CMS, aby lepiej wyjaśnić negatywne skutki leniwego ładowania w części strony widocznej na ekranie i jak systemy CMS mogą go uniknąć, korzystając z metody heurystycznej.

Te sprawdzone metody dotyczą wszystkich programistów stron internetowych, więc warto też w narzędziach takich jak Lighthouse oznaczyć leniwe ładowanie, stosując rozwiązania zapobiegające leniwym ładowaniu. Jeśli chcesz wiedzieć więcej o postępach w tej kontroli, zapoznaj się z prośbą o dodanie funkcji na GitHubie. Do tego czasu programiści mogli znaleźć przypadki leniwego ładowania elementów LCP, dodając do danych pól bardziej szczegółowe logowanie.

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 był on leniwy.

Podkreśla to także ostrą przewagę nad techniką leniwego ładowania i możliwość ulepszenia interfejsów API na poziomie platformy. Na przykład w Chromium wystąpił problem z eksperymentowaniem z szybkim natywnie ładowaniem pierwszych kilku obrazów (podobnie jak w przypadku poprawki), pomimo atrybutu loading.

Kończę

Jeśli w swojej witrynie używasz leniwego ładowania obrazów natywnych, sprawdź sposób implementacji i przeprowadź testy A/B, by lepiej poznać koszty wydajności. Skuteczniejsze ładowanie obrazów w części strony widocznej na ekranie może przynieść korzyści. Jeśli masz witrynę opartą na WordPressie, wkrótce powinna pojawić się w niej poprawka. Jeśli korzystasz z innego systemu CMS, upewnij się, że zdajesz sobie sprawę z opisanych tu potencjalnych problemów z wydajnością.

Wypróbowywanie stosunkowo nowych interfejsów API platform internetowych może wiązać się z ryzykiem i korzyściami. Nie bez powodu są one nazywane najnowocześniejszymi funkcjami. Zaczynamy czuć, że natywne leniwe ładowanie obrazu ma swoje wady, ale dostrzegamy również jego zalety do osiągania lepszych wyników.

Fot. Frankie Lopez na kanale Unsplash