Leniwe ładowanie obrazów i ramek: kiedy przyspiesza stronę, a kiedy szkodzi LCP

Czym jest leniwe ładowanie i jak działa atrybut loading

Leniwe ładowanie (ang. lazy loading) to odłożenie pobierania zasobu do momentu, w którym staje się potrzebny. Na stronie internetowej dotyczy to przede wszystkim obrazów i ramek iframe, czyli okien, w których osadza się cudzą treść: mapę, film, kalendarz rezerwacji albo wtyczkę serwisu społecznościowego. Zamiast pobierać wszystko naraz, przeglądarka pobiera na początku tylko to, co mieści się na ekranie, a resztę dopiero wtedy, gdy użytkownik przewija stronę w jej kierunku.

Współcześnie nie potrzeba do tego żadnego skryptu. Wystarczy atrybut loading dopisany do znacznika img albo iframe. Zgodnie z opisem w serwisie web.dev, w artykule o leniwym ładowaniu obrazów na poziomie przeglądarki, atrybut przyjmuje dwie wartości. Wartość lazy oznacza odłożenie pobrania do chwili, gdy element znajdzie się w określonej odległości od widocznego obszaru. Wartość eager to zachowanie domyślne, takie samo jak przy braku atrybutu: zasób jest pobierany od razu, bez względu na położenie.

<img src="realizacja-lazienka.jpg" alt="Łazienka po remoncie" width="800" height="600" loading="lazy">

<iframe src="https://example.com" title="Mapa dojazdu" width="600" height="400" loading="lazy"></iframe>

Kiedy przeglądarka pobiera odłożony obraz

Przeglądarka nie czeka, aż obraz wejdzie na ekran. Zaczyna go pobierać wcześniej, z zapasem, tak aby zdążył się wczytać, zanim użytkownik do niego dotrze. W przeglądarkach opartych na silniku Chromium zapas ten zależy od rodzaju połączenia. Według web.dev dla szybkich połączeń wynosi on 1250 pikseli, a dla wolniejszych 2500 pikseli od widocznego obszaru. Wartości te są zapisane na stałe w przeglądarce i właściciel strony nie może ich zmienić.

Z tego samego źródła wynika kilka mniej oczywistych zasad. Atrybut loading działa ze znacznikiem img, nie obejmuje obrazów ustawionych jako tło w arkuszu stylów. W elemencie picture, który podaje kilka wersji obrazu, atrybut dopisuje się tylko do znajdującego się w nim znacznika img. Przeglądarka, która atrybutu nie zna, po prostu go pomija i pobiera obraz w zwykły sposób, więc wdrożenie niczego nie psuje. Obecnie atrybut obsługują wszystkie główne przeglądarki: Chrome, Edge, Firefox i Safari.

Kiedy leniwe ładowanie przyspiesza stronę

Leniwe ładowanie pomaga wtedy, gdy strona zawiera dużo obrazów lub osadzonych treści poniżej pierwszego ekranu. Przeglądarka ma na starcie mniej do pobrania, więc łącze i moc urządzenia pracują na to, co użytkownik widzi od razu. Osoba, która nie przewinie strony do końca, w ogóle nie pobiera dolnych zdjęć, co ma znaczenie przy pakiecie danych w telefonie.

Skalę oszczędności pokazuje test opisany w artykule web.dev o skutkach zbyt częstego leniwego ładowania. Autorzy porównali strony WordPressa z włączonym i wyłączonym leniwym ładowaniem. Po jego wyłączeniu liczba pobieranych bajtów obrazów rosła ponad dwukrotnie: na stronie archiwum wpisów w wersji na komputer z 577 KB do 1173 KB, a na pojedynczym wpisie w wersji mobilnej ze 114 KB do 378 KB.

W praktyce najwięcej zyskują strony o długim układzie. Sklep z Poznania, który na stronie kategorii pokazuje kilkadziesiąt miniatur produktów, pobierze na telefonie tylko kilka pierwszych. Firma remontowa z Bydgoszczy z galerią realizacji na dole strony głównej nie obciąża nią pierwszego ekranu. W obu przypadkach chodzi o obrazy, do których użytkownik dociera dopiero po przewinięciu.

Warto przy tym zachować proporcje. Leniwe ładowanie nie zmniejsza wagi samych plików. Zdjęcie o zbyt dużych wymiarach albo zapisane w przestarzałym formacie pozostaje ciężkie, tylko jest pobierane później. Dobór formatu, kompresję i wymiary opisujemy osobno we wpisie o tym, jak obrazy na stronie wpływają na SEO.

Kiedy leniwe ładowanie szkodzi LCP

Leniwe ładowanie szkodzi wtedy, gdy obejmuje obraz widoczny zaraz po otwarciu strony, a najbardziej wtedy, gdy jest to element LCP. LCP (Largest Contentful Paint, największe wyrenderowanie treści) mierzy czas, po którym na ekranie pojawia się największy widoczny element, często zdjęcie główne lub baner. Według artykułu web.dev o optymalizacji największego wyrenderowania treści dobry wynik to 2,5 sekundy lub mniej w co najmniej 75 procentach wizyt, a wynik powyżej 4 sekund jest słaby.

Przyczyna opóźnienia jest prosta. Zwykły obraz przeglądarka zaczyna pobierać natychmiast po znalezieniu go w kodzie HTML. Przy obrazie z wartością lazy musi najpierw ustalić, gdzie obraz leży na stronie, a to wie dopiero po obliczeniu układu. Dopiero wtedy stwierdza, że obraz jest w widocznym obszarze, i rozpoczyna pobieranie. Ten sam artykuł mówi wprost, że obrazu LCP nigdy nie należy ładować leniwie, ponieważ zawsze prowadzi to do zbędnego opóźnienia.

Potwierdza to wspomniany test na stronach WordPressa. Na stronie archiwum wpisów wyłączenie leniwego ładowania skróciło LCP o 13 procent w wersji na komputer i o 15 procent w wersji mobilnej. Najlepszy wynik dało jednak rozwiązanie pośrednie: obrazy z góry strony wczytywane od razu, pozostałe leniwie. LCP było wtedy co najmniej tak dobre jak bez leniwego ładowania, a liczba pobieranych bajtów pozostała niska. Autorzy tłumaczą to tym, że obrazy spoza ekranu nie konkurują o łącze z obrazem głównym.

Co ustawić na obrazie głównym

Obraz główny powinien mieć w kodzie zwykły adres w atrybucie src, nie mieć atrybutu loading z wartością lazy i otrzymać atrybut fetchpriority z wartością high, który podnosi priorytet jego pobierania. Web.dev zaleca, aby wysoki priorytet nadawać najwyżej jednemu lub dwóm obrazom, bo przy większej liczbie wskazówka traci sens. Łączenie obu atrybutów na jednym obrazie jest sprzeczne: przeglądarka najpierw odkłada pobranie, a potem ma je wykonać z wysokim priorytetem.

Błędnie:
<img src="baner-glowny.jpg" alt="Salon fryzjerski" loading="lazy">

Poprawnie:
<img src="baner-glowny.jpg" alt="Salon fryzjerski" width="1200" height="600" fetchpriority="high">

Drugim źródłem kłopotów są starsze skrypty do leniwego ładowania, które przenoszą adres obrazu z atrybutu src do atrybutu data-src i dopiero po uruchomieniu podstawiają go z powrotem. Przeglądarka przeglądająca kod HTML nie widzi wtedy adresu obrazu i nie może zacząć go pobierać, dopóki skrypt się nie wykona. To samo dotyczy obrazów ustawionych jako tło w arkuszu stylów oraz dodawanych przez skrypt. Pozostałe przyczyny słabego wyniku opisujemy we wpisie o tym, co opóźnia LCP na stronie.

Dlaczego obrazy i ramki muszą mieć podane wymiary

Wymiary pozwalają przeglądarce zarezerwować miejsce na obraz, zanim go pobierze. Bez nich obraz zajmuje początkowo zero na zero pikseli, a po wczytaniu rozpycha treść i przesuwa wszystko, co leży poniżej. Przy leniwym ładowaniu problem się nasila, bo obrazy wczytują się późno, często w chwili, gdy użytkownik już czyta tekst albo sięga do przycisku.

Takie przeskoki mierzy wskaźnik CLS (Cumulative Layout Shift, skumulowane przesunięcie układu). Według artykułu web.dev o optymalizacji skumulowanego przesunięcia układu dobry wynik to 0,1 lub mniej w co najmniej 75 procentach wizyt, a wartości powyżej 0,25 są słabe. To samo źródło wyjaśnia, że na podstawie atrybutów width i height przeglądarka wylicza proporcje obrazu jeszcze przed jego pobraniem. Jeśli obraz ma w stylach ustawioną szerokość na cały kontener, wystarczy dodać wysokość automatyczną, a przeglądarka sama obliczy właściwą wysokość. Miejsce można też zarezerwować właściwością aspect-ratio w arkuszu stylów.

Brak wymiarów ma jeszcze jeden, mniej znany skutek. Web.dev zwraca uwagę, że w galerii złożonej z obrazów bez wymiarów wszystkie mają na początku zerową wysokość. Przeglądarka może uznać je wszystkie za widoczne i pobrać od razu. Leniwe ładowanie jest wtedy wpisane w kod, ale nie przynosi oszczędności.

Ta sama zasada dotyczy ramek. Mapa lub film osadzone bez podanej wysokości potrafią po wczytaniu przesunąć całą dolną część strony. Dla ramek o zmiennym rozmiarze, na przykład reklam czy widżetów, zalecane jest zarezerwowanie miejsca minimalną wysokością lub proporcjami. Więcej przyczyn przeskoków opisujemy we wpisie o tym, skąd biorą się przesunięcia układu strony.

Leniwe ładowanie ramek iframe: mapy, filmy i wtyczki

Ramka z wartością lazy nie pobiera swojej zawartości, dopóki użytkownik nie przewinie strony w jej pobliże. Ma to duże znaczenie, ponieważ ramka to w praktyce osobna strona wczytywana wewnątrz Państwa strony, z własnymi skryptami, stylami i obrazami.

Artykuł web.dev o leniwym ładowaniu elementów iframe poza ekranem podaje przykładowe oszczędności przy początkowym wczytywaniu strony: około 500 KB dla osadzonego filmu z YouTube, 514 KB dla odtwarzacza Spotify i około 100 KB dla osadzonego wpisu z Instagrama. Wtyczka Facebooka z przyciskiem polubienia pobiera domyślnie około 215 KB zasobów, z czego większość to kod JavaScript. Źródło dodaje, że odłożenie ramek może pośrednio poprawić także LCP, bo na słabszym łączu zwalnia przepustowość dla zasobów ważnych na pierwszym ekranie.

Typowy przykład to strona kontaktowa kancelarii z Krakowa, na której mapa dojazdu znajduje się pod danymi adresowymi i formularzem. Na telefonie użytkownik widzi najpierw numer telefonu i adres, a mapa leży niżej. Odłożenie jej wczytania nie zmienia niczego w odbiorze strony, a pierwszy ekran ma mniej do pobrania. Podobnie jest z filmem z realizacji w środku długiej strony usługi czy widżetem rezerwacji wizyt na dole strony gabinetu.

Zasada wyjątku jest taka sama jak przy obrazach: ramki widocznej od razu po otwarciu strony nie należy ładować leniwie. Warto też wiedzieć, że atrybut nie rozróżnia ramek widocznych od ukrytych ramek technicznych, używanych czasem do pomiarów lub komunikacji między usługami. To autor strony decyduje, które ramki odłożyć, dlatego atrybutu nie należy dopisywać hurtowo do elementów, których przeznaczenia się nie zna.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Co widzi robot Google, gdy treść ładuje się z opóźnieniem

Robot Google widzi treść ładowaną leniwie tylko wtedy, gdy wczytuje się ona sama po znalezieniu się w widocznym obszarze, bez udziału użytkownika. Dokumentacja Google Search Central poświęcona naprawianiu leniwie ładującej się zawartości witryny stwierdza, że leniwe ładowanie jest dobrą praktyką, ale wdrożone niepoprawnie może ukryć część treści przed wyszukiwarką. Powód jest jeden: Google nie wchodzi w interakcję ze stroną, czyli jej nie przewija i niczego na niej nie klika.

Google wskazuje trzy sposoby, które spełniają ten warunek. Pierwszym jest leniwe ładowanie wbudowane w przeglądarkę, czyli opisany wyżej atrybut loading dla obrazów i ramek. Drugim jest interfejs IntersectionObserver, czyli mechanizm przeglądarki, który informuje skrypt, że dany element znalazł się w widocznym obszarze. Trzecim są biblioteki JavaScript, które wczytują dane w chwili, gdy element wchodzi w widoczny obszar. Wspólna cecha tych rozwiązań to reakcja na widoczność elementu, a nie na ruch użytkownika.

Treść zależna od przewijania i kliknięcia

Dokumentacja wprost przestrzega przed uzależnianiem wczytywania treści od działań użytkownika, takich jak przewijanie lub klikanie. Dotyczy to starszych skryptów, które czekają na zdarzenie przewijania i dopiero po nim podstawiają adresy obrazów, a także list produktów, opinii czy opisów pobieranych po naciśnięciu przycisku rozwijającego dalszą część. Skoro robot nie przewija i nie klika, taka treść może nigdy nie trafić do wyrenderowanej wersji strony.

Łatwo wyobrazić sobie skutek na przykładzie sklepu z częściami rowerowymi z Łodzi, w którym zdjęcia na karcie produktu mają adres w atrybucie data-src, a skrypt podstawia go po pierwszym ruchu przewijania. Klienci widzą zdjęcia bez zastrzeżeń. W kodzie, który otrzymuje robot, znaczniki img pozostają jednak bez adresu, więc wyszukiwarka nie ma czego powiązać z produktem. Strona poprawna dla człowieka okazuje się niepełna dla robota.

Google dodaje jeszcze jedno zalecenie, zbieżne z tym, co opisaliśmy przy LCP: nie należy stosować leniwego ładowania do treści, która jest widoczna od razu po otwarciu strony, ponieważ wydłuża to czas jej wyświetlenia.

Przewijanie nieskończone a indeksowanie

Przewijanie nieskończone, czyli doczytywanie kolejnych porcji treści w miarę zbliżania się do końca strony, wymaga dodatkowej pracy. Według tej samej dokumentacji każda porcja treści powinna mieć własny, stały adres URL, pod którym zawsze znajduje się ta sama zawartość. W adresach lepiej stosować bezwzględne numery stron, na przykład parametr page z numerem, niż określenia względne. Strony powinny być połączone kolejnymi linkami, aby wyszukiwarka mogła odnaleźć cały zbiór, a adres w pasku przeglądarki powinien się zmieniać, gdy kolejna porcja staje się główną treścią na ekranie.

Dla sklepu oznacza to, że kategoria z doczytywaniem produktów powinna mieć równolegle zwykłe stronicowanie z linkami w kodzie. W dużych serwisach wiąże się to z szerszym tematem, który opisujemy we wpisie o tym, jak filtry w sklepie wpływają na indeksowanie.

Leniwe ładowanie w WordPressie: co system robi sam

WordPress dopisuje atrybut loading do obrazów i ramek samodzielnie, bez wtyczek, i stara się przy tym ominąć obrazy z góry strony. Według wpisu zespołu rozwijającego system, poświęconego usprawnieniom wydajności obrazów w wersji 6.3, o atrybutach decyduje jedna centralna funkcja. Przyznaje ona obrazowi albo atrybut fetchpriority z wartością high, albo atrybut loading z wartością lazy, albo żaden z nich, i nigdy nie nadaje obu jednocześnie.

System nie zna rozmiaru ekranu odwiedzającego, ponieważ kod strony powstaje na serwerze. Posługuje się więc przybliżeniem. Domyślnie pozostawia bez leniwego ładowania trzy pierwsze obrazy na stronie, co ma lepiej pasować do układów wielokolumnowych. Wysoki priorytet pobierania otrzymuje pierwszy obraz uznany za wystarczająco duży: iloczyn jego szerokości i wysokości musi wynosić co najmniej 50 tysięcy, więc obraz 300 na 200 pikseli spełnia warunek, a 200 na 200 już nie. Oba progi programista może zmienić filtrami. Ważna jest też zasada, że system nie nadpisuje atrybutów ustawionych ręcznie w kodzie.

Przybliżenie bywa zawodne. Autorzy testu opisanego w web.dev wymieniają czynniki, które wpływają na trafność: długość tytułu, ilość tekstu przed pierwszym obrazem i rozmiar okna. Z naszych obserwacji wynika, że częstszym źródłem kłopotów są dodatki. Kreatory stron, suwaki i wtyczki przyspieszające nieraz generują znaczniki img poza standardowymi funkcjami systemu albo nakładają własne leniwe ładowanie na wszystkie obrazy, łącznie z głównym.

W sklepach na WooCommerce warto osobno obejrzeć trzy szablony: stronę główną, stronę kategorii i kartę produktu. Na każdym z nich elementem LCP bywa co innego: baner, pierwsza miniatura albo główne zdjęcie produktu. W ramach usługi pozycjonowania sklepów oceniamy je oddzielnie, na telefonie i na komputerze.

Jak zweryfikować leniwe ładowanie na własnej stronie

Weryfikacja składa się z trzech pytań: czy obraz główny jest pobierany od razu, czy obrazy i ramki mają wymiary oraz czy robot Google widzi komplet treści. Na każde z nich odpowiada inne narzędzie, a wszystkie są dostępne bez opłat.

Kod strony w przeglądarce

Najprostszy test to kliknięcie zdjęcia głównego prawym przyciskiem myszy i wybranie z menu polecenia zbadania elementu. Przeglądarka otwiera wtedy narzędzia dla programistów z podświetlonym znacznikiem img. Wystarczy odczytać cztery rzeczy: czy w atrybucie src stoi prawdziwy adres pliku, czy nie ma atrybutu loading z wartością lazy, czy są atrybuty width i height oraz czy jest fetchpriority z wartością high. Dla obrazu z dołu strony oczekiwany wynik jest odwrotny: wartość lazy powinna tam być. Test należy wykonać także w widoku telefonu, ponieważ wiele stron pokazuje na małym ekranie inny obraz główny niż na komputerze.

Raport wydajności

W raportach opartych na Lighthouse służy do tego statystyka o nazwie Wykrywanie żądań LCP. Zgodnie z dokumentacją Chrome ocenia ona trzy warunki dla obrazu będącego elementem LCP: czy ma atrybut fetchpriority z wartością high, czy jest widoczny w głównym dokumencie, czyli wprost w kodzie HTML, oraz czy nie zastosowano do niego leniwego ładowania. Niespełniony trzeci warunek to dokładnie błąd opisany w tym wpisie. Niespełniony drugi wskazuje zwykle na adres ukryty w atrybucie data-src albo obraz ustawiony jako tło.

W starszych raportach pojawiała się też pozycja Odrocz obrazy poza ekranem, która wyliczała obrazy spoza widocznego obszaru pobierane na starcie. Dokumentacja informuje, że audyt ten został usunięty w Lighthouse 13, więc jego brak w nowym raporcie nie jest błędem. Jak czytać cały raport, opisujemy we wpisie PageSpeed Insights: jak czytać raport.

Narzędzie do sprawdzania adresów URL w Search Console

To, co widzi robot, pokazuje Search Console. Adres podstrony wpisuje się w pasku wyszukiwania u góry panelu, a następnie uruchamia test wersji opublikowanej. Po zakończeniu testu na karcie wyniku pojawia się przycisk wyświetlenia przetestowanej strony. Otwiera on panel z kartą Zrzut ekranu oraz kartą Więcej informacji, na której według pomocy Search Console znajdują się między innymi lista załadowanych zasobów i zwrócony kod HTML.

Google zaleca, aby w wyrenderowanym kodzie odszukać treść ładowaną leniwie i upewnić się, że adresy obrazów i filmów znajdują się w atrybucie src znaczników img i video. W praktyce wystarczy wyszukać w kodzie nazwę pliku zdjęcia z dołu strony albo fragment tekstu z ostatniej sekcji. Jeżeli ich nie ma, treść zależy od działania, którego robot nie wykonuje. Trzeba przy tym uwzględnić, że zrzut ekranu z tego narzędzia może różnić się od wyglądu strony w przeglądarce, a liczba testów w ciągu dnia jest ograniczona.

Po wdrożeniu poprawek zmianę LCP i CLS u prawdziwych użytkowników widać dopiero po pewnym czasie, w raporcie opisanym we wpisie Podstawowe wskaźniki internetowe w Search Console. Test laboratoryjny pokazuje efekt od razu, ale tylko dla jednego urządzenia i jednego łącza.

Typowe błędy i kolejność poprawek

Najczęstsze błędy to leniwie ładowany obraz główny, brak wymiarów obrazów i ramek oraz treść wczytywana dopiero po przewinięciu lub kliknięciu. Poprawki warto prowadzić w tej właśnie kolejności: najpierw pierwszy ekran, potem stabilność układu, na końcu widoczność dla robota i porządek w dodatkach.

Do mniej oczywistych pomyłek należy przekonanie, że ukrycie obrazu zawsze wstrzymuje jego pobieranie. Według web.dev obrazy ukryte właściwością display z wartością none nie są wczytywane w głównych przeglądarkach, ale ukrycie przez zerową przezroczystość pobrania nie wstrzymuje. Osobnej uwagi wymagają suwaki i karuzele: pierwszy slajd jest zwykle elementem LCP i powinien wczytywać się od razu, a kolejnym można obniżyć priorytet.

• Obraz główny na każdym szablonie nie ma atrybutu loading z wartością lazy, zarówno na telefonie, jak i na komputerze.
• Obraz główny ma adres w atrybucie src i atrybut fetchpriority z wartością high.
• Logo i pierwszy rząd miniatur wczytują się w zwykły sposób.
• Wszystkie obrazy i ramki mają podaną szerokość i wysokość albo zarezerwowane proporcje w stylach.
• Mapy, filmy i wtyczki położone poniżej pierwszego ekranu mają atrybut loading z wartością lazy.
• Na stronie działa jeden mechanizm leniwego ładowania, a nie kilka nakładających się na siebie.
• Wyrenderowany kod w Search Console zawiera adresy obrazów z dołu strony w atrybucie src.
• Listy z doczytywaniem mają równoległe stronicowanie ze stałymi adresami.

Samodzielnie da się zwykle poprawić ustawienia wtyczek i pojedyncze obrazy wstawiane w edytorze. Pomoc specjalisty jest potrzebna, gdy źródłem problemu jest szablon motywu, kreator stron generujący własny kod albo skrypt doczytujący produkty. Leniwe ładowanie jest też tylko jednym z elementów, które składają się na podstawowe wskaźniki internetowe, dlatego w ramach usługi SEO technicznego oceniamy je razem z czasem odpowiedzi serwera i wagą plików. Punktem wyjścia bywa audyt SEO, który wskazuje, na których szablonach problem występuje.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl