Lazy load images w PrestaShop: kiedy użyć modułu i jak go sprawdzić

Lazy loading odracza pobranie obrazu do chwili, gdy użytkownik zbliży się do jego miejsca na stronie. W natywnym wariancie przeglądarka interpretuje atrybut `loading="lazy"` w znaczniku ``. Moduł może zamiast tego używać JavaScriptu, klas CSS lub atrybutów danych, a implementacja zależy od jego kodu i motywu sklepu.

Odraczanie ma największy sens dla zdjęć poza początkowym widokiem, na przykład dalszych produktów na długiej kategorii albo kolejnych zdjęć galerii. Dzięki temu przeglądarka może najpierw pobrać zasoby potrzebne do wyświetlenia treści widocznej po otwarciu strony. Nie oznacza to kompresji zdjęć ani zmniejszenia ich wymiarów.

W HTML prostą implementację natywną rozpoznasz po atrybucie `loading="lazy"`. Mechanizm modułowy może pokazywać `data-src` zamiast właściwego `src`, a skrypt po przewinięciu przepisuje adres obrazu. Jeżeli JavaScript nie zadziała, taki obraz może pozostać pusty; dlatego sprawdzamy wynik na froncie, a nie tylko stan przełącznika w module.

Nie zakładamy, że każda wersja PrestaShop, motyw i moduł stosują tę samą metodę. Ustawienia wydajności i cache znajdują się w panelu administracyjnym w obszarze Zaawansowane parametry > Wydajność, ale samo zachowanie obrazów może wynikać z szablonu lub dodatku. Przewodnik jak włączyć lazy loading na stronie wyjaśnia ogólny mechanizm poza konfiguracją sklepu.

Przed instalacją dodatku sprawdzamy wygenerowany kod strony, żeby nie uruchomić dwóch mechanizmów dla tych samych obrazów. Otwórz stronę sklepu w Chrome, kliknij prawym przyciskiem myszy i wybierz "Wyświetl źródło strony". Wyszukaj `loading="lazy"`, `data-src`, `data-srcset` oraz nazwy klas zawierające `lazy`.

Samo `loading="lazy"` potwierdza natywną wskazówkę dla przeglądarki, ale nie mówi, czy atrybut trafił na właściwe zdjęcia. W DevTools wybierz element obrazu w panelu Elements i sprawdź jego atrybuty oraz rzeczywisty adres w `src` lub `currentSrc`. Następnie w panelu Network, z filtrem Img, odśwież stronę i zobacz, które pliki pobierają się bez przewijania, a które dopiero później.

Sprawdź też panel Moduły > Menedżer modułów i ustawienia motywu, zwłaszcza gdy sklep ma dodatek optymalizujący obrazy lub wydajność. Lista aktywnych modułów pomaga zawęzić przyczynę, ale rozstrzygający jest kod renderowany na froncie. Dokumentacja instalowania modułów PrestaShop opisuje zarządzanie dodatkami w panelu.

Moduł wybieramy na podstawie zgodności technicznej i możliwości kontroli wyjątków, a nie samej nazwy funkcji. Najpierw ustalamy dokładną wersję PrestaShop, nazwę i wersję motywu oraz to, czy sklep korzysta już z dodatku optymalizującego obrazy, cache albo karuzele.

Przed zakupem czytamy changelog, wymagania oraz informacje o wyłączeniach. Jeżeli opis obiecuje poprawę szybkości bez wskazania zakresu działania, sprawdzamy, czy moduł nie dubluje funkcji już obecnych w motywie. Aktualną cenę sprawdzamy na stronie autora modułu lub w oficjalnym Marketplace PrestaShop, ponieważ zależy od producenta i warunków licencji.

Zmianę wykonujemy najpierw na kopii sklepu albo w środowisku testowym, zwłaszcza gdy moduł modyfikuje szablony lub skrypty. Przed instalacją zapisujemy wersję PrestaShop, motywu, aktywnych dodatków i ustawień cache. Kopia powinna obejmować pliki oraz bazę danych, a nie samą konfigurację modułu.

Po instalacji zaczynamy od ustawień domyślnych i nie włączamy jednocześnie kilku mechanizmów lazy load. Jeśli moduł obsługuje selektory, wskazujemy najpierw obrazy list produktów i treści poza pierwszym ekranem. Wykluczamy logo, baner i zdjęcie produktu, jeśli są widoczne bez przewijania albo wskazane jako LCP.

Po każdej zmianie czyścimy cache PrestaShop i cache przeglądarki. W panelu ustawienia cache znajdziesz w Zaawansowane parametry > Wydajność; nazwy i rozmieszczenie opcji mogą różnić się między wersjami. Oficjalna pomoc PrestaShop opisuje cache Smarty oraz opcje optymalizacji CSS i JavaScript w tym obszarze. Zmiany oceniamy po wyczyszczeniu cache, a nie na podstawie nieaktualnego HTML.

Testujemy trzy szablony: stronę główną, kategorię z listą produktów i kartę produktu z galerią. Na każdej stronie sprawdzamy obraz widoczny po wejściu, zdjęcia ładowane przy przewijaniu, zmianę wariantu oraz zachowanie przy filtrowaniu i sortowaniu. Dopiero po takim samym teście na telefonie wdrażamy ustawienie na produkcji.

Nie ustawiamy lazy load na obraz, który ma być widoczny od razu i może stanowić element LCP. Najczęściej dotyczy to zdjęcia produktu na górze karty, banera głównego albo innego dużego elementu pierwszego widoku. Opóźniony request może zwiększyć czas wyświetlenia tej treści.

Sprawdź LCP w PageSpeed Insights lub panelu Performance w Chrome DevTools, a następnie ustal, który element został zmierzony. Gdy LCP jest zdjęciem, upewnij się, że jego adres znajduje się w HTML od początku i nie czeka na uruchomienie skryptu lazy load. W razie potrzeby wyklucz obraz z selektora modułu lub ustaw mu `loading="eager"`, jeśli implementacja tego wymaga. Atrybut `width` i `height` pomaga przeglądarce zarezerwować miejsce na obraz i ograniczyć przesunięcia układu.

Perspektywa KC Mobile. W sklepach z rozbudowaną kartą produktu problemem bywa to, że moduł traktuje każde zdjęcie tak samo. Dlatego weryfikujemy osobno zdjęcie główne, miniatury galerii i obrazy wyświetlane dopiero po przewinięciu. Wyłączenie właściwego obrazu z lazy load może poprawić pierwszy widok bardziej niż dodanie kolejnego modułu optymalizującego.

Porównujemy tę samą stronę przed zmianą i po niej, przy takim samym urządzeniu, profilu sieci i stanie cache. Zapisujemy adres testowany, wersję modułu, ustawienie selektorów i to, czy cache był czyszczony. Wynik jednego pomiaru traktujemy jako wskazówkę, a nie dowód działania na wszystkich szablonach.

W PageSpeed Insights sprawdzamy LCP i diagnostykę obrazów, a lokalnie w Chrome uruchamiamy DevTools > Network i filtrujemy żądania typu Img. Panel Elements pokazuje, czy dany `` ma `loading="lazy"`, `data-src` lub klasy dodawane przez moduł. W konsoli sprawdzamy błędy JavaScriptu, szczególnie po wejściu na kartę produktu i zmianie wariantu.

Wynik porównujemy dla strony głównej, kategorii i produktu, w wersji mobilnej i desktopowej. Notujemy LCP, liczbę pobieranych obrazów przy pierwszym widoku, rozmiar transferu, przesunięcia układu oraz poprawność galerii. Jeśli moduł zmniejsza liczbę żądań, ale opóźnia LCP lub pozostawia puste zdjęcia, konfiguracja nie spełnia celu.

Przy analizie LCP liczy się nie tylko rozmiar pliku. Obraz może być późno odkrywany, ponieważ wstawia go JavaScript albo blokują go inne zasoby. W poradniku lazy loading w WordPressie opisujemy podobne testy, a optymalizacja szybkości WordPressa pokazuje, dlaczego lazy load jest jedną z kilku odrębnych prac wydajnościowych.

Jeśli chcesz ocenić wpływ szybkości na wyniki sklepu przed wdrożeniem zmian, kalkulator szybkości strony może pomóc oszacować wagę problemu. Sam wynik kalkulatora nie zastępuje testów technicznych konkretnego sklepu.

Jeśli po zmianie zdjęcia nie pojawiają się, nie wyłączamy od razu wszystkich dodatków na działającym sklepie. Najpierw porównujemy stronę z kopią sprzed zmiany, sprawdzamy konsolę i żądania obrazów, a potem izolujemy konflikt. Puste miniatury mogą oznaczać, że motyw oczekuje `src`, a moduł przeniósł adres do `data-src` bez poprawnego uruchomienia skryptu.

Test wykonujemy w tej kolejności: wyłącz selektor dla galerii, sprawdź zmianę wariantu, wyczyść cache i ponów test; następnie sprawdź karuzelę, filtrowanie oraz sortowanie kategorii. Jeśli strona odzyskuje działanie po wyłączeniu modułu, potwierdź konflikt na środowisku testowym i sprawdź, czy istnieje ustawienie zgodności dla motywu.

Jeśli awaria dotyczy zamówień, przywracamy działające ustawienie i sprawdzamy ścieżkę zakupową przed kolejnym wdrożeniem. Nie publikujemy modułu tylko dlatego, że poprawia pojedynczy pomiar Lighthouse.

Moduł rozwiązuje wyłącznie problem momentu pobierania. Nie zmniejszy automatycznie zbyt dużego pliku, nie dobierze właściwego wariantu do telefonu i nie naprawi zdjęcia zapisanego w złym formacie, chyba że ma osobne, potwierdzone funkcje optymalizacji.

Pracę nad obrazami porządkujemy tak: najpierw dobieramy rozmiar pliku do wymiarów wyświetlania, potem kompresujemy zdjęcia i rozważamy WebP lub AVIF, a następnie sprawdzamy warianty responsywne, cache i CDN. Na końcu konfigurujemy opóźnianie elementów poza ekranem, pilnując wyjątku dla LCP. Przewodnik lazy loading w WordPressie pokazuje podobne kompromisy w innym systemie.

Przy dużym katalogu oceniamy też, czy sklep nie generuje nadmiarowych wersji tych samych zdjęć i czy szablon wyświetla je w odpowiednich wymiarach. Obraz o szerokości kilku tysięcy pikseli użyty jako mała miniatura nadal pobiera niepotrzebnie duży plik, nawet gdy ładuje się dopiero po przewinięciu. Po zmianach robimy osobny test jakości fotografii i działania galerii.

Moduł ma sens wtedy, gdy test potwierdza problem z nadmiarem żądań obrazów w pierwszym widoku i możemy bezpiecznie wykluczyć elementy krytyczne. Gdy główny problem leży w rozmiarze zdjęć, skryptach, serwerze albo motywie, samo lazy load nie rozwiąże przyczyny. Dla sklepów na WordPressie opisaliśmy kolejność działań w poradniku błędy optymalizacji WordPressa, a osobno omawiamy, czy wdrażać AMP.

• EWWW Image Optimizer w WordPressie: jak skonfigurować i sprawdzić optymalizację obrazów
• Optymalizacja stron z dynamicznymi tabelami danych pod szybkość i SEO
• Cloudflare - co to jest, jak działa i kiedy przydaje się firmie
• Co to jest CDN Optima? Funkcje systemu i zastosowania w firmie