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.
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.
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.
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.
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% |
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% |
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% |
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% |
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.