Lazy loading w PrestaShop: szybszy sklep i lepszy LCP bez pułapek

Lazy loading w PrestaShop to wczytywanie obrazków dopiero wtedy, gdy klient przewinie stronę w ich pobliże. Dobrze wdrożony zmniejsza ilość danych pobieranych przy otwarciu strony nawet o połowę, nie pogarszając czasu wyświetlenia głównego obrazka. Źle wdrożony robi odwrotnie: opóźnia zdjęcie produktu na górze strony i obniża wynik Largest Contentful Paint (LCP). Poniżej znajdziesz dane, które pokazują, ile można zyskać, gdzie najczęściej popełnia się błędy i dlaczego w PrestaShop trudno objąć lazy loadingiem wszystkie obrazki.

Czym jest lazy loading?

Lazy loading (leniwe, opóźnione ładowanie) to technika, w której przeglądarka nie pobiera od razu obrazków leżących poniżej widocznej części strony. Pobiera je dopiero wtedy, gdy klient przewija stronę i obrazek zbliża się do ekranu. Są dwa sposoby, żeby to osiągnąć:

• Natywny atrybut loading="lazy" — jedno słowo w znaczniku <img> lub <iframe>. O tym, kiedy wczytać obrazek, decyduje przeglądarka. Obsługują go Chrome od wersji 77, Edge od 79, Firefox od 75 i Safari od 15.4 (ramki iframe: Firefox od 121, Safari od 16.4). Przeglądarki, które go nie znają, po prostu go ignorują.
• Skrypt JavaScript — w src stoi lekki placeholder, a prawdziwy adres czeka w atrybucie data-src. Skrypt z IntersectionObserver podmienia adres, gdy obrazek zbliża się do ekranu. Daje więcej kontroli (odległość wczytywania, płynne pojawianie się), ale wymaga JavaScriptu i staranności.

Chrome wczytuje obrazki z loading="lazy" z wyprzedzeniem: około 1250 px przed ekranem przy szybkim połączeniu i 2500 px przy wolnym. Według pomiarów zespołu Chrome na Androidzie przy łączu 4G 97,5% takich obrazków jest gotowych w ciągu 10 ms od pojawienia się na ekranie, więc klient nie widzi pustych miejsc.

Dlaczego lazy loading jest ważny dla sklepu?

Obrazki to największa część typowej strony internetowej. Według HTTP Archive (Web Almanac 2025) mediana strony głównej waży 2,56 MB na telefonie, z czego 911 KB to obrazki, pobierane w 15 żądaniach. W sklepie internetowym obrazków jest zwykle więcej: lista kategorii z 24 miniaturami, slider, banery, logotypy płatności, zdjęcia w opisie produktu i polecane produkty pod nim.

Klient, który otwiera kategorię na telefonie, widzi najwyżej kilka pierwszych produktów. Bez lazy loadingu jego przeglądarka pobiera wszystkie miniatury od razu: zużywa transfer, walczy o łącze z obrazkiem, który rzeczywiście widać, i dłużej pracuje na słabszym procesorze. W teście zespołu Chrome na stronie WordPressa lazy loading obrazków poniżej ekranu zmniejszył ilość pobranych danych obrazków o 51–70% przy pierwszym wczytaniu, a po poprawnym ustawieniu pierwszych obrazków LCP był taki sam lub lepszy niż bez lazy loadingu.

Szybkość przekłada się na sprzedaż. W badaniu Deloitte „Milliseconds Make Millions” (2020, zlecone przez Google, 37 marek, 30 mln sesji) skrócenie czasu ładowania na telefonie o 0,1 s wiązało się z 8,4% wyższą konwersją w handlu detalicznym i 9,2% wyższą wartością zamówienia. Vodafone w teście A/B poprawił LCP o 31% i uzyskał 8% więcej sprzedaży. Lazy loading nie jest jedynym czynnikiem — liczą się też serwer (o tym piszemy w porównaniu własny serwer czy hosting dla PrestaShop), cache i rozmiar zdjęć — ale to jeden z najtańszych kroków.

Jak lazy loading wpływa na LCP i Core Web Vitals

Google mierzy szybkość strony trzema wskaźnikami Core Web Vitals. Dla obrazków najważniejszy jest LCP (Largest Contentful Paint) — czas wyświetlenia największego elementu na ekranie; dobry wynik to najwyżej 2,5 s dla 75% wizyt. Google pisze wprost, że zaleca osiągnięcie dobrych Core Web Vitals, bo są zgodne z tym, co nagradzają jego systemy rankingowe. Drugi wskaźnik, CLS (przesunięcia układu, dobry wynik poniżej 0,1), też zależy od obrazków.

Najważniejszy wniosek: obrazka widocznego od razu nie wolno opóźniać. Na co szóstej stronie w sieci główny obrazek ma lazy loading — przeglądarka czeka z nim do zbudowania układu strony, więc LCP rośnie. W danych Chrome strony z natywnym lazy loadingiem miały medianę LCP 3546 ms wobec 2922 ms bez niego (to korelacja, nie dowód). Zespół Chrome sprawdził to w teście na WordPressie, który od wersji 5.5 dodaje loading="lazy" także do obrazków widocznych od razu: po zmianie, w której pierwsze obrazki ładują się normalnie, LCP strony archiwum na telefonie spadł o 18%, a oszczędność danych została.

Dla pierwszego dużego obrazka warto pójść krok dalej i dodać fetchpriority="high" — przeglądarka pobierze go przed innymi plikami. W kwietniu 2025 Google usunął z Lighthouse audyt „Defer offscreen images”, bo przeglądarki same obniżają priorytet obrazków poza ekranem. To ważne: lazy loading nie służy do podbijania wyniku w PageSpeed, tylko do oszczędzania danych i łącza klientów, a o wyniku LCP decyduje to, czy pierwsze obrazki ładują się od razu.

Lazy loading w PrestaShop: co robi motyw, a czego nie

Przeanalizowaliśmy domyślne motywy PrestaShop 1.7.8, 8.2 i 9.2 oraz 105 motywów sklepów, z którymi pracowaliśmy (listopad 2026). Wyniki:

• Classic i Hummingbird mają loading="lazy" na około 90% swoich obrazków — także na głównym zdjęciu produktu (product-cover-thumbnails.tpl), które jest elementem LCP strony produktu. Czyli domyślny motyw opóźnia akurat ten obrazek, którego opóźniać nie powinien.
• Moduły prawie nie korzystają z lazy loadingu: w szablonach modułów PrestaShop 1.7.8 nie ma go na żadnym z 214 obrazków, w 9.2 — na 3 z 225. Slider, banery, bloki z ikonami ładują się od razu.
• Treści z edytora — zdjęcia w opisach produktów i na stronach CMS — nigdy nie mają lazy loadingu, bo nie pochodzą z szablonów.
• W motywach sklepów tylko 29% obrazków ma atrybut loading, 9% opóźnia własny skrypt motywu, a 62% nie ma podanej szerokości, co przy skryptach z placeholderem grozi przesunięciami układu.

Dlaczego trudno wdrożyć lazy loading kompletnie

Dodanie loading="lazy" do jednego szablonu to minuta pracy. Objęcie nim całego sklepu, bez psucia czegokolwiek, to zupełnie inne zadanie:

1. Dziesiątki szablonów. Motyw ma kilkadziesiąt szablonów z obrazkami, a każdy moduł — swoje. Ręczne zmiany w plikach modułów znikają przy ich aktualizacji, a nadpisania w motywie trzeba utrzymywać przy każdej nowej wersji.
2. Treści z edytora. Opisów produktów i stron CMS nie poprawisz w szablonie — trzeba by edytować każdy wpis w bazie, a edytor i tak nie dodaje atrybutu do nowych obrazków.
3. Treści doczytywane przez AJAX. Lista produktów po filtrowaniu lub sortowaniu, szybki podgląd i okno koszyka powstają bez przeładowania strony. Skrypt lazy loadingu musi zauważyć nowe obrazki.
4. Pierwsze obrazki strony. Które obrazki są widoczne bez przewijania, zależy od strony: na głównej to logo i slider, na karcie produktu — zdjęcie produktu. Reguła „wszystko lazy” psuje LCP, reguła „nic” nie oszczędza danych.
5. Skrypty motywu i modułów. Galerie, zoomy i slidery same podmieniają adresy obrazków, a niektóre moduły zamieniają ikony SVG na kod, czytając adres z src. Placeholder w złym miejscu kończy się pustym zdjęciem albo znikającą ikoną.
6. SEO i brak JavaScriptu. Google zaleca, żeby obrazki ładowały się, gdy pojawiają się w oknie, a nie po kliknięciu czy przewinięciu, i żeby po wyrenderowaniu ich adres był w src. Skrypt, który tego nie zapewnia, może ukryć zdjęcia przed wyszukiwarką.
7. Tła CSS nie obsługują atrybutu loading — banery z tłem w atrybucie style wymagają skryptu.

Wskazówka: sprawdź swój sklep w kilka sekund. Otwórz kartę produktu, kliknij prawym przyciskiem główne zdjęcie i wybierz „Zbadaj”. Jeśli ma loading="lazy", motyw opóźnia element LCP. Potem przewiń do opisu produktu: obrazki w opisie bez loading ładują się od razu, nawet gdy klient do nich nie dojdzie.

Automatyczny lazy loading w PrestaShop

Właśnie z tych powodów przygotowaliśmy moduł Automatyczny lazy loading. Nie edytuje żadnego pliku motywu ani modułów — dodaje lazy loading do HTML-u, który wypisują szablony sklepu, więc obejmuje motyw, moduły, opisy produktów, strony CMS i treści doczytywane przez AJAX. Pierwsze obrazki każdej strony (domyślnie cztery) ładuje od razu, także gdy opóźnił je motyw, a pierwszy duży dostaje fetchpriority="high".

Do wyboru są dwie techniki: natywna (loading="lazy", bez JavaScriptu, bezpieczna dla wyszukiwarek) i skrypt z placeholderem zachowującym proporcje obrazka, z regulowaną odległością wczytywania, płynnym pojawianiem się i obsługą teł CSS. Moduł zostawia w spokoju obrazki, którymi zajmuje się już skrypt motywu, a e-maili, faktur PDF i panelu administracyjnego nie dotyka wcale. Wybrane szablony możesz wykluczyć, a pojedynczy obrazek wyłączyć klasą no-lazy. Tabela „Szablony z obrazkami” pokazuje, co moduł zrobił w każdym szablonie i dlaczego pominął resztę. Działa w PrestaShop 1.7.8, 8 i 9, także w multistore.

Jeśli Twój motyw ma nietypowe galerie albo potrzebujesz pomocy z całą optymalizacją szybkości, możesz też zamówić prace programistyczne PrestaShop.

Jak sprawdzić efekt?

• PageSpeed Insights — sekcja z danymi od prawdziwych użytkowników (Chrome UX Report) pokazuje LCP i CLS z ostatnich 28 dni. W diagnostyce zwróć uwagę na wykrywanie żądania LCP: tam Lighthouse zgłasza opóźniony obrazek LCP i brak wysokiego priorytetu.
• Google Search Console — raport „Podstawowe wskaźniki internetowe” grupuje adresy z wolnym LCP. Zmiany widać w nim po kilku tygodniach.
• Narzędzia przeglądarki — karta „Sieć” z filtrem obrazków: przy otwarciu strony powinno się pojawić kilka plików, a kolejne w miarę przewijania.

Lazy loading to jeden z 15 kroków, które opisujemy w poradniku jak przyspieszyć PrestaShop — tam znajdziesz też cache, PHP, WebP i porządki w modułach.

Źródła

• HTTP Archive, Web Almanac 2025: Performance — obrazki jako LCP, lazy loading i fetchpriority obrazka LCP, odsetek stron z dobrym LCP.
• HTTP Archive, Web Almanac 2025: Page Weight — waga stron i obrazków.
• web.dev, The performance effects of too much lazy loading (F. Arntz, R. Viscomi) — LCP i dane w teście WordPressa.
• web.dev, Browser-level image lazy loading — obsługa w przeglądarkach, progi odległości, tła CSS.
• Google Search Central: Fix lazy-loaded website content — lazy loading a indeksowanie.
• Google Search Central: Core Web Vitals — progi i znaczenie dla wyszukiwarki.
• Chrome for Developers: Lighthouse is moving to performance insight audits (28.04.2025) — usunięcie audytu obrazków poza ekranem.
• Deloitte, Milliseconds Make Millions (2020) — szybkość a konwersja.
• web.dev, Vodafone: a 31% improvement in LCP increased sales by 8% (2021).

Najczęściej zadawane pytania

Chcesz objąć lazy loadingiem cały sklep bez edycji motywu? Zobacz moduł Automatyczny lazy loading albo napisz do nas, jeśli masz pytanie o swój sklep.

Produkty z tego wpisu

Automatyczny lazy loading

39,00 € 19,50 €

• -50%
• Nowy

Ocena na 5 gwiazdek na podstawie () opinii

Dodaj do koszyka

Wróć do: Blog