Strona ładuje się ponad 4 sekundy, współczynnik odrzuceń rośnie, a Google coraz niżej pozycjonuje witrynę w wynikach. Brzmi znajomo? W zdecydowanej większości przypadków winowajcą są obrazy — stanowią średnio 40-60% całkowitej wagi strony. Lazy loading, czyli leniwe ładowanie obrazów, rozwiązuje ten problem elegancko: przeglądarka pobiera grafikę dopiero wtedy, gdy użytkownik przewija stronę w jej kierunku. Zamiast ładować 30 zdjęć na raz, witryna serwuje je porcjami. Efekt? Pierwsze wyświetlenie strony następuje szybciej, a serwer zużywa mniej zasobów. Problem pojawia się jednak tam, gdzie SEO spotyka wydajność — źle zaimplementowane leniwe ładowanie może sprawić, że Googlebot w ogóle nie zobaczy grafik i nie zaindeksuje ich w wyszukiwarce grafik. Przyjrzyjmy się, jak wdrożyć lazy loading tak, aby strona działała szybciej bez negatywnego wpływu na widoczność w wynikach wyszukiwania.
Z naszego artykułu dowiesz się:
Jak działa lazy loading i dlaczego przeglądarki obsługują go natywnie
Mechanizm leniwego ładowania obrazów opiera się na prostej logice: element graficzny nie jest pobierany z serwera, dopóki nie znajdzie się w obrębie widocznego obszaru przeglądarki (viewport) lub w jego bezpośrednim sąsiedztwie. Przeglądarka monitoruje pozycję przewijania i dopiero gdy użytkownik zbliża się do danego fragmentu strony, inicjuje żądanie HTTP po odpowiedni plik graficzny.
Natywny atrybut loading="lazy" i jego ograniczenia
Od 2019 roku Chrome, a następnie Firefox, Edge i Safari (od wersji 15.4) wspierają natywny atrybut loading="lazy" dodawany bezpośrednio do tagu <img>. Wystarczy dopisać jeden atrybut, a przeglądarka sama decyduje, kiedy pobrać obraz. Nie potrzeba żadnej biblioteki JavaScript — implementacja sprowadza się do jednej linijki w HTML.
Natywne rozwiązanie ma jednak swoje niuanse. Przeglądarka sama ustala próg odległości od viewportu, przy którym rozpoczyna pobieranie. W Chrome ten próg wynosi około 1250 pikseli na szybkim łączu i nawet 2500 pikseli na wolnym — co oznacza, że obraz może zacząć się ładować znacznie wcześniej, niż użytkownik do niego dotrze. Z perspektywy użytkownika to dobrze (mniej widocznych „pustych miejsc"), ale z perspektywy oszczędności transferu zysk bywa mniejszy niż przy rozwiązaniach opartych na JavaScript, gdzie próg kontrolujemy sami.
Intersection Observer API jako alternatywa z pełną kontrolą
Dla projektów wymagających precyzyjnego sterowania momentem ładowania, Intersection Observer API daje znacznie większe możliwości. Tworzymy obserwator, który monitoruje wybrane elementy i wywołuje callback w momencie, gdy element wchodzi w zdefiniowaną strefę. Typowa implementacja wygląda tak: obraz początkowo ma źródło zapisane w atrybucie data-src, a dopiero po wykryciu przez obserwator wartość ta zostaje przepisana do właściwego atrybutu src. Takie podejście pozwala ustawić dokładny margines (np. 200 pikseli przed viewportem), zastosować animację fade-in przy pojawianiu się grafiki i obsłużyć różne formaty grafik w zależności od urządzenia. Z naszego doświadczenia — Intersection Observer sprawdza się najlepiej na stronach z galeriami produktowymi, gdzie ładujemy 50-100 miniatur jednocześnie i zależy nam na minimalnym zużyciu transferu mobilnego.
Leniwe ładowanie obrazów a indeksacja — co widzi Googlebot
Największa obawa przy wdrażaniu lazy loading dotyczy tego, czy roboty wyszukiwarek w ogóle zobaczą leniwie ładowane grafiki. Googlebot renderuje strony za pomocą silnika Chromium (w wersji evergreen, czyli aktualizowanej), co oznacza, że teoretycznie obsługuje zarówno natywny atrybut loading="lazy", jak i JavaScript z Intersection Observer.
W praktyce sprawa jest bardziej złożona. Googlebot wykonuje renderowanie w dwóch falach — najpierw pobiera HTML i indeksuje treść tekstową, a dopiero w drugiej fali (która może nastąpić po godzinach, a nawet dniach) uruchamia JavaScript i renderuje pełną stronę. Jeśli źródło obrazu jest zapisane wyłącznie w data-src i wymaga JavaScriptu do przepisania na src, obraz pojawi się w indeksie dopiero po drugiej fali renderowania. Natywny loading="lazy" w tagu <img> z prawidłowym atrybutem src nie stwarza tego problemu — Googlebot widzi URL grafiki bezpośrednio w HTML.
Warto znać jeszcze jedną zależność: Googlebot nie symuluje przewijania strony w tradycyjnym sensie, ale renderuje całą stronę do pełnej wysokości. Oznacza to, że natywne leniwe ładowanie obrazów jest przez niego obsługiwane prawidłowo — przeglądarka renderująca „widzi" każdy element, nawet ten głęboko na stronie. Problemy pojawiają się dopiero przy niestandardowych implementacjach, które ładują obrazy wyłącznie po zdarzeniu scroll wywoływanym przez użytkownika.
Poprawna implementacja lazy load — atrybut src, formaty i responsywność
Samo dodanie loading="lazy" to dopiero początek. Aby leniwe ładowanie obrazów działało optymalnie zarówno dla użytkowników, jak i dla wyszukiwarek, trzeba zadbać o kilka elementów jednocześnie.
Zawsze podawaj wymiary obrazu w atrybutach width i height lub przez CSS. Bez nich przeglądarka nie wie, ile miejsca zarezerwować na grafikę, co prowadzi do przeskoków layoutu (CLS — Cumulative Layout Shift). Przy testach jednego portalu informacyjnego samo dodanie wymiarów do 120 obrazów zmniejszyło CLS z 0.32 do 0.04, co przełożyło się na poprawę oceny Core Web Vitals z „Poor" na „Good".
Te elementy współgrają ze sobą. Optymalizacja obrazów bez lazy loading daje ograniczone efekty, a leniwe ładowanie bez optymalizacji formatu i rozmiaru pliku marnuje potencjał. Przy jednym z projektów e-commerce połączenie konwersji do WebP, responsywnych srcsetów i natywnego lazy loading skróciło czas ładowania strony kategorii z 6.2 do 2.1 sekundy na połączeniu 4G.
Typowe błędy przy wdrażaniu lazy loading i ich wpływ na widoczność
Z perspektywy SEO niebezpieczne nie jest samo leniwe ładowanie, lecz jego błędna implementacja. Poniższe scenariusze obserwujemy regularnie przy audytach technicznych.
| Błąd | Skutek SEO | Rozwiązanie | |
| Brak atrybutu src (tylko data-src) | Googlebot może nie zaindeksować obrazu w pierwszej fali | Zawsze podawaj src z docelowym URL, dodaj loading="lazy" | |
| Lazy loading na obrazach above the fold | Pogorszenie LCP, niższa ocena Core Web Vitals | Pierwsze 1-2 obrazy zawsze z loading="eager" | |
| Brak atrybutu alt | Obraz niewidoczny w Google Images, utrata ruchu z grafik | Opisowy alt na każdym obrazie | |
| Brak wymiarów width/height | Przeskoki layoutu, wysoki CLS | Zawsze podawaj wymiary lub aspect-ratio w CSS | |
| JavaScript blokujący rendering | Opóźnione załadowanie wszystkich grafik | Natywny loading="lazy" nie wymaga JS |
Jeden z częstszych problemów dotyczy generatorów stron i builderów wizualnych. Wiele wtyczek do WordPressa czy Shopify automatycznie dodaje lazy loading do wszystkich obrazów, łącznie z logo, grafiką hero i obrazem LCP. W efekcie najważniejszy element wizualny strony ładuje się z opóźnieniem, a metryka Largest Contentful Paint spada poniżej akceptowalnego progu 2.5 sekundy. Rozwiązanie polega na selektywnym wyłączeniu leniwego ładowania dla grafik widocznych w pierwszym ekranie — większość nowoczesnych wtyczek (np. Perfmatters, FlyingPress) pozwala zdefiniować liczbę obrazów wykluczonych z lazy loading.
Testowanie i monitorowanie leniwego ładowania w kontekście SEO
Wdrożenie lazy loading bez weryfikacji to jak optymalizacja na ślepo. Potrzebujemy dwóch perspektyw: jak stronę widzi użytkownik i jak widzi ją Googlebot.
Z perspektywy użytkownika PageSpeed Insights (lub Lighthouse w Chrome DevTools) pokaże wpływ na Core Web Vitals — LCP, CLS i INP. Po wdrożeniu leniwego ładowania sprawdzamy, czy LCP się poprawił (obraz above the fold nie powinien być lazy-loaded) i czy CLS nie wzrósł (brak wymiarów przy loading images). Narzędzie WebPageTest pozwala dodatkowo zobaczyć kaskadę żądań HTTP i zweryfikować, w którym momencie przeglądarka pobiera poszczególne grafiki.
Z perspektywy Googlebot-a korzystamy z narzędzia „Sprawdź URL" w Google Search Console. Po wpisaniu adresu strony i kliknięciu „Testuj opublikowany URL" zobaczymy wyrenderowany zrzut ekranu tak, jak widzi go robot. Jeśli na zrzucie brakuje grafik — implementacja wymaga korekty. Możemy też zweryfikować indeksację obrazów bezpośrednio w Google Images wyszukując site:nasza-domena.pl i sprawdzając, czy nowe grafiki pojawiają się w wynikach. Przy dużych witrynach (powyżej 10 000 podstron) monitorujemy dodatkowo raport pokrycia indeksu i statystyki crawlowania — nagły spadek zaindeksowanych zasobów graficznych po wdrożeniu lazy loading to sygnał ostrzegawczy.
Rekomendujemy cykliczną weryfikację co 2-4 tygodnie, szczególnie po aktualizacjach CMS-a lub wtyczek. Jedna automatyczna aktualizacja potrafi zmienić sposób renderowania obrazów i zniweczyć wcześniejszą optymalizację. Warto też ustawić alert w Google Search Console na spadek liczby zaindeksowanych stron — reagowanie w ciągu kilku dni pozwala uniknąć trwałej utraty widoczności grafik w wynikach wyszukiwania.
