Leniwe ładowanie

TL;DR — Leniwe ładowanie każe przeglądarce odroczyć pobieranie obrazów i osadzonych elementów do chwili, gdy użytkownik prawie do nich przewinie, dzięki czemu początek strony ładuje się szybciej. Najprostsza metoda bez kodu to dodanie loading="lazy" do <img> lub <iframe>. Zapamiętaj jedną zasadę: nie ładuj leniwie dużego obrazu na górze strony, bo sprawi to wrażenie wolniejszego, a nie szybszego działania.

Czym jest leniwe ładowanie

Zwykle, gdy przeglądarka otwiera stronę, próbuje pobrać wszystko, co się na niej znajduje — każdy obraz, każdą osadzoną mapę czy wideo — od razu. Na długiej stronie z wieloma obrazami to dużo pobierania dla treści, których możesz nigdy nie przewinąć, aby zobaczyć.

Leniwe ładowanie to naprawia. Odracza ładowanie obrazów i osadzonych elementów poza ekranem, dopóki nie przewiniesz ich do widoku. Strona szybko pokazuje to, co jest na górze, a reszta ładuje się w miarę przewijania. Mniej danych na początku oznacza szybsze pierwsze wrażenie, oraz oszczędność przepustowości i baterii — co ma największe znaczenie na telefonach.

Prosty sposób: atrybut loading

Kiedyś potrzebowałeś do tego biblioteki JavaScript. Już nie. Nowoczesne przeglądarki mają to wbudowane. Wystarczy dodać jeden atrybut:

<img src="photo.jpg" loading="lazy" alt="…">

To wszystko. Działa na <img> i <iframe> (pomyśl o osadzonych filmach z YouTube, Google Maps, widgetach społecznościowych) w każdej głównej przeglądarce, bez JavaScript.

Jeden błąd, którego należy unikać

Nie stosuj leniwego ładowania do dużego obrazu na górze strony — obrazu hero, rzeczy, którą ludzie widzą jako pierwszą. Leniwe ładowanie mówi przeglądarce „to może poczekać”, więc leniwie ładowany obraz na górze ładuje się później, niż powinien, i strona wydaje się wolniejsza. Wskazówki Google mówią, aby pominąć leniwe ładowanie dla wszystkiego, co jest widoczne od razu po otwarciu strony.

Krótko mówiąc: leniwie ładuj treści poniżej linii zagięcia, a treści powyżej linii zagięcia ładuj normalnie.

Czy to szkodzi SEO?

Samo w sobie nie. Google może indeksować leniwie ładowane obrazy i treści bez problemu, gdy jest to zrobione w normalny sposób. Problemy zaczynają się dopiero, gdy strona ukrywa treść za przewijaniem lub klikaniem — ponieważ wyszukiwarki nie przewijają ani nie klikają. Jeśli Twoje obrazy po prostu używają loading="lazy", jesteś bezpieczny. Chcesz poznać szczegóły, jak Google faktycznie to widzi i jak to sprawdzić? Przełącz się na zakładkę Zaawansowane.

TL;DR — Leniwe ładowanie odracza obrazy i ramki poza ekranem do chwili, gdy zbliżą się do viewportu, zmniejszając początkową wagę strony i pracę głównego wątku. Natywny atrybut loading="lazy" w <img> i <iframe> zastąpił większość bibliotek JavaScript; znaczenie mają tylko wartości lazy i eager, a auto jest przestarzałe. Szkodliwe błędy to leniwe ładowanie obrazu LCP lub widocznego nad linią zagięcia oraz ukrywanie treści za przewijaniem albo kliknięciem, którego Googlebot nie wykona. Nie jest to bezpośredni czynnik rankingowy; wpływ przebiega przez Core Web Vitals i możliwość crawlowania. W narzędziu do sprawdzania adresów URL potwierdź, że adresy obrazów trafiają do atrybutu src wyrenderowanego HTML.

Co właściwie robi leniwe ładowanie

Pomysł jest prosty: ładuj zasoby tylko wtedy, gdy ich potrzebujesz, zamiast ładować wszystko naraz. Na stronie z dużą ilością multimediów pobieranie każdego obrazu i osadzonego elementu z góry zajmuje przeglądarkę pobieraniem rzeczy, których odwiedzający może nigdy nie przewinąć — marnując przepustowość, pamięć i baterię na nic. Odroczenie tych poza ekranem pozwala na szybsze wyświetlenie treści nad linią zagięcia. Martin Splitt dokładnie to zauważył w odcinku firmowego podcastu Google „Leniwe ładowanie bez tajemnic”: Celem jest unikanie pracy, która nic nie daje, ponieważ niekrytyczne obrazy, bez których strona mogłaby się obejść, po prostu zajmują przeglądarkę.

To łączy się z Core Web Vitals, które większość osób stara się osiągnąć. Mniej bajtów konkurujących o sieć na początku oznacza, że element Largest Contentful Paint może się wyrenderować wcześniej. W przypadku iframe — reklam, widgetów społecznościowych, sekcji komentarzy, map — odroczenie ich również zmniejsza pracę głównego wątku podczas startu, co jest wygraną dla Interaction to Next Paint, a nie tylko dla LCP. Wskazówki Google na web.dev opisują leniwie ładowane iframe jako ulepszenie INP podczas ładowania strony.

Natywne a sterowane JavaScriptem leniwe ładowanie

Kilka lat temu przeglądarki zyskały natywny atrybut loading dla obrazów i iframe, więc możesz przekazać całą pracę przeglądarce zamiast podłączać API JavaScriptu. W moim przewodniku po SEO dla JavaScriptu w Ahrefs zauważam to samo: odkąd napisałem ten artykuł, leniwe ładowanie w większości przeszło z bycia sterowanym JavaScriptem do obsługi przez przeglądarki. Nadal spotkasz konfiguracje sterowane JS, a w przypadku obrazów zwykle są one w porządku — sprawdzam, czy faktyczna treść (nie tylko obrazy) jest ładowana leniwie, ponieważ to te konfiguracje powodowały, że treść nie była poprawnie pobierana.

Wersja natywna:

<!-- Below-the-fold image: defer it -->
<img src="gallery-07.jpg" loading="lazy" width="800" height="600" alt="…">

<!-- Off-screen embed: defer it -->
<iframe src="https://www.youtube.com/embed/…" loading="lazy" title="…"></iframe>

Zawsze ustawiaj jawne width/height (lub aspect-ratio) na leniwych obrazach, aby przeglądarka zarezerwowała miejsce przed załadowaniem obrazu — to największe ryzyko przesunięcia układu przy odroczonych obrazach. Zarezerwowane wymiary nie są jednak absolutną gwarancją CLS: jeśli otaczający układ lub responsywne przycięcie nadal zmieni się po załadowaniu obrazu, nadal możesz zobaczyć przesunięcie, więc potwierdź to prawdziwym śladem przesunięcia układu, zamiast zakładać, że same stałe wymiary to rozwiążą.

Leniwe ładowanie i iframe wymagają jeszcze jednego rozróżnienia: loading="lazy" na <iframe> tylko odracza kiedy nastąpi pobranie i utworzenie osadzenia. Nie ustawia za Ciebie jego title, zachowania fokusu, sandbox, allow/polityki uprawnień, referrerpolicy, obsługi zgody ani wymiarów — te nadal wymagają własnej uwagi, a osadzenie może nadal wykonywać pracę (skrypty, piksele śledzące, układ), gdy stanie się kwalifikowane do załadowania. I nie zakładaj, że „poniżej krawędzi” działa wszędzie tak samo: treść z display: none, slajdy karuzeli poza ekranem, transformowane elementy i zagnieżdżone kontenery przewijane mogą przecinać viewport inaczej niż zwykły element poniżej krawędzi, więc przetestuj faktyczny układ i elementy nawigacji, zamiast zakładać równoważność.

Wartości atrybutu loading

Obecnie liczą się tylko dwie wartości:

• loading="lazy" — odrocz zasób, dopóki nie znajdzie się blisko viewportu.
• loading="eager" — załaduj go natychmiast, to domyślne zachowanie. Użyj tego, aby jawnie oznaczyć obrazy powyżej krawędzi.

Możesz zobaczyć loading="auto" w starszych artykułach — jest przestarzałe w Chrome, więc po nie sięgaj. Nie ma takiej potrzeby; pominięcie atrybutu już daje ci domyślne (eager) zachowanie.

Jak blisko jest „blisko”? loading="lazy" to wskazówka, a nie gwarancja kontrolowana przez autora — specyfikacja pozostawia faktyczną decyzję o bliskości viewportu przeglądarce. Chromium stara się pobrać leniwy zasób wystarczająco wcześnie, aby był gotowy, zanim do niego przewiniesz, a odległość wyzwalania różni się w zależności od przeglądarki, prędkości połączenia i typu zasobu; nie jest to stała wartość w pikselach, na której możesz polegać lub którą możesz odtworzyć w różnych przeglądarkach lub wersjach. Nie publikuj — ani nie ufaj — konkretnej liczbie „ładuje N pikseli przed viewportem”; traktuj okno bliskości viewportu jako zdefiniowane przez implementację i potwierdź faktyczne zachowanie śladem sieciowym w przeglądarce/połączeniu, które Cię interesuje, zamiast zakładać stałą.

Natywne leniwe ładowanie dobrze współgra również z obrazami responsywnymi: dotyczy zwykłego src oraz wyboru srcset/sizes, więc nie tracisz zachowania responsywnych obrazów przez dodanie loading="lazy". Jeśli natomiast ukryjesz prawdziwy URL tylko w atrybucie data-*, aby skrypt podmienił go później, ładowanie zależy teraz od tego skryptu — przetestuj wyrenderowany HTML i sprawdź, co się stanie, jeśli skrypt zawiedzie (więcej na ten temat w zakładkach Skrypty i Rozwiązywanie problemów).

Błąd nr 1: leniwe ładowanie obrazu LCP / obrazu nad zakładką

To najczęstszy błąd, jaki widuję, i wszystkie źródła się z tym zgadzają. Jeśli leniwie ładujesz obraz hero — lub dowolny obraz, który prawdopodobnie będzie elementem LCP — mówisz przeglądarce, aby czekała na najważniejszy piksel dla postrzeganej szybkości ładowania. Przeglądarka nie może też leniwie załadować obrazu, dopóki nie wie, gdzie obraz będzie się znajdować na stronie, więc leniwe ładowanie obrazów nad zakładką zwykle działa wolniej niż natychmiastowe. To bezpośrednio opóźnia Largest Contentful Paint, metrykę, którą Google zaleca rozwiązać w ciągu pierwszych 2,5 sekundy ładowania.

Splitt przedstawił drugą stronę jasno w odcinku SOTR: jeśli nie używasz leniwego ładowania tam, gdzie powinieneś, prawdopodobnie zaszkodzi to niektórym aspektom Core Web Vitals — najprawdopodobniej LCP. Więc to działa w obie strony. Zasada:

• Prawdopodobny lub zaobserwowany kandydat na LCP → ładuj natychmiast (pomiń loading="lazy" lub ustaw eager). Rozważ fetchpriority="high" na obrazie LCP.
• Poniżej zakładki → loading="lazy".

Nie każdy obraz nad zakładką jest kandydatem na LCP — zidentyfikuj ten właściwy (trace Performance lub PageSpeed Insights go wskaże) i zweryfikuj jego czasy żądań, zamiast traktować wszystkie obrazy na pierwszym ekranie tak samo. To osobne wskazówki, nie jedno ustawienie: loading="eager" (lub pominięcie loading) oznacza tylko, że przeglądarka nie odroczy odkrycia zasobu — samo w sobie nie podnosi priorytetu pobierania. fetchpriority to odrębna, doradcza wskazówka na dodatek. Łączenie <link rel="preload"> z loading="lazy" na tym samym zasobie wysyła przeglądarce sprzeczne intencje, więc sprawdź rzeczywisty wodospad sieciowy, zamiast zakładać, że kombinacja działa tak, jak oczekujesz.

Ogólnym antywzorcem jest włączanie leniwego ładowania dla każdego obrazu w całej witrynie — to częsty domyślny stan CMS. Jak zauważył Splitt, jeśli każdy obraz jest leniwie ładowany, to obrazy, które są (lub powinny być) natychmiast widoczne, również są leniwie ładowane, co jest dokładnie przypadkiem, którego chcesz uniknąć.

Jak Googlebot renderuje leniwie ładowane treści

Oto rzeczywistość indeksowania, która zaskakuje ludzi: Googlebot nie przewija strony i nie klika. Renderuje Twoją stronę w przeglądarce bezgłowej, ale nie symuluje użytkownika interagującego z nią. Google stwierdza to wprost — jego zalecane metody leniwego ładowania celowo nie polegają na działaniach użytkownika, takich jak przewijanie czy klikanie, ponieważ Google Search nie wchodzi w interakcję z Twoją stroną.

Dlatego właśnie sposób implementacji ma znaczenie. Dokumentacja Google wymienia trzy implementacje, które uważa za bezpieczne: wbudowane leniwe ładowanie przeglądarki dla obrazów i iframe, API IntersectionObserver (z polyfillem) lub biblioteka JavaScript, która ładuje dane, gdy wchodzą w obszar widoczny. Wszystkie trzy opierają się na przecięciu z obszarem widocznym — nie na zdarzeniu przewijania lub kliknięcia, którego Googlebot nigdy nie wywoła.

Wzorzec wysokiego ryzyka to niestandardowa lub zewnętrzna biblioteka JS do leniwego ładowania. Jeśli biblioteka zachowuje się nieprawidłowo, a URL obrazu nigdy nie trafi do atrybutu src, Google po prostu nie pobierze tego obrazu — Splitt opisał dokładnie ten tryb awarii w odcinku SOTR. Nie ma czego indeksować, jeśli URL nie jest tam obecny. To samo sygnalizuję w moim przewodniku po JavaScript SEO: leniwe ładowanie obrazów jest zwykle w porządku, ale leniwie ładowane treści to miejsce, gdzie pojawiają się problemy z indeksowaniem, a rozwiązaniem jest sprawdzenie, co Google faktycznie renderuje.

Nieskończone przewijanie to inny problem

Nie myl podstawowego leniwego ładowania obrazów/iframe z nieskończonym przewijaniem lub ładowaniem paginowanym. Odraczanie obrazów to jedno; ładowanie nowych fragmentów treści podczas przewijania przez użytkownika to drugie i wymaga własnej architektury. Wytyczne Google: nadaj każdemu fragmentowi stały, unikalny URL, utrzymuj treść stabilną dla każdego URL (używaj bezwzględnych numerów stron, takich jak ?page=12, a nie względnych wartości, takich jak ?date=yesterday), i aktualizuj wyświetlany URL za pomocą History API, gdy każdy fragment staje się główną widoczną treścią, tak aby można go było odświeżyć, udostępnić i linkować. Pomiń to, a głębsza treść za nieskończonym przewijaniem może nigdy nie zostać niezawodnie przeszukana ani zaindeksowana.

Jak to przetestować

Ścieżka weryfikacji jest taka sama w dokumentacji Google i w mojej własnej metodologii: użyj narzędzia URL Inspection w Search Console i sprawdź wyrenderowany HTML. Jeśli URL-e Twoich obrazów (lub filmów) pojawiają się w atrybucie src na elementach <img>/<video> w tym wyrenderowanym HTML, Twoja konfiguracja działa. Google mówi to wprost — sprawdź wyrenderowany HTML zgodnie z instrukcją: “Check the rendered HTML to make sure your content is in the rendered HTML” (tłumaczenie) „Sprawdź wyrenderowany HTML, aby upewnić się, że znajduje się w nim Twoja treść”. Jeśli URL brakuje w src, to jest Twój problem i zwykle wskazuje na trigger przewijania/kliknięcia lub uszkodzoną bibliotekę.

W przypadku leniwie ładowanej siatki produktów wyjdź poza tę kontrolę obecności. Uruchom macierz testowania SEO dla nieskończonego przewijania ze standardowymi i wysokimi rzutniami, świeżą nawigacją i zmianą rozmiaru po załadowaniu, przebiegami bez akcji i z przyrostowym przewijaniem, liczbami unikalnych linków do produktów oraz inspekcją drzewa dostępności. Zmiana rozmiaru zainicjalizowanej strony nie jest równoważna nawigacji przy końcowym rozmiarze rzutni, ponieważ obserwatory i obliczenia wsadowe mogą być rejestrowane tylko podczas uruchamiania. Dowód potwierdzający to twierdzenie Google Search does not scroll or click to trigger lazy-loaded content, so implementations should not depend on user interaction and should expose resource URLs in rendered HTML. Zakres: Google Search guidance for JavaScript-driven lazy loading. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google Search Central: Lazy-load content

Możesz też polegać na narzędziach do wydajności sieci: PageSpeed Insights flaguje obrazy poza ekranem, które powinieneś odraczać. W moim przewodniku po PageSpeed Insights w Ahrefs zauważam, że audyt “defer offscreen elements” mówi Ci, aby leniwie ładować obrazy — to wygodny sposób na połączenie diagnostyki, którą już uruchamiasz, z rozwiązaniem.

Uczciwość w kwestii sygnałów rankingowych

Bądź jasny co do tego, czym leniwe ładowanie jest, a czym nie jest. Używanie go nie jest bezpośrednim czynnikiem rankingowym, a nie używanie go nie jest karą. Związek z rankingami jest pośredni: płynie przez Core Web Vitals (głównie LCP, czasami INP dla iframe) oraz przez możliwość przeszukiwania, jeśli zła implementacja ukrywa treść. Splitt scharakteryzował wpływ na ranking przez Core Web Vitals jako drobny, minimalny czynnik w większości przypadków. Optymalizuj więc leniwe ładowanie dla doświadczenia ładowania Twoich użytkowników i dla czystego indeksowania — nie dlatego, że oczekujesz wzrostu rankingu od samego atrybutu.

Gdzie to pasuje

Leniwe ładowanie to jedna z dźwigni w szerszym zestawie narzędzi wydajności sieci. Łączy się z wskazówkami dotyczącymi zasobów (preload/preconnect dla zasobów, które chcesz wcześnie), strategią ładowania czcionek, buforowaniem i CDN — i jest oceniane ostatecznie przez Core Web Vitals. Odpowiednio podziel treść nad i pod linią zagięcia, a będzie to jedna z najtańszych dostępnych wygranych.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Lazy loading odkłada ładowanie obrazów i iframe’ów poza ekranem, dopóki nie zbliżą się do viewportu — zmniejszając początkową wagę strony i pracę przy starcie. Natywny sposób bez JS to loading="lazy" na <img> i <iframe>; w dużej mierze zastąpił biblioteki JS. To wskazówka dla przeglądarki, a nie gwarantowana odległość ani czas — punkt wyzwalania różni się w zależności od przeglądarki, połączenia i typu zasobu, więc nie polegaj na stałej liczbie pikseli.
• Wartości: liczą się tylko lazy i eager. auto jest przestarzałe w Chrome.
• Związek z Core Web Vitals: mniejsza liczba bajtów na starcie pomaga LCP; odroczenie iframe’ów zmniejsza pracę głównego wątku przy starcie, pomagając INP. Ustaw width/height, aby odroczone obrazy nie powodowały CLS — choć zarezerwowane wymiary same w sobie nie gwarantują zerowego przesunięcia, jeśli otaczający układ nadal się zmienia.
• Błąd #1: lazy loading prawdopodobnego/obserwowanego obrazu LCP, a nie tylko dowolnego obrazu powyżej linii zagięcia. Opóźnia to Largest Contentful Paint, które według Google powinno rozwiązać się w ciągu 2,5 s. eager/pominięcie loading wpływa tylko na wykrycie — samo w sobie nie podnosi priorytetu pobierania; fetchpriority to osobna wskazówka, a łączenie preload z loading="lazy" na tym samym zasobie jest sprzeczne. Masowe lazy loading na całej stronie to typowy antywzorzec CMS.
• Iframe’y mają własny kontrakt: loading="lazy" tylko opóźnia czas pobierania/tworzenia — title, sandbox, polityka uprawnień, polityka referrer, zgoda i wymiary nadal muszą być ustawione niezależnie, a ukryte/karuzelowe/przekształcone układy mogą przecinać viewport inaczej niż zwykły element poniżej linii zagięcia.
• Googlebot nie przewija ani nie klika. Treści ukryte za zdarzeniami przewijania/kliknięcia mogą pozostać niezauważone. Bezpieczne metody Google — natywne lazy loading, IntersectionObserver lub dobrze działająca biblioteka JS — wszystkie opierają się na przecięciu z viewportem.
• Najwyższe ryzyko: niestandardowe/zewnętrzne biblioteki JS do lazy loadingu. Jeśli URL nigdy nie trafi do src, Google nie zaindeksuje obrazu (według Martina Splitta).
• Infinite scroll to co innego: wymaga unikalnych paginowanych URL-i + History API.
• Weryfikacja w Search Console URL Inspection → rendered HTML → URL-e obrazów obecne w atrybucie src.
• Nie jest to bezpośredni czynnik rankingowy. Efekt jest pośredni, poprzez Core Web Vitals i możliwość indeksowania, a Splitt nazwał wpływ Core Web Vitals na ranking niewielkim.

Oficjalna dokumentacja

Wytyczne z pierwotnych źródeł od wyszukiwarek i Google web.dev.

Google — Search Central

• Naprawianie leniwie ładowanej treści witryny — definitywny dokument: bezpieczne metody implementacji, zasada „Google nie wchodzi w interakcje z Twoją stroną”, wymagania dotyczące nieskończonego przewijania i paginowanego ładowania oraz sposób weryfikacji w wyrenderowanym HTML.
• Podstawy SEO dla JavaScriptu — zaleca leniwe ładowanie obrazów jako najlepszą praktykę dotyczącą przepustowości i wydajności oraz linkuje do dedykowanego przewodnika.
• Core Web Vitals — dlaczego lazy loading elementu LCP jest samopokonujący (cel LCP to 2,5 s).

Google — web.dev (Learn Performance)

• Leniwe ładowanie obrazów i elementów <iframe> — kiedy odraczać oraz korzyść INP z odroczonych ramek.
• Leniwe ładowanie obrazów na poziomie przeglądarki — natywny atrybut i dlaczego nie należy leniwie ładować obrazów w viewporcie lub elementu LCP.
• Czas leniwie ładować ramki poza ekranem — przypadek specyficzny dla ramek (reklamy, widżety, mapy).
• Leniwe ładowanie na poziomie przeglądarki dla systemów CMS — wytyczne dla platform CMS.

Podcast firmowy Google

• Odcinek 98: „Leniwe ładowanie bez tajemnic” (21 sie 2025) — John Mueller i Martin Splitt o leniwym ładowaniu, renderowaniu, indeksowaniu i Core Web Vitals. Odcinek znajduje się również w archiwum podcastu Google.

Dokumentacja dla programistów (nie dotyczy SEO, ale jest autorytatywna w kwestii API)

• MDN — leniwe ładowanie (przewodnik po wydajności)
• MDN — HTMLImageElement: właściwość loading
• caniuse — Lazy loading przez atrybut dla obrazów i iframe

Bing / Microsoft

• Bing nie publikuje dedykowanego dokumentu o leniwym ładowaniu. Jego ogólne Wytyczne dla webmasterów obejmują szeroko crawling i renderowanie JS. Bingbot renderuje za pomocą przeglądarki headless opartej na Chromium i, podobnie jak Googlebot, nie przewija ani nie klika — więc to samo natywne podejście loading="lazy" / IntersectionObserver, które spełnia wymagania Google, powinno spełniać wymagania Bing. Ten ostatni punkt jest wnioskiem z ogólnego zachowania renderowania Bingbota, a nie źródłowym oświadczeniem Bing na temat leniwego ładowania — traktuj go odpowiednio.

Cytaty ze źródła

Oficjalne oświadczenia z dokumentacji Google. Każdy link to link bezpośredni, który przeskakuje do cytowanego fragmentu na stronie źródłowej.

Google — Search Central, „Fix Lazy-Loaded Website Content”

• “Deferring loading of non-critical or non-visible content, also commonly known as ‘lazy-loading’, is a common performance and UX best practice.” (tłumaczenie) „Odraczanie ładowania treści niekrytycznych lub niewidocznych, znane również jako „lazy-loading”, to powszechna dobra praktyka w zakresie wydajności i UX.” Przejdź do cytatu
• “However, if not implemented correctly, this technique can inadvertently hide content from Google. This document explains how to make sure Google can crawl and index lazy-loaded content.” (tłumaczenie) „Jeśli jednak technika ta nie zostanie wdrożona prawidłowo, może nieumyślnie ukryć treść przed Google. Ten dokument wyjaśnia, jak zapewnić, aby Google mogło przeszukiwać i indeksować treści ładowane leniwie.” Przejdź do cytatu
• “The methods mentioned don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (tłumaczenie) „Wspomniane metody nie polegają na działaniach użytkownika, takich jak przewijanie czy klikanie, aby załadować treść, co jest ważne, ponieważ Google Search nie wchodzi w interakcje z Twoją stroną.” Przejdź do cytatu
• “Don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page. That might cause content to take longer to load and show up in the browser, which will be very noticeable to the user.” (tłumaczenie) „Nie dodawaj leniwego ładowania do treści, które prawdopodobnie będą natychmiast widoczne, gdy użytkownik otworzy stronę. Może to spowodować, że treść będzie ładować się dłużej i pojawi się w przeglądarce później, co będzie bardzo zauważalne dla użytkownika.” Przejdź do cytatu
• “Give each chunk its own persistent, unique URL.” — o nieskończonym przewijaniu / ładowaniu paginowanym. (tłumaczenie) „Nadaj każdej części własny, trwały, unikalny URL.” Przejdź do cytatu

Lista kontrolna leniwego ładowania

Uruchom to przed wdrożeniem zmiany dotyczącej leniwego ładowania:

• Obraz hero / LCP NIE jest leniwie ładowany — ładuje się natychmiast (pomiń loading="lazy"), najlepiej z fetchpriority="high".
• loading="lazy" jest zastosowane do obrazów i iframe, które znajdują się poniżej linii zagięcia.
• Leniwie ładowane obrazy mają jawne width/height (lub aspect-ratio), aby nie powodować przesunięcia układu (CLS), gdy się wczytają.
• Żadna treść nie jest blokowana za zdarzeniem przewinięcia lub kliknięcia — Googlebot ich nie wywoła. Użyj natywnego leniwego ładowania lub IntersectionObserver.
• Nie używasz przestarzałej wartości loading="auto" — tylko lazy/eager.
• Iframe poza ekranem (osadzenia, reklamy, mapy, widżety) używają loading="lazy", aby zmniejszyć pracę głównego wątku podczas uruchamiania.
• Leniwie ładowane iframe nadal mają własne title, sandbox, allow/politykę uprawnień, referrerpolicy i jawne wymiary — loading="lazy" tylko opóźnia czas pobierania, a nie te atrybuty.
• Zweryfikowano w Search Console URL Inspection → rendered HTML, że adresy URL obrazów/filmów pojawiają się w atrybucie src.
• Jeśli używasz biblioteki JS do leniwego ładowania innej firmy, potwierdzono, że src nadal jest wypełnione w wyrenderowanym HTML.
• W przypadku nieskończonego przewijania każda część ma unikalny, trwały, paginowany adres URL, a History API aktualizuje wyświetlany adres URL.
• Flagi PageSpeed Insights „defer offscreen images” są rozwiązane.

Antywzorce leniwego ładowania (mity i błędy)

Każdy z nich to powszechne przekonanie lub nawyk, dlaczego jest błędny i co zrobić zamiast tego.

„Leniwe ładowanie jest zawsze dobre, więc zastosuj je do każdego obrazu.” Dlaczego to błąd: ogólne leniwe ładowanie w całej witrynie obejmuje również obraz hero/LCP, co opóźnia Largest Contentful Paint — odwrotność korzyści szybkości, którą chciałeś uzyskać. Zamiast tego: leniwie ładuj tylko treści poniżej linii zagięcia; obrazy powyżej linii zagięcia ładuj natychmiast.

„Google w ogóle nie indeksuje leniwie ładowanych treści.” Dlaczego to błąd: Google indeksuje leniwie ładowane treści bez problemu, gdy są one realizowane za pomocą natywnego leniwego ładowania, IntersectionObserver lub dobrze działającej biblioteki. Ryzyko jest specyficzne dla konfiguracji blokowanych przewijaniem/kliknięciem lub uszkodzonych — według słów samego Google, problem występuje, gdy jest to „not implemented correctly.” Zamiast tego: użyj metody przecięcia z widokiem i zweryfikuj w wyrenderowanym HTML.

„loading='auto' to dobry domyślny wybór.” Dlaczego to błąd: auto jest przestarzałe w Chrome; zalecanie go to nieaktualna porada. Zamiast tego: użyj lazy dla zasobów poza ekranem, eager (lub nic) dla pozostałych.

„Leniwe ładowanie i nieskończone przewijanie to to samo rozwiązanie.” Dlaczego to błąd: to różne rzeczy. Nieskończone przewijanie dodatkowo wymaga unikalnych paginowanych adresów URL i aktualizacji History API, w przeciwnym razie głębsza treść może nigdy nie być niezawodnie indeksowana. Zamiast tego: traktuj paginowane/nieskończone ładowanie jako osobną architekturę z adresami URL dla każdej części.

„loading='lazy' działa na dowolnym elemencie.” Dlaczego to błąd: jest określony dla <img> i <iframe>. Wsparcie dla innych elementów nie jest częścią podstawowej specyfikacji w ten sam sposób. Zamiast tego: użyj atrybutu na obrazach i iframe; obsługuj inne multimedia odpowiednią techniką (dla wideo, obraz plakatu, który ładuje wideo po wejściu w widok).

„Leniwe ładowanie szkodzi SEO.” Dlaczego to błąd: samo leniwe ładowanie nie jest karą. Efekt istotny dla rankingu działa poprzez Core Web Vitals i jest niewielki; szkodzi słaba implementacja, a nie technika. Zamiast tego: zaimplementuj to poprawnie, wyklucz obraz LCP i zweryfikuj, co się renderuje.

Ściągawka leniwego ładowania

Atrybut loading

Które elementy to obsługują

• <img> — tak
• <iframe> — tak
• Inne elementy (wideo/audio) — nie są częścią podstawowej specyfikacji w ten sam sposób; użyj wzorca obraz plakatu + ładowanie po wejściu w widok dla wideo.

Powyżej vs. poniżej linii zagięcia

• Powyżej linii zagięcia / prawdopodobny LCP → eager (nigdy lazy). Dodaj fetchpriority="high" do obrazu LCP.
• Poniżej linii zagięcia → lazy.

Wpływ na Core Web Vitals

• Odraczanie obrazów poza ekranem → pomaga LCP (mniej bajtów konkuruje na początku).
• Odraczanie iframe’ów poza ekranem → pomaga INP (mniej pracy głównego wątku podczas startu).
• Brak width/height przy leniwych obrazach → może zaszkodzić CLS (przesunięcie układu podczas ładowania).

Zasady, na które zwraca uwagę Googlebot

• Googlebot nie przewija ani nie klika — brak treści zależnych od przewijania lub klikania.
• Bezpieczne metody: natywne loading="lazy", IntersectionObserver, dobrze działająca biblioteka JS.
• Weryfikacja: URL Inspection → wyrenderowany HTML → URL obrazu w atrybucie src.
• Nieskończone przewijanie ≠ leniwe ładowanie obrazów — wymaga unikalnych adresów URL z paginacją + History API.

Przed / po

Konkretne poprawki, sformułowane tak, jakbyś je napotkał podczas audytu.

1. Obraz hero jest ładowany leniwie (opóźniony LCP)

Przed:

<img src="hero.jpg" loading="lazy" alt="Product hero">

Po:

<img src="hero.jpg" fetchpriority="high" alt="Product hero">

Dlaczego: hero jest elementem LCP. Ładowanie go z priorytetem (i priorytetyzacja pobierania) pozwala mu pojawić się szybciej. Leniwe ładowanie działa odwrotnie.

2. Szerokie, domyślne leniwe ładowanie z CMS-a

Przed: każdy <img> w szablonie ma loading="lazy", w tym logo w nagłówku i obraz wyróżniony na górze strony. Po: szablon ładuje obrazy powyżej linii zagięcia z priorytetem i stosuje loading="lazy" tylko do obrazów renderowanych poniżej początkowego viewportu. Dlaczego: masowe leniwe ładowanie obejmuje obrazy widoczne od razu, opóźniając to, co użytkownik (i LCP) widzi jako pierwsze.

3. Ładowanie osadzonych treści poza ekranem podczas ładowania strony

Przed:

<iframe src="https://maps.google.com/…" title="Store map"></iframe>

Po:

<iframe src="https://maps.google.com/…" loading="lazy" title="Store map"></iframe>

Dlaczego: mapa jest poniżej linii zagięcia. Odroczenie jej usuwa koszt startowy i pomaga INP, ponieważ osadzone treści wykonują pracę na głównym wątku podczas ładowania strony.

4. Niestandardowe leniwe ładowanie JS pozostawia src puste dla Googlebota

Przed: biblioteka przechowuje prawdziwy URL w data-src i podmienia go na src podczas zdarzenia przewijania — którego Googlebot nigdy nie wywołuje, więc wyrenderowany HTML pokazuje pusty/placeholderowy src. Po: użyj natywnego loading="lazy" (prawdziwy URL w src od początku) lub biblioteki opartej na IntersectionObserver, a następnie potwierdź w URL Inspection, że URL jest obecny w wyrenderowanym src. Dlaczego: jeśli URL nie jest w src w wyrenderowanym HTML, Google nie może pobrać obrazu.

Znajdź obrazy, które powinny (lub nie powinny) być ładowane leniwie

Fragment kodu do konsoli DevTools, który możesz wkleić na dowolnej stronie, aby sprawdzić atrybut loading. Wyświetla obrazy z ich wartością loading oraz informacją, czy są aktualnie w viewportcie — dzięki temu zauważysz obraz powyżej linii zagięcia oznaczony jako lazy lub taki poniżej, który nie jest.

Chrome DevTools Console

// Audit loading attributes vs. viewport position
[...document.images].forEach(img => {
  const r = img.getBoundingClientRect();
  const inView = r.top < innerHeight && r.bottom > 0;
  const loading = img.getAttribute('loading') || '(none/eager)';
  // Flag the two mistakes: in-view + lazy, or off-view + not lazy
  const flag =
    (inView && loading === 'lazy') ? '⚠ above-the-fold but LAZY' :
    (!inView && loading !== 'lazy') ? '· off-screen, not lazy' : '';
  console.log(loading.padEnd(14), inView ? 'in-view ' : 'off-view', flag, img.currentSrc || img.src);
});

Przeszukaj źródła pod kątem ryzykownych wzorców leniwego ładowania

Sprawdź swoje szablony/wyniki budowania pod kątem przestarzałej wartości auto oraz leniwego ładowania JS w stylu data-src (które może pozostawić src puste dla Googlebota).

macOS / Linux (bash)

# Deprecated loading="auto"
grep -rn 'loading="auto"' ./src

# JS-driven lazy load leaving real URL in data-src (verify these render into src)
grep -rn 'data-src=' ./src

Windows (PowerShell)

# Deprecated loading="auto"
Get-ChildItem -Recurse .\src | Select-String -Pattern 'loading="auto"'

# JS-driven lazy load using data-src
Get-ChildItem -Recurse .\src | Select-String -Pattern 'data-src='

Pamiętaj: data-src nie jest automatycznie problemem — to sygnał, aby potwierdzić, że prawdziwy URL trafia do wyrenderowanego src, co weryfikujesz w URL Inspection w Search Console.

Obraz hero zaczyna się później po włączeniu leniwego ładowania

Objaw: LCP staje się wolniejszy, a żądanie hero zaczyna się późno w waterfallu.

Prawdopodobna przyczyna: Globalna reguła CMS dodała loading="lazy" do obrazu powyżej linii zagięcia lub obrazu LCP.

Poprawka i potwierdzenie: Usuń z tego obrazu atrybut leniwego ładowania, opcjonalnie dodaj fetchpriority="high" i potwierdź, że jego żądanie zaczyna się wcześniej w dopasowanym śladzie.

Obraz z leniwym ładowaniem pojawia się, ale przesuwa stronę

Objaw: Treść przeskakuje, gdy odroczony obraz wchodzi w obszar widoczny.

Prawdopodobna przyczyna: Obraz nie ma jawnych wymiarów ani zarezerwowanego współczynnika proporcji.

Poprawka i potwierdzenie: Dodaj atrybuty width i height lub zarezerwuj ten sam współczynnik proporcji w CSS. Przeładuj stronę z włączonymi regionami przesunięć układu i zweryfikuj, że obraz nie przesuwa już otaczającej treści.

Google nie widzi odroczonej treści

Objaw: Wyrenderowana inspekcja nie zawiera adresu URL obrazu ani treści, która pojawia się po przewinięciu przez człowieka.

Prawdopodobna przyczyna: Procedura obsługi przewijania/kliknięcia nigdy nie uruchamia się dla Googlebota lub biblioteka leniwego ładowania pozostawia prawdziwy adres URL w data-src zamiast w wyrenderowanym src.

Poprawka i potwierdzenie: Użyj natywnego leniwego ładowania lub implementacji opartej na IntersectionObserver, a następnie sprawdź wyrenderowany HTML i potwierdź, że końcowy adres URL i treść są obecne bez interakcji.

Osadzony element poza ekranem nadal ładuje się natychmiast

Objaw: Iframe poniżej linii zagięcia pojawia się w początkowym wodospadzie żądań mimo zmiany leniwego ładowania.

Prawdopodobna przyczyna: Atrybut jest nieobecny we wdrożonym iframe, opakowanie tworzy iframe z wyprzedzeniem lub osadzony element znajduje się wystarczająco blisko obszaru widocznego, aby przekroczyć próg ładowania przeglądarki.

Poprawka i potwierdzenie: Sprawdź aktywny DOM i inicjatora żądania, przetestuj na długiej stronie z zimną pamięcią podręczną i zweryfikuj, że żądanie jest odroczone do momentu osiągnięcia przez przeglądarkę progu bliskości obszaru widocznego.

Narzędzia do wdrożenia i dowodu

• Panele Elements i Network w Chrome DevTools: potwierdź wdrożony atrybut loading, zidentyfikuj, który skrypt utworzył iframe, i porównaj czasy rozpoczęcia żądań przed i po zmianie.
• Panel Performance w Chrome DevTools: zarejestruj ładowanie i zweryfikuj, że odroczenie osadzonego elementu zmniejsza początkową pracę wątku głównego bez opóźniania obrazu LCP.
• PageSpeed Insights: użyj diagnostyki obrazów poza ekranem jako listy początkowej, a następnie oddziel prawdziwych kandydatów poniżej linii zagięcia od obrazu hero lub innej natychmiastowej treści.
• Inspekcja adresów URL w Search Console: sprawdź wyrenderowany HTML i zweryfikuj, że odroczone adresy URL obrazów trafiają do src i że treść ładowana leniwie istnieje bez przewijania lub kliknięcia.
• Obszar widoczny przeglądarki i pasek klatek: przetestuj więcej niż jeden rozmiar obszaru widocznego. Obraz poniżej linii zagięcia na komputerze może znajdować się powyżej linii zagięcia na mniejszym lub inaczej ukształtowanym urządzeniu.

Odraczanie obrazów poniżej linii zagięcia

Test do przeprowadzenia: Zarejestruj ślad sieciowy zimnego ładowania przed i po dodaniu natywnego leniwego ładowania do obrazu znajdującego się znacznie poniżej początkowego obszaru widocznego.

Oczekiwany wynik: Żądanie obrazu jest nieobecne w początkowym krytycznym wodospadzie żądań i zaczyna się, gdy obszar widoczny się do niego zbliża.

Interpretacja niepowodzenia: Wdrożony znacznik nie zawiera atrybutu, JavaScript tworzy lub pobiera obraz z wyprzedzeniem lub obraz testowy znajduje się w zakresie progu bliskości obszaru widocznego przeglądarki.

Okno monitorowania: Sprawdź natychmiast po wdrożeniu na reprezentatywnych rozmiarach obszaru widocznego urządzeń mobilnych i komputerów stacjonarnych.

Wyzwalacz wycofania: Wycofaj zmianę, jeśli obraz widoczny przy początkowym ładowaniu jest odroczony lub jeśli obraz rutynowo nie pojawia się, zanim użytkownik do niego dotrze.

Wykluczenie obrazu LCP

Test do przeprowadzenia: Porównaj dopasowane ślady wydajności i wodospady żądań dla obrazu LCP strony po usunięciu ogólnego leniwego ładowania.

Oczekiwany wynik: Obraz LCP ładuje się z wyprzedzeniem, jego żądanie zaczyna się wcześniej, a LCP nie ulega regresji.

Interpretacja niepowodzenia: Inny szablon lub warstwa optymalizacji ponownie dodaje atrybut lub odkrycie jest nadal opóźnione przez CSS, JavaScript lub znaczniki.

Okno monitorowania: Sprawdź powtórzone testy laboratoryjne natychmiast, a następnie obserwuj LCP w terenie przez kolejne okno raportowania.

Wyzwalacz wycofania: Wycofaj całe wdrożenie, jeśli zmiana opóźnia inne krytyczne zasoby na tyle, aby spowodować powtarzalną regresję LCP.

Widoczność wyrenderowanej treści

Test do wykonania: Użyj URL Inspection, aby wyświetlić wyrenderowany HTML bez interakcji z stroną i wyszukaj odroczony URL obrazu oraz powiązaną treść.

Oczekiwany wynik: Finalny URL pojawia się w src, a ważna treść jest obecna w wyrenderowanym HTML.

Interpretacja błędu: Implementacja zależy od zdarzenia przewinięcia/kliknięcia lub skrypt leniwego ładowania nie zadziałał podczas renderowania.

Okno monitorowania: Przetestuj każdy zmieniony szablon po wydaniu i po zmianie biblioteki leniwego ładowania lub potoku obrazów CMS.

Wyzwalacz wycofania: Wycofaj zmiany, jeśli indeksowalna treść lub URL-e obrazów znikną z wyrenderowanego wyniku.

Sprawdź się: Leniwe ładowanie

Pięć szybkich pytań o odraczanie obrazów i iframe bez szkody dla Core Web Vitals ani indeksowania. Wybierz odpowiedź na każde, a potem sprawdź.

Zasoby warte Twojego czasu

Moje powiązane artykuły

• Problemy i dobre praktyki w SEO dla JavaScriptu — gdzie omawiam przejście od sterowanego JS do natywnego leniwego ładowania w przeglądarce i dlaczego leniwie ładowana treść (nie tylko obrazy) stanowi ryzyko dla indeksowania.
• Google PageSpeed Insights dla specjalistów SEO i programistów — łączy audyt „odrocz obrazy poza ekranem” z leniwym ładowaniem oraz resztą raportu PSI.
• Przewodnik dla początkujących po technicznym SEO — gdzie wydajność i renderowanie wpisują się w szerszy obraz.

Z branży

• Naprawianie leniwie ładowanej treści witryny (Google Search Central) — definitywny dokument o implementacji i testowaniu.
• Leniwe ładowanie obrazów na poziomie przeglądarki (web.dev) — natywny atrybut i zastrzeżenie dotyczące LCP, prosto od zespołu wydajności Google.
• Czas leniwie ładować ramki poza ekranem (web.dev) — przypadek iframe i jego korzyść dla startu/INP.
• Leniwe ładowanie bez tajemnic — odc. 98 (Google) — pełny odcinek Muellera i Splitta o leniwym ładowaniu, renderowaniu, indeksowaniu i Core Web Vitals.
• Leniwe ładowanie wyjaśnione: szybko przyspiesz witrynę i popraw UX (Search Engine Land) — obszerny branżowy przewodnik z uwagami dotyczącymi CMS.
• Leniwe ładowanie (przewodnik po wydajności) (MDN) — widok API z perspektywy dewelopera.
• Wprowadzenie do leniwego ładowania z myślą o skutecznym crawlowaniu i indeksowaniu (Oncrawl) — dogłębne spojrzenie na kąt indeksowania i crawl.

Dziennik zmian