Lazy loading to odkładanie ładowania obrazów, ramek i całych sekcji strony do chwili, w której są potrzebne. Korzystają z niego wtyczki cache, sklepy z długą listą produktów i serwisy z przyciskiem „pokaż więcej”. Google indeksuje stronę w postaci, jaką ma po wykonaniu skryptów, i nie przewija jej ani nie klika, więc do indeksu trafia tylko ta treść, która załaduje się sama.
Dlaczego lazy loading potrafi ukryć treść przed Google?
Bo wyszukiwarka ocenia stronę po wyrenderowanym HTML, czyli po tym, co zostaje w kodzie po wykonaniu JavaScriptu, bez żadnego gestu użytkownika. Dokumentacja Google Search Central mówi o tym jednym zdaniem: „Google Search does not interact with your page”, czyli nie przewija strony, nie klika ani nie przesuwa palcem po ekranie.
Skrypt, który czeka na zdarzenie scroll albo click, w trakcie renderowania się nie uruchomi. Treść, którą miał wstawić, nie pojawi się w wyrenderowanym HTML i nie zostanie zaindeksowana, choć w przeglądarce wygląda na obecną. Sam mechanizm pobierania i indeksowania opisuje wpis Crawlowanie a indeksowanie: czym się różnią?, a o tym, co Google robi ze skryptami, piszemy w tekście Czy Google widzi treść ładowaną przez JavaScript?
Wytyczne indeksowania mobilnego formułują to jako wymaganie: Google nie załaduje treści, która pojawia się dopiero po interakcji użytkownika, czyli po przesunięciu palcem, kliknięciu albo pisaniu.
Reguła jest jedna: treść, która ładuje się sama, trafia do indeksu. Treść, która czeka na gest użytkownika, dla Google nie istnieje.
Które sposoby ładowania treści Google widzi, a których nie?
Google wymienia trzy wdrożenia, które uznaje za bezpieczne: mechanizm wbudowany w przeglądarkę dla obrazów i ramek iframe, interfejs IntersectionObserver wraz z polyfillem oraz bibliotekę ładującą dane po wejściu elementu w widoczny obszar okna. Wszystkie łączy jedno: żadne nie czeka na ruch użytkownika.
🚫 Czego Google nie zobaczy
- ✕Treści doładowywanej po zdarzeniu
scroll,clicklubtouch, bo renderowanie odbywa się bez tych zdarzeń. - ✕Przycisku „pokaż więcej”, który dopiero po kliknięciu pobiera opis z serwera.
- ✕Kolejnych porcji listy w infinite scrollu, jeśli nie mają własnych adresów.
- ✕Obrazu z pustym atrybutem
srcalbo wyłącznie zdata-srcw wyrenderowanym HTML. - ✕Obrazu bez podanych wymiarów w kontenerze o zerowej wysokości.
✅ Co Google zobaczy
- ✓Obrazy i ramki
iframez atrybutemloading="lazy". - ✓Elementy obserwowane przez IntersectionObserver, gdy warunkiem doładowania jest ich położenie.
- ✓Bibliotekę, która ładuje dane po wejściu elementu w widoczny obszar okna.
- ✓Treść obecną w HTML i zwiniętą samym CSS-em. Wytyczne indeksowania mobilnego dopuszczają zakładki i akordeony pod warunkiem, że ich zawartość jest taka sama jak w wersji na komputer.
Jak wdrożyć lazy loading obrazów krok po kroku?
Obrazy są najprostszym przypadkiem, bo przeglądarki mają wbudowany mechanizm i nie trzeba do niego żadnego skryptu.
Wybierz obrazy poniżej pierwszego ekranu
Na odroczeniu zyskują zdjęcia w galerii, ikony w stopce i grafiki w dalszych sekcjach, ale nie obraz w nagłówku.
Dodaj loading="lazy"
Przeglądarka pobierze taki obraz dopiero wtedy, gdy zbliży się on do widocznego obszaru okna na odległość, którą sama wylicza. Wartością domyślną jest eager, czyli pobranie od razu.
Podaj width i height
Bez wymiarów niezaładowany obraz ma rozmiar 0 na 0 pikseli, więc nie przecina widocznego obszaru okna i nigdy się nie doładuje. Dokumentacja MDN traktuje to jako zachowanie zamierzone, nie błąd przeglądarki.
Obrazy z pierwszego ekranu zostaw na eager
Google odradza odkładanie treści widocznej zaraz po otwarciu strony, bo pojawia się ona z opóźnieniem, które użytkownik zauważa. Największy obraz w pierwszym ekranie decyduje przy tym o wyniku LCP.
Sprawdź efekt w wyrenderowanym HTML
Adresy obrazów mają się w nim znaleźć w atrybucie src elementów <img>.
Natywny lazy loading działa tylko przy włączonym JavaScripcie. To celowe zabezpieczenie przed śledzeniem, bo przy wyłączonych skryptach przeglądarka pobiera wszystkie obrazy od razu.
Jak ładować treść tekstową po przewinięciu, żeby Google ją zobaczył?
Najbezpieczniej wysłać ją w HTML od razu, a odraczać tylko to, co kosztuje transfer: zdjęcia, mapy, odtwarzacze wideo, ramki z zewnętrznych serwisów. Opisy kategorii, treść ofertowa, nagłówki i linki wewnętrzne zostają w kodzie generowanym przez serwer.
Gdy sekcja ma się doładowywać, użyj IntersectionObserver. To interfejs przeglądarki, który wywołuje funkcję w chwili, gdy obserwowany element zbliża się do widocznego obszaru okna. Warunkiem uruchomienia jest położenie elementu, a nie gest użytkownika, i to odróżnia ten mechanizm od nasłuchiwania zdarzenia scroll.
Obserwatorowi ustaw zapas odległości, żeby treść ładowała się, zanim znajdzie się w widocznym obszarze okna, a nie dokładnie na jego krawędzi. Przy okazji zmniejszasz liczbę osobnych żądań do serwera, co w dużym serwisie przekłada się na budżet indeksowania.
Co zrobić z przyciskiem „pokaż więcej”?
Wynik zależy od tego, czy treść jest już w HTML, czy zostanie pobrana dopiero po kliknięciu. Przycisk, który rozwija tekst obecny w kodzie strony, nie przeszkadza w indeksowaniu, a taki, który dociąga go z serwera, ukrywa ten fragment przed Google w całości.
- Długi opis kategorii lub produktu. Wyślij pełną treść w HTML i zwiń ją CSS-em, a przyciskiem zmieniaj tylko wysokość kontenera. Google ma wtedy cały tekst, użytkownik widzi skrót.
- Katalog realizacji, opinii lub wpisów. Przycisk może dobierać kolejne porcje, jeśli każda z nich ma własny adres, dostępny bezpośrednio i podlinkowany w kodzie.
- Treść za logowaniem lub formularzem. Nie zobaczy jej ani Google, ani użytkownik, który trafia z wyszukiwarki. Jeśli taka treść ma pracować na wynik strony, musi być dostępna bez logowania.
Test zajmuje chwilę: wyłącz w przeglądarce JavaScript i otwórz stronę. Co zostało na ekranie, jest w HTML, a co zniknęło, wymaga skryptu i trzeba to sprawdzić w Search Console.
Masz sklep albo katalog, w którym treść doładowuje się po przewinięciu?
Sprawdzimy w Search Console, co z tego widzi Google, i wskażemy poprawki w ramach pozycjonowania.
Jak wdrożyć infinite scroll, żeby Google zaindeksował kolejne strony?
Infinite scroll doładowuje kolejne porcje listy w miarę przewijania i sam z siebie nie daje wyszukiwarce żadnego adresu do pobrania. Google zaleca, żeby pod spodem działała zwykła paginacja. Dokumentacja podaje cztery reguły:
- Każda porcja ma własny, stały adres.
- Pod tym adresem za każdym razem ładuje się ta sama treść.
- W adresie używaj bezwzględnych numerów stron, na przykład parametru
?page=12. Wartości względne w rodzaju?date=yesterdayodpadają, bo treść pod nimi się zmienia. - Adresy są podlinkowane po kolei, żeby wyszukiwarka mogła je odkryć.
Gdy użytkownik przewinie stronę do kolejnej porcji i to ona zajmie główną część ekranu, podmień adres w pasku przeglądarki przez History API. Dzięki temu odświeżenie i udostępnienie linku prowadzą do tego samego miejsca listy. Ten sam mechanizm History API stoi za routingiem w SPA – opisujemy go we wpisie pozycjonowanie aplikacji jednostronicowej.
W sklepie ten sam efekt daje zwykła paginacja kategorii, opisana we wpisie Jak ustawić paginację kategorii w sklepie? Infinite scroll jest wtedy warstwą wygody dla użytkownika, a nie jedynym sposobem dotarcia do produktów.
Jak ustawić lazy loading w WordPressie?
Od WordPressa 5.5 atrybut loading="lazy" dokłada się sam, więc wdrożenie zaczyna się od sprawdzenia, ile mechanizmów działa naraz. Najczęstszy problem to nie brak lazy loadingu, tylko dwa mechanizmy nałożone na siebie: rdzeń i wtyczka cache.
| Źródło | Co robi | Na co uważać |
|---|---|---|
| WordPress | Dokłada loading="lazy" do obrazów w treści wpisu, zajawkach, widżetach tekstowych, awatarach i w wp_get_attachment_image(). Atrybut trafia tylko do obrazów z podaną szerokością i wysokością. Od wersji 5.9 rdzeń pomija pierwsze trzy elementy multimedialne w treści, a od 6.3 obraz nagłówkowy dostaje fetchpriority="high" i decoding="async". | Próg pierwszych elementów zmienia filtr wp_omit_loading_attr_threshold, a cały mechanizm wyłącza wp_lazy_loading_enabled. Zmiana progu bez powodu psuje LCP. |
| Wtyczka cache | LiteSpeed Cache i podobne wtyczki mają własne leniwe ładowanie na skrypcie: podmieniają adres obrazu na placeholder lub rozmytą miniaturę, a element w trakcie ładowania nosi atrybut data-lazyloaded. | To właśnie wariant z data-src, który trzeba sprawdzić w wyrenderowanym HTML. Obrazy z pierwszego ekranu i logo wpisz do pola wykluczeń po fragmencie adresu. |
| Motyw i kreator | Galerie, suwaki i sekcje budowane wtyczką do stron bywają ładowane własnym skryptem, niezależnym od dwóch pozostałych mechanizmów. | Suwak, który buduje slajdy po załadowaniu strony, zostawia w kodzie pustą ramkę. Zdjęcia z takiego suwaka nie trafiają do wyników grafiki. |
Kolejność działań jest prosta: zostaw jeden mechanizm, wyklucz z niego obrazy z pierwszego ekranu i sprawdź stronę po każdej zmianie ustawień wtyczki.
Jak sprawdzić, czy Google widzi leniwie ładowaną treść?
Zobaczysz to w Google Search Console, narzędziem Sprawdzanie adresu URL, na karcie z kodem HTML po renderowaniu. Dokumentacja podaje kryterium wprost: wdrożenie jest poprawne, gdy adresy obrazów i filmów widać w atrybucie src elementów <img> i <video> w wyrenderowanym HTML.
Dla treści tekstowej metoda jest ta sama: skopiuj fragment zdania widocznego w przeglądarce i poszukaj go w kodzie na karcie HTML. Brak dopasowania oznacza, że skrypt się nie wykonał albo czeka na gest użytkownika. Całą procedurę, razem z różnicą między wersją z indeksu a testem na żywo, opisuje wpis Czy Google widzi treść ładowaną przez JavaScript?
Test powtarzaj po każdej zmianie ustawień wtyczki cache i po każdej aktualizacji motywu. Lazy loading psuje się cicho: strona wygląda tak samo, a z kodu znika połowa zdjęć.
Nie wiesz, czy po włączeniu wtyczki cache Google nadal widzi opisy i zdjęcia?
Napisz do nas, sprawdzimy to i podpowiemy, co zmienić.
FAQ
Nie, dopóki treść ładuje się bez udziału użytkownika. Google wymienia trzy poprawne metody wdrożenia i traktuje je jako dobrą praktykę wydajnościową. Szkodzi dopiero wariant, w którym treść pojawia się po przewinięciu lub kliknięciu.
Wystarczy, pod warunkiem że obraz ma podaną szerokość i wysokość oraz prawdziwy adres w atrybucie src. Bez wymiarów niezaładowany obraz zajmuje 0 na 0 pikseli i nie doładuje się nigdy. Potwierdzisz to jednym zapytaniem w narzędziu Sprawdzanie adresu URL.
Zobaczy je tylko wtedy, gdy skrypt podmieni data-src na src w trakcie renderowania, bez przewijania strony. Tak działa większość wtyczek cache i zwykle wychodzi to poprawnie, ale wynik trzeba sprawdzić w wyrenderowanym HTML. Obraz, który zostaje z samym data-src, dla wyszukiwarki nie istnieje.
Tak, jeśli jest obecna w kodzie strony i ukryta wyłącznie CSS-em. Wytyczne indeksowania mobilnego dopuszczają takie układy pod warunkiem, że treść jest ta sama co w wersji na komputer. Do indeksu nie trafia natomiast treść pobierana z serwera dopiero po rozwinięciu zakładki.
Nie. Obrazy widoczne zaraz po otwarciu strony mają ładować się od razu, bo odroczenie opóźnia ich pojawienie się na ekranie. WordPress stosuje tę zasadę sam, pomijając trzy pierwsze elementy multimedialne w treści.
Źródła
- Google Search Central, „Fix lazy-loaded content”: developers.google.com
- Google Search Central, „Mobile-first indexing best practices”: developers.google.com
- MDN Web Docs, element
<img>, atrybutloading: developer.mozilla.org - WordPress Developer Resources,
wp_omit_loading_attr_threshold()iwp_get_loading_optimization_attributes(): developer.wordpress.org - Make WordPress Core, „Lazy-loading images in 5.5”: make.wordpress.org
- LiteSpeed Cache, dokumentacja „Page Optimization”: docs.litespeedtech.com
