Jak wdrożyć lazy loading obrazów na stronie internetowej
Obraz potrafi ważyć więcej niż cały kod strony. I często właśnie on decyduje, czy użytkownik zobaczy treść od razu, czy przez kilka sekund będzie patrzył na pusty ekran, przesuwający się układ albo niedoładowany baner. Lazy loading obrazów rozwiązuje konkretny problem: nie każe przeglądarce pobierać od razu grafik, których użytkownik jeszcze nie widzi.
Nie jest to jednak przełącznik „przyspiesz stronę”. Źle wdrożony lazy loading potrafi pogorszyć LCP, opóźnić obraz główny, zepsuć układ strony i dać złudne wyniki w testach. Dobrze wdrożony działa ciszej: zmniejsza liczbę żądań na starcie, ogranicza transfer danych i pomaga szybciej pokazać najważniejszą część strony.
Co to jest lazy loading obrazów i kiedy naprawdę przyspiesza stronę
Lazy loading polega na tym, że przeglądarka odkłada pobieranie obrazów znajdujących się poza pierwszym widokiem ekranu. Zamiast ładować wszystkie zdjęcia z długiej podstrony produktowej, galerii, bloga czy strony kategorii, pobiera najpierw to, co jest potrzebne do wyświetlenia widocznej części strony.
Najprostszy zapis wygląda tak:
<img
src="/images/produkt-2.webp"
alt="Czarny plecak turystyczny z boczną kieszenią"
width="800"
height="600"
loading="lazy">
Atrybut loading=”lazy” mówi przeglądarce: „to zdjęcie nie jest pilne, pobierz je dopiero wtedy, gdy użytkownik zbliży się do miejsca, w którym będzie potrzebne”. Współczesne przeglądarki obsługują ten mechanizm natywnie, więc w większości typowych wdrożeń nie trzeba już dokładania biblioteki JavaScript tylko po to, żeby opóźnić ładowanie obrazów.
Największy sens ma to na stronach, które mają:
- długie listy produktów,
- galerie zdjęć,
- wpisy blogowe z wieloma ilustracjami,
- strony kategorii z miniaturami,
- landing page’e z sekcjami daleko poniżej pierwszego ekranu,
- opinie klientów z avatarami,
- logotypy partnerów nisko na stronie.
Nie każdy obraz powinien być leniwie ładowany. To najważniejsza decyzja. Obraz widoczny od razu po wejściu na stronę nie powinien mieć loading=”lazy”. Dotyczy to szczególnie hero image, dużego zdjęcia produktu, grafiki nad nagłówkiem oraz każdego obrazu, który może zostać uznany za element Largest Contentful Paint.
Praktyczna zasada jest prosta:
jeżeli obraz jest widoczny bez przewijania na typowym ekranie telefonu, zostaw go jako ładowany normalnie. Jeżeli pojawia się niżej, dodaj lazy loading.
Trzeba też rozumieć ograniczenie: lazy loading nie zmniejsza wagi samego pliku. Jeżeli zdjęcie ma 3 MB, dalej ma 3 MB. Zostanie tylko pobrane później. Dlatego opóźnione ładowanie obrazów nie zastępuje kompresji, formatu WebP/AVIF, poprawnych wymiarów i sensownego kadrowania. To raczej ostatni etap porządkowania obrazów, nie pierwszy.
Priorytet działań powinien wyglądać tak:
- Najpierw zmniejsz rozmiar plików i podawaj obrazy w odpowiednich wymiarach.
- Potem ustaw width i height, żeby uniknąć przeskakiwania układu.
- Następnie oznacz obrazy poza pierwszym ekranem przez loading=”lazy”.
- Dopiero później rozważ bardziej zaawansowane rozwiązania, np. Intersection Observer.
W praktyce największy zysk widać tam, gdzie strona na starcie próbuje pobrać kilkanaście albo kilkadziesiąt grafik. Na krótkiej stronie z jednym zdjęciem lazy loading nie zrobi cudów. Na kategorii e-commerce z 48 miniaturami produktów może już realnie ograniczyć transfer i liczbę żądań podczas pierwszego renderowania.
Jak wdrożyć lazy loading krok po kroku bez psucia LCP
Najbezpieczniej zacząć od audytu, a nie od masowej podmiany kodu. Automatyczne dodanie loading=”lazy” do wszystkich obrazów brzmi kusząco, ale bywa błędem. Szczególnie w systemach CMS, gdzie ten sam szablon obsługuje stronę główną, wpis blogowy i kartę produktu.
Pierwszy krok: znajdź obrazy nad linią załamania strony. Sprawdź osobno mobile i desktop. To ważne, bo grafika, która na dużym monitorze jest widoczna od razu, na telefonie może spaść niżej — albo odwrotnie, przez inny układ sekcji.
Obrazy w pierwszym widoku traktuj tak:
<img
src="/images/glowne-zdjecie-produktu.webp"
alt="Skórzany portfel męski w kolorze brązowym"
width="1200"
height="900"
fetchpriority="high">
Tu nie dodajemy loading=”lazy”. Jeżeli obraz jest głównym kandydatem do LCP, można rozważyć fetchpriority=”high”, żeby dać przeglądarce sygnał, że ten zasób jest ważny. Nie należy jednak rozdawać wysokiego priorytetu wszystkim obrazom. Jeżeli wszystko jest pilne, przeglądarka traci możliwość ustalenia kolejności.
Drugi krok: dodaj lazy loading do obrazów poniżej pierwszego ekranu.
<img
src="/images/opinia-klienta.webp"
alt="Zdjęcie klienta dodającego opinię o produkcie"
width="400"
height="400"
loading="lazy">
Trzeci krok: ustaw wymiary. To nie jest kosmetyka. Brak width i height może powodować przesunięcia layoutu, gdy obraz doładuje się później. Użytkownik chce kliknąć przycisk, a w tym momencie wskakuje zdjęcie i cała sekcja przesuwa się w dół. Dla UX to irytujące, dla CLS — potencjalny problem.
Czwarty krok: używaj lazy loading także z obrazami responsywnymi, ale bez kombinowania z data-src, jeśli nie jest to potrzebne.
<picture>
<source
srcset="/images/galeria-800.avif"
type="image/avif">
<source
srcset="/images/galeria-800.webp"
type="image/webp">
<img
src="/images/galeria-800.jpg"
alt="Widok salonu po remoncie"
width="800"
height="533"
loading="lazy">
</picture>
W przypadku elementu picture atrybut loading trafia na img, nie na source. To częsty błąd w ręcznych wdrożeniach.
Piąty krok: sprawdź efekt w narzędziach, a nie „na oko”. Minimum to:
- Chrome DevTools → Network: czy obrazy poniżej ekranu nie pobierają się od razu,
- Lighthouse: czy nie pojawiły się ostrzeżenia dotyczące LCP,
- PageSpeed Insights: czy dane laboratoryjne nie wskazują opóźnienia głównego obrazu,
- Google Search Console → Core Web Vitals: czy po czasie poprawiają się dane z realnych wizyt.
Trzeba uważać na jedną rzecz: test laboratoryjny pokazuje symulację, a użytkownicy mają różne urządzenia, sieci i rozmiary ekranów. Dlatego pojedynczy zielony wynik w Lighthouse nie oznacza jeszcze, że problem został rozwiązany dla ruchu mobilnego.
W CMS-ach warto sprawdzić, czy motyw lub wtyczka nie dodaje lazy loading automatycznie. WordPress od kilku wersji robi to natywnie dla wielu obrazów, ale motyw, builder albo plugin optymalizacyjny może zmienić zachowanie. Jeżeli kilka narzędzi próbuje sterować obrazami jednocześnie, pojawiają się dziwne efekty: puste placeholdery, podwójne atrybuty, błędne srcsety albo opóźniony obraz główny.
Dobra procedura wdrożeniowa wygląda tak:
- Zrób kopię strony lub pracuj na środowisku testowym.
- Wybierz 3–5 typów podstron: strona główna, wpis blogowy, kategoria, produkt, landing page.
- Oznacz lazy loadingiem tylko obrazy poniżej pierwszego widoku.
- Sprawdź mobile osobno, nie tylko desktop.
- Porównaj liczbę żądań i transfer danych przed oraz po zmianie.
- Dopiero wtedy wdrażaj regułę globalnie.
Nie warto zaczynać od agresywnych skryptów, które podmieniają src na data-src dla wszystkich grafik. Kiedyś był to standard, dziś w wielu przypadkach to zbędny ciężar. Natywne loading=”lazy” jest prostsze, mniej awaryjne i działa nawet wtedy, gdy nie chcesz utrzymywać dodatkowego kodu JavaScript.
Co robić, a czego nie robić przy opóźnionym ładowaniu grafik
Najważniejsza zasada: nie opóźniaj obrazu, który buduje pierwszy widok strony. To błąd, który widzę najczęściej przy automatycznych optymalizacjach. Plugin obiecuje poprawę szybkości, dodaje lazy loading wszędzie, a potem LCP rośnie, bo główne zdjęcie produktu zostało potraktowane jak grafika z dołu strony.
Co robić:
- dodawaj loading=”lazy” do obrazów poniżej pierwszego ekranu,
- zostawiaj obrazy kluczowe dla LCP bez lazy loadingu,
- ustawiaj width i height dla każdego obrazu,
- stosuj srcset i sizes, jeśli obraz ma różne warianty dla mobile i desktop,
- kompresuj pliki przed wdrożeniem lazy loadingu,
- używaj WebP lub AVIF tam, gdzie obsługuje to stack strony,
- testuj osobno szablony, nie tylko jedną podstronę.
Czego nie robić:
- nie dodawaj lazy loadingu do logo, hero image i pierwszego zdjęcia produktu,
- nie ustawiaj fetchpriority=”high” na wielu obrazach naraz,
- nie używaj jednocześnie kilku pluginów do lazy loadingu,
- nie ukrywaj ciężkich obrazów CSS-em, licząc, że „jakoś się nie pobiorą”,
- nie zakładaj, że poprawa wyniku Lighthouse oznacza poprawę dla wszystkich użytkowników,
- nie zostawiaj obrazów bez wymiarów, bo layout może skakać.
Osobna sprawa to tła CSS. Atrybut loading=”lazy” działa na elementach HTML, takich jak img czy iframe, ale nie rozwiązuje automatycznie problemu grafik ustawionych jako background-image. Jeżeli główna grafika strony jest tłem w CSS, przeglądarka może wykrywać ją później niż zwykły obraz w HTML. Przy sekcjach hero często lepiej użyć normalnego img albo picture i ostylować go tak, aby zachowywał się jak tło.
Przykład lepszego podejścia dla ważnego obrazu:
<picture class="hero__media">
<source srcset="/images/hero-mobile.webp" media="(max-width: 767px)">
<source srcset="/images/hero-desktop.webp" media="(min-width: 768px)">
<img
src="/images/hero-desktop.webp"
alt="Nowoczesna kuchnia z drewnianym blatem"
width="1600"
height="900"
fetchpriority="high">
</picture>
Jeżeli obraz jest dekoracyjny, można zostawić pusty alt:
<img
src="/images/dekoracja.webp"
alt=""
width="600"
height="400"
loading="lazy">
Ale jeśli zdjęcie niesie informację — pokazuje produkt, efekt usługi, wykres, instrukcję albo porównanie — opis alternatywny powinien być konkretny. Lazy loading nie może psuć dostępności.
Granica opłacalności? Na małej stronie firmowej z pięcioma lekkimi grafikami większy efekt da kompresja i poprawny rozmiar obrazów. Na sklepie, blogu, portalu albo stronie z portfolio lazy loading zwykle ma sens, ale tylko po selekcji. Najpierw obrazy poniżej ekranu. Potem galerie. Na końcu elementy pomocnicze, takie jak avatary, logotypy i miniatury wpisów.
Po wdrożeniu warto przyjąć prostą regułę kontroli: każda nowa sekcja dodawana do strony powinna mieć sprawdzone obrazy pod kątem trzech pytań:
- Czy obraz jest widoczny w pierwszym widoku?
- Czy ma ustawione width i height?
- Czy jego rozmiar pliku pasuje do miejsca, w którym jest wyświetlany?
Jeżeli odpowiedź na pierwsze pytanie brzmi „tak”, nie dodawaj lazy loadingu automatycznie. Jeżeli „nie”, dodanie loading=”lazy” jest zwykle bezpieczną decyzją.
FAQ: najczęstsze pytania o lazy loading obrazów
Czy lazy loading zawsze przyspiesza stronę?
Nie. Przyspiesza głównie start ładowania strony wtedy, gdy poniżej pierwszego ekranu znajduje się dużo obrazów. Nie zmniejsza sam z siebie wagi plików.
Czy można dodać loading=”lazy” do wszystkich obrazów?
Nie powinno się. Obrazy widoczne od razu po wejściu na stronę, zwłaszcza główny obraz LCP, powinny ładować się normalnie.
Czy lazy loading działa bez JavaScriptu?
Natywny lazy loading jest funkcją przeglądarki, ale w praktyce odraczanie ładowania bywa zależne od działania JavaScriptu w przeglądarce. Nie należy traktować tego jako mechanizmu bezpieczeństwa ani blokady pobierania zasobów.
Czy lazy loading zastępuje kompresję obrazów?
Nie. Najpierw trzeba zmniejszyć pliki, dobrać format i wymiary, a dopiero potem opóźniać ładowanie obrazów, które nie są potrzebne na starcie.
Czy warto używać biblioteki JavaScript do lazy loadingu?
Tylko wtedy, gdy potrzebujesz większej kontroli, np. animowanych placeholderów, niestandardowych progów ładowania albo obsługi bardzo specyficznych komponentów. Dla zwykłych obrazów HTML najczęściej wystarcza loading=”lazy”.
Jak sprawdzić, czy lazy loading działa?
Najprościej w Chrome DevTools, w zakładce Network. Po odświeżeniu strony obrazy poniżej pierwszego ekranu nie powinny pobierać się wszystkie od razu.
Czy lazy loading ma wpływ na SEO?
Może mieć pośredni wpływ przez szybkość ładowania i Core Web Vitals. Trzeba jednak dopilnować, aby obrazy miały normalne adresy src, poprawne alty i były dostępne dla przeglądarki oraz robotów.
Od czego zacząć wdrożenie?
Od usunięcia największego błędu: sprawdź, czy główny obraz strony nie ma loading=”lazy”. Potem oznacz tym atrybutem grafiki poniżej pierwszego ekranu i porównaj wyniki w Network oraz PageSpeed Insights.
Więcej informacji na stronie: https://szymonsarnecki.pl
Dodaj komentarz